Optimization of IORefs and STRefs - comparison to g++
Mateusz Kłoczko
mateusz.p.kloczko at gmail.com
Thu Dec 3 01:10:06 UTC 2015
Hello!
I've performed a few simple tests using Haskell and C++ on primitives.
I've compilled all Haskell programs with -O2 optimizations, and C++ ones
with -O3
ghc version - 7.10.2, gcc version : 5.1.1
I'm sending the codes in the zip file.
*Problem1* - 100 000 000 iterations.
Time of execution (in seconds):
*Int pure tail recursion*: 6.911011299962411e-2
*Int# pure tail recursion *: 4.587398100011342e-2
*IORef for loop* 1.1533970820000832
*IORef 'tail' recursion* 1.0696569040001123
*STRef for loop* 1.1545546840006864
*STRef tail recursion* 1.1110019479992843
*C++ *: 2.7e-07
The llvm version could be as fast as C++ one in this problem.
Buuut... then there's *problem 2* (using if or case) - 100 000 000
iterations:
*Int# tail recursion* 1.315346227000191
*IORef for loop*: 2.6442542390004746
*STRef for loop*: 2.669217500999366
*C++*: 0.158056
Here haskell is about 9 times slower than C++.
*Problem 4* - executing the same functionality using bit operations - 100
000 000 iterations:
*Int# tail recursion:* 0.12361123500068061
*C++:* 0.131141
So, Haskell here is as fast as C++.
My question is: can IORefs and STRefs be optimized ? I would like very much
to rely on them, but I would like to achieve great speeds.
Also, is can one achieve good speeds of execution when using cases or ifs ?
If not, what is the other way to do it ? Compiler flags, Cmm optimizations
- they are all welcome.
And the final question - how hard would it be to implement such
optimizations in ghc compiler?
Regards,
Mateusz Kłoczko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151203/bf1e72a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EfficientMutability.zip
Type: application/zip
Size: 4751 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151203/bf1e72a1/attachment.zip>
More information about the Glasgow-haskell-users
mailing list