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

Single location to call Procedural API for all matrix types and automatic concucurrency #179

Open
lessthanoptimal opened this issue Feb 11, 2023 · 2 comments
Assignees
Labels
Discuss Needs additional discussion enhancement

Comments

@lessthanoptimal
Copy link
Owner

Right now every matrix type has it's own set of classes; CommonOps_DDRM, CommonOps_ZDRM, CommonOps_DSCC, ... etc. Then if you want to call concurrent implementations you have to call another variant, i.e. CommonOps_MT_DDRM. Currently the only way to hide this complexity is to use SimpleMatrix. However, that only supports a few functions and you lose control over memory management.

To make people's lives easier, I'm proposing CommonOps (and other similar named classes) that will support most of the Procedural API for all matrix types in a single location. It will also handle automatic switching to concurrent implementations when the matrix size is large enough and handle workspace variables using ThreadLocal.

https://github.com/lessthanoptimal/ejml/tree/feature/fancy_ops

That's the working branch for this work. One issue that has become apparent is that an automated procedure for either checking that all functions have been brought over or to generate CommonOps itself. The goal for the next release is to have just enough functionality to run in JavaMatrixBenchmark. Threaded implementations have yet to be run in that public benchmark because there was no easy way to use them.

@lessthanoptimal lessthanoptimal self-assigned this Feb 11, 2023
@lessthanoptimal
Copy link
Owner Author

The main motivation for me is that when I want to use concurrent implementations but still have the ability to turn it off in downstream libraries there is no way to do that without manually coding it up yourself. This will solve that problem. Plus needing to handle workspace is annoying.

While no one has complained, I think having the Procedural API require knowing all these suffixes makes it difficult for people to get started.

@lessthanoptimal lessthanoptimal added enhancement Discuss Needs additional discussion labels Feb 11, 2023
@FlorentinD
Copy link
Collaborator

I can also say, that when first looking at EJML, the suffixes also got me confused.
AFAIK, you also explained the suffixes in the docs, so after a first confusion, it is straight-forward to navigate.

My main concern would be that this will lead to large files which are harder to navigate.
But in general, I think this would be a good improvement :)

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

When branches are created from issues, their pull requests are automatically linked.

2 participants