Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans to Support more SVM types #9

Open
sammysheep opened this issue Mar 28, 2023 · 3 comments
Open

Plans to Support more SVM types #9

sammysheep opened this issue Mar 28, 2023 · 3 comments
Labels

Comments

@sammysheep
Copy link

sammysheep commented Mar 28, 2023

Are there any plans to support more SVM types like multi-class GMNP? The Shogun project seems quiet now (abandoned?) and has left behind a trove of BSD-3 licensed C++.

Love that you are using Portable SIMD, it's a really great project.

@ralfbiedert
Copy link
Owner

Are there any plans to support more SVM types like multi-class GMNP?

I haven't checked in with libSVM in a while, but this project was / is meant to be a drop-in Rust replacement. I could see support for other SVM types being added, but that would have to be driven by somebody else as it's not on my roadmap right now.

@sammysheep
Copy link
Author

Hmmm, I would have to evaluate that for myself as well.

BUT supposing someone wanted to contribute to this project, what are the contribution guidelines to follow?

@ralfbiedert
Copy link
Owner

ralfbiedert commented Mar 28, 2023

Contributions are very welcome. A few thoughts, random order:

  • Most important to me is that existing libSVM compat remains and all tests continue to pass (except if latest libSVM were to change) that it remains zero-alloc during runtime
  • Having SIMD instructions would be nice, but it could be worthwhile checking if autovectorization has gotten so good that the entire explicit SIMD machinery could be removed. That would massively simplify the code, remove that dependency and make it instantly compatibly with Rust stable (1)
  • As this was my first Rust project from a few years ago there are some implementation details that that I'm not proud of, and that probably make contributions / changes harder than they should be. From top of my mind: 1) too many macros for implementation details and 2) the simd_aligned library with the VectorD types & co. If any of these get in the way I happily accept patches addressing them
  • From my side I happily review PRs and bounce ideas, but I don't have much time working on this right now

Love that you are using Portable SIMD, it's a really great project.

(1) In theory it's great, but portable SIMD in Rust has been unstable for 5 years or so, and I don't know how many more years it will stay in that state. If I rewrote FFSVM from scratch I'd probably check autovec as mentioned, and / or add a super-thin stable SIMD shim on stable. Being nightly only is a huge drawback for adoption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants