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

Slow Integer Matrix Multiplication #732

Open
SolidTux opened this issue Sep 26, 2019 · 2 comments
Open

Slow Integer Matrix Multiplication #732

SolidTux opened this issue Sep 26, 2019 · 2 comments
Labels
information needed More information is needed to make progress

Comments

@SolidTux
Copy link

Currently matrix multiplications are a lot slower for integer matrices than for float matrices, because for floats either BLAS or matrixmultiply is used.

E.g. here for a 1000x1000 matrix the integer version takes more than 5 times as long as the float version and this get worse when the matrix size increases.

Is there anything planned for fast integer matrix multiplications? Or any way I can help to improve this situation?

@SolidTux SolidTux changed the title Slow Integer Matrixmultiplication Slow Integer Matrix Multiplication Sep 26, 2019
@bluss
Copy link
Member

bluss commented Sep 26, 2019

With f64 you can represent integers up to 1 << 53, so there's your fastest integer matrix multiply. 😉

I don't know if there are any plans. I'm avoiding it since I don't have time for it and the utility is low. It seems like there are a lot more parameters that go into integer MM and the SIMD support is way less developed.

What would the design be with regards to overflow? What's the design for the scalar types, the accumulator and/or the resulting type? Various existing integer MMs have different combinations for these, and this operation seems to show up in specialist libraries.

Someone made an experiment of plugging in integers into matrixmultiply over in bluss/matrixmultiply#28. Maybe one could check in on how the smart people in the thread are doing w.r.t the problem. It would probably be good to bring a design that is already working somewhere else, and bring it to Rust. You don't have to port it - could be a library you call?

@SolidTux
Copy link
Author

The matrixmultiply version would be great. I did a short test and used the test branch with ndarray which decreased the time significantly.

@bluss bluss added the information needed More information is needed to make progress label Apr 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
information needed More information is needed to make progress
Projects
None yet
Development

No branches or pull requests

2 participants