5 ms·
From my experience: * The vast majority of code doesn't need to be fast, and it's trivial to write code that's within a factor of 5 of optimized C. I can writ
by jackpirate 11y ago
From my experience:
* The vast majority of code doesn't need to be fast, and it's trivial to write code that's within a factor of 5 of optimized C. I can write Haskell at least 10x faster than I can write optimized C for the same problem.
* If you want code that's within a factor of 2 of C then you'll need to understand quite a bit about the internal details of the compiler, but your code won't get too ugly. I'd say it's about the same amount of work in both C and Haskell to get this level of performance.
* If you want code that's just as fast as optimized C then you'll need great understanding of both the compiler and the underlying hardware. At this point, you can expect your code will get hideously ugly. Also your code will break a lot when GHC versions change. I can write optimized C about 10x faster than I can write optimized Haskell.
Of course every problem is different, and this is only a rough average of my experience.
- Fede_V 11y agoVery helpful reply, thanks. If it's not too much to ask, do you have any examples (that you are free to share) of taking some Haskell code, then optimizing it bit by bit?
- efnx 11y agohttp://www.reddit.com/r/haskellgamedev/comments/2jbtob/haskell_breakout_optimized_from_60fps_to_500fps/ http://www.reddit.com/r/haskellgamedev/comments/2jbtob/haske...
- barosl 11y agoThat's interesting, what does "break" mean exactly? Does it stop compiling after GHC being upgraded? Or does it suffer from performance regression due to the changes of the optimizing strategy in GHC?
- efnx 11y agoGHC progresses fast and the internal types change subtly, so after upgrading GHC, some libraries fail to compile. Fixing it is usually trivial, and it's a nice way to keep in touch with your compiler.