-
Notifications
You must be signed in to change notification settings - Fork 11
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
What is going on when further optimization appears to make the program slower? #211
Comments
Short answer: Needs to be investigated. I'm out of ideas why this is happening. |
Thank you for being open about the situation. I think the current workaround is acceptable, and since I've shifted to running with smaller I was able to reproduce this behavior on 2 out of 2 machines for the above picture by using all cores and flipping through tmux tabs for a minute. I have the sense that it would just work if I tried again. If there's a specific change you'd like me to test with to gather data, I'd be more than happy to do this. Looking at |
Lets see. The status line is generated in So based on this, the assembly actually seems to get worse. So, from that, I think we should actually have a look at the assembly from this cutoff point, to find out what actually changed. |
Oh, and I just double checked. I was wrong about the writeout every 10%. It used to be that, but now only the last asm is written. This means, the last one from each of the bets, and one final one from the I'm in the works of fixing that, but during the tests I'm now able to reproduce the error (50) that has been thrown in the GH CI lately. I'll try to fix that, too and push some changes to dev |
A cartoon image of CryptOpt I've had is that it rejects mutations that make the program slower. I know that this is idealistic, even the optimization trace in the paper goes down for a bit. But how is it that continuing to try more mutations seems to have a real chance of making the cycle counts in the CryptOpt output go up? I understand that there's some chance that a mutation will misleadingly appear attractive due to measurement noise, but looking at the above log I can tell at a glance that a previous program would likely perform better. What is going on here -- is the theory that something changes about the machine to make both versions run slower, or does the wrong one just get picked sometimes?
The text was updated successfully, but these errors were encountered: