SVE Backend - #842
Conversation
|
This now compiles and passes the t3 tests on Ookami. ToDo:
|
|
I remember from Ookami's talk that performance with GCC was the worst among all compilers. I did a brief experiment before losing access to Ookami. I am not sure why these numbers are so small compared to what we had Friday but I think the poor performance with sve might partly have something to do with compiler, maybe?! I have to apply for an account to do more experiments though. |
cdf2581 to
a5b2fa5
Compare
|
Is this ready for review? Should we include it in v0.11? |
|
The two big todos are fixing the makefile magic and seeing if this actually does anything different than OPT in terms of performance. |
d3cd77e to
e57bab0
Compare
|
I noticed that libxsmm contains aarch64/SVE code and it's announced as supported for the next release. |
|
Do we have a place where we can measure performance? There is a machine at Sandia that you can access if you put in a Sarape request and AWS c7g also has SVE. JLSE also has a system that I could try requesting. |
3475cec to
a112875
Compare
1427077 to
2133264
Compare
11b2789 to
2ceb799
Compare
09b6747 to
56d0d6a
Compare
|
964d214 to
7184d99
Compare
|
Side note - finally got the compile flags right to test in GitHub Actions. Yay. But the test is failing. Boo. |
|
Given that XSMM targets this hardware and already gives us better performance on AVX hardware, I propose we close this. Any objections? |
|
This was well before my time, so I'm not 100% on the motivation and scope of the PR. But that logic makes sense to me. |
|
I think XSMM did not target SVE at the time when this work was started. If XSMM covers the scope of what we might use SVE intrinsics for, I don't have a problem sticking with that and just closing this. |
Closes #631