-
Notifications
You must be signed in to change notification settings - Fork 180
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
Possibly test HiGHS on RISC-V hardware #2000
Comments
Sure. Are these compiler and architecture combinations that we support OK @galabovaa? |
HiGHS solves the .lp (MPS) file in 2.09 (0.92) seconds, with a clearly different algorithmic path. Seeing that they correspond to a feasibility problem, different solutions are very likely. Different machine, but undoubtedly rather faster than GLPK |
We have GCC and -O2 tested, as well as clang on ARM but we have not yet tested HiGHS on RISC-V hardware |
I'm in the middle of it :P |
Let me see if I can find what went wrong. |
One looks like,
But all the others are variations on this regex-not-found:
|
These iteration count tests are indicators of a logical difference in the way that the simplex solver runs on a particular architecture: no error has occurred. They can be caused by compiler optimizations |
It is worth considering modifying our tests so the iteration counts are only checked on particular architectures that we have tested on. Since it is expected for them to differ. I guess the objective values differ with a value below 1e-08. For macOS arm I have added different objective values and iterations to ctest for the instances that differ, and the ones above seem to be a subset. In way what you show is expected. Is it possible for you to run ctest --verbose and send me the (possibly rather large) output, so I could use the values to do the same? |
No problem, here you go: |
Thank you! I will add the iteration counts for RICS-V in cmake :) |
Hi @orlitzky I have added the iteration count modifications to branch risc-v: https://github.com/ERGO-Code/HiGHS/tree/risc-v Could you please check whether there are any tests that are still failing? Once those are cleared I can merge it in latest. |
I admit I was trying to trick it, but I did succeed by switching to
Details:
|
This trick is expected to work: changing levels of compiler optimizations is expected to change iteration counts. We've had a discusstion about it recently with some new compiler friends. We only really test for the default -O2. So, apart from the trick, did ctest pass with the default setting? :) |
I suppose it may be worth to modify CMake, so the iteration count tests are only executed if the level of -O is not modified by the user. I would be happy to do this on another branch. This bit I could test locally too, since it would also fail on macos ARM / windows or linux with amd64 too. |
Yes, it worked with the same compiler/flags as in my original report. Out of the box, CMake will actually use
My CXXFLAGS are IMO you're likely to run into the same sort of problem with changing CC/CXX as well. |
As requested! But keep in mind that the difference was only important with GCC at
-O2
, or with clang, and on ARM64 or RISC-V hardware.edge_disjoint_spanning_trees.lp.txt
edge_disjoint_spanning_trees.mps.txt
The text was updated successfully, but these errors were encountered: