5 ms·
Throwing multiple cores at the problem is not what I would call beating decades of optimized C. The author only utilizes multiple cores when he realizes the ove
by Sysreq1 7y ago
Throwing multiple cores at the problem is not what I would call beating decades of optimized C. The author only utilizes multiple cores when he realizes the overhead of Haskell will not allow him to actually win. Author even admits the C program was more efficient. You can multi thread a C program as well, at which point it would retake the title.
- bonzini 7y agoAlso, when counting words the C code is actually handling multibyte sequences, which is one of the biggest sources of improvement for the Haskell code (8s to 3.5s). Having to use a syntax extension explicitly to forgo laziness feels like cheating to me... But then I have never used Haskell so perhaps that's actually normal.
- unhammer 7y agoIf you're talking about BANGPATTERNS, that is completely normal in Haskell. Pretty much any non-trivial Haskell program (and many trivial ones too) will have !'s in various places to force something to be strict, and to use the ! syntax you do need to add a pragma. Those pragmas are what let Haskell evolve new features without breaking backward compatibility, so Haskell programs tend to have a lot of them. Perhaps one day we'll have a new standard (it's been 19 years since the last one) which will include some of the pragmas by default. In the meanwhile, it's possible to turn the common ones on project-wide and just forget about them.
- tome 7y ago> Having to use a syntax extension explicitly to forgo laziness feels like cheating to me... But then I have never used Haskell so perhaps that's actually normal. The `seq` function achieves the same end and is in the standard library. There's nothing cheating about it. The bang patterns extension just provides some nicer syntax for it.
- pcstl 7y agoHaskell is a lazy-by-default language and the most practical way to disable laziness is that syntax extension. You can do it without the extension, but it'll turn ugly really quick (lots of uses of the "seq" function everywhere). In general, the Haskell community is very tolerant of language extensions (people will recommend you enable about a dozen of them in every project), so this is pretty standard.
- InvOfSmallC 7y agoWhat is the cost of parallelism of C though?
- rootw0rm 7y agospinning up threads and context switching, just like the cost for everyone else?
- chii 7y agoThe Haskell version is provably going to work without issue when parrellelized (due to monoid laws), but I doubt the concurrency primitives in C is as trivially usable, and I expect no sane person would want to write that version.
- keldaris 7y agoWhy? This is not a hard problem and there's nothing wrong with parallelism in C. I'd much rather work on parallelizing the C code than deal with any amount of Haskell. I suspect there are more people who would agree with me than the total amount of people happy to write Haskell.
- sasasassy 7y agoOpenMP IS trivially usable.
- cormacrelf 7y agoThere's nothing stopping you from following the monoid laws in C. There is also nothing stopping you from breaking the monoid laws in Haskell.
- raverbashing 7y agoWhatever the cost in C, Haskell is incurring the same cost, unless it is using green threads. (You could use green threads in C - or something similar, though to be honest counting words in a file is a bit of an annoying problem for parallelism)
- MrBuddyCasino 7y agoI have noticed this is a very human pattern. Things have their strengths, and they've got their weaknesses. But if your identity is bound too much to your favourite thing, you have to bend reality in order to make the weakness disappear. Or as Feynman put it: The first principle is that you must not fool yourself — and you are the easiest person to fool.
- zelly 7y agoIt's sad to see this kind of Stockholm syndrome. The author is fighting hard against the Haskell compiler to fit a square peg in a round hole. Programming languages are just tools, not religions. Programming languages are fake abstractions of the machine. When one doesn't work for you, you should have no problem switching to another. Loyalty to literally an arbitrary man-made mental model at the expense of your real life productivity makes zero sense.
- pwm 7y agoFunny how different people read this differently. I read it as a playful exploration of how far can you push your square peg into that round hole. No one uses Haskell as a faster C irl, that would not make much sense, that’s not where the strength of the language lies.
- psychoslave 7y agoThe article starts directly with a warning that the title is a bit provocative. The main point here is clearly not to sell the existing tool on the sole consideration of binary execution performances. As the article say, with Haskell you can produce more reliable software, thanks to a strong typing, and use higher abstraction levels. Even with a significant loss in performance, this can be a good trade off (depending on the project type of course). So the point here is that you can have descent performance with a state of the art "high-level garbage-collected runtime-based language".
- erichocean 7y ago> is a bit provocative "is wildly incorrect" would be more accurate.
- psychoslave 7y agoThat sounds like a rather common strategy for making provocative statements, doesn't it?
- ummonk 7y agoIn fairness, throwing multiple cores at it would require a lot more boilerplate in C. Whereas for single-core the C code would be simpler than the optimized single-core Haskell code presented here.
- simias 7y agoThere seems to be an unhealthy obsession with beating C in some corner of the Haskell community. It makes even less sense nowadays when some of the most popular languages out there are Javascript and Python, clearly C-grade performance is not required anymore by the vast majority of applications. I actually wrote a comment (in 2013, but the page I'm referencing doesn't appear to have changed one bit) where I shared my experience looking at haskell.org's introduction that was filled with FUD regarding C and how Haskell was so much better and faster: https://news.ycombinator.com/item?id=5090808 https://news.ycombinator.com/item?id=5090808 Maybe if they had actually tried to teach me the language instead of that bad faith "used car salesman" tactic I'd be writing Haskell these days.
- tom_mellior 7y ago> There seems to be an unhealthy obsession with beating C in some corner of the Haskell community. I think it's about the same for pretty much any language in the "statically typed, compiled" camp. You'll see "faster than C" claims for Rust and Go as well, for example.
- simias 7y agoThat's true. I guess what makes Haskell stand out to me is that at this point it's fairly clear that the assertion is mostly wrong (i.e. idiomatic Haskell is not faster than idiomatic C at most algorithmic tasks, and often significantly slower) and instead of doing the reasonable thing and saying "additional safety and expressiveness is more important than raw performance for most applications" (something I'd completely agree with personally) they double-down with these meaningless, unfair benchmarks. Meanwhile Rust is genuinely competitive with C performance-wise and thanks to generics and things like more aggressive inlining can actually equal or even beat C without requiring esoteric micro-optimizations. Of course the drawback is that writing Rust code is significantly more complicated and more restrictive.
- Annatar 7y agoAnd the really funny part for us C practitioners is, we know we'll rarely be as fast as machine code generated from Fortran.