-
Notifications
You must be signed in to change notification settings - Fork 96
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
Minimize the use of floating point arithmetic #15
Comments
But the use of floating point calculations should be already pretty much minimal. They are also mostly done outside of the critical loops, except for the |
Could you please share your current logs? It is quite possible that the reported values are actually normal. Also as a test, you could try to hack the |
Hi I made a small patch to check if the soft-float is really performance cost. We won some Mb/s but not so much. Feel free to integrate that (or not :) ) |
How big was the difference? I just don't like integers for this kind of calculations because they tend to overflow. And if it happens, then we get really bogus results. Edit: BTW, you are using
|
The difference was about ~3%. (go from 380 Mb/s to 390 Mb/s) The fact that ualarm is not accurate is not an issue. In my case, the loop run about 0.6 seconds (far of 0.5 asked) in both case. The timer t1 and t2 give us the true start and stop so the value is still accurate. |
Hi,
We're currently developing on the new ARMADA380 architecture for FreeBSD.
During the checks of the L2 cache activation, we use your tool that is very useful.
However, FreeBSD 10.3 lack the support of hard-float, so all the computations of the memory bandwidth include the soft-float computation. It results bad value (and some stress :) ) and hours to search why the memory is so slow.
Can you look to minimize as possible the use of floating point arithmetic during the bench phases ?
Thank you
Alexandre Martins
The text was updated successfully, but these errors were encountered: