Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Haskell Is Not faster than C

jacquesmattheij.com

Post reply on HN
Print view View original

81–90 of 227 posts

Re: When Haskell Is Not faster than C

#81

Post by asynchrony »

jrockway wrote: post #48
VeejayRampay wrote: post #36

Earlier quoted context omitted.

I am a Ruby programmer and let it be clear, the holier-than-thou attitude can indeed be pervasive in the Ruby community. Yet, most of the proselytism int the Ruby community are different shades of "Programming with this language makes me very happy, I'd like everyone to be happy as well". Of course it's not always as clear cut and there is sometimes much to be desired in terms of behavior. But that's where the Haskel…

I think you're imagining the holier-than-thou attitude. While people are certainly excited to have figured it out, nobody is asking them to be excited about it. If you disagree, how about citing some sources? You're good at coming up with analogies, but coming up with analogies is like being Hitler. What?

I wonder if 4 comments to Godwin is a new record for Hacker News.

Re: When Haskell Is Not faster than C

#82

Post by flyinRyan »

VeejayRampay wrote: post #5

I still wonder to this day why Haskell programmers want their language to be loved so much. At times it feels like that kid at the playground that spends half his time telling everyone how he's the best thing since sliced bread and cries himself to sleep at night wondering why no one will play with him and his monads. Don't get me wrong, Haskell looks like a great language with obvious qualities and I don't knock any…

I get exactly this vibe from a certain other language, but never Haskell.

Re: When Haskell Is Not faster than C

#83

Post by [deleted] »

wnewman wrote: post #79
confluence wrote: post #68

The problem with fringe languages has always been the "all talk - no walk" nature they all seem to have. Stop telling me why you are so awesome. Just show me with shipped product. Until then it's just an intellectual circle jerk. Talk less. Ship more.

There is truth in this. Certainly shipping more is good. But the situation is somewhat analogous to the perennial debate about commenting code, with "talk" playing the comment role and "ship[ped code]" playing the code role, so that your "talk less ship more" position becomes analogous to the perennial "code should be self-documenting" position. There is truth in that: to an important extent, well-designed code can b…

[deleted]

Re: When Haskell Is Not faster than C

#84

Post by jacquesm »

gnuvince wrote: post #80

> This article is in response to an earlier one comparing Haskell and C, which made the claim that Haskell beats out C when it comes to speed. Perhaps my reading comprehension of the original post is different from Jacques' (or I'm just wrong), but I don't think that the original article made such a claim. Here's the TL;DR of the original article: > TL;DR: Conventional wisdom is wrong. Nothing can beat highly micro-o…

> Perhaps my reading comprehension of the original post is different from Jacques' (or I'm just wrong), but I don't think that the original article made such a claim. Here's the TL;DR of the original article:

The TL;DR is not representative of the whole article. It would be nice if it were but it isn't, so just reading the TL;DR is not enough, better do the short-enough;did-read version of that. Another commenter in this thread said more or less the same thing, I've responded to him here:

http://news.ycombinator.com/item?id=5091270

Re: When Haskell Is Not faster than C

#85

Post by dasil003 »

VeejayRampay wrote: post #36
jrockway wrote: post #26

Earlier quoted context omitted.

I'd say Haskell does one percent of the proselytising that Ruby does. You hear about it a lot on HN because people write interesting articles about it. Remember, most articles that are submitted aren't being upvoted. There's probably someone writing about how their ImmutableSet implementation for Java is the best thing ever, but it's not being upvoted because the community doesn't consider it interesting.

I am a Ruby programmer and let it be clear, the holier-than-thou attitude can indeed be pervasive in the Ruby community. Yet, most of the proselytism int the Ruby community are different shades of "Programming with this language makes me very happy, I'd like everyone to be happy as well". Of course it's not always as clear cut and there is sometimes much to be desired in terms of behavior. But that's where the Haskel…

Rubyists aren't like hippies (hippies have no taste and they dislike drama), more like hipster art critics if anything.

Haskellers being compared to Jehovah's witnesses is even more wrong. They're more like scientists, maybe of the climate change variety: most of them keep their heads down with a dedication to improving the state of the art, but when they go public it's with good reason and people should listen rather rejecting out of hand anything that challenges their ingrained worldview.

Re: When Haskell Is Not faster than C

#86

Post by jacquesm »

JoachimSchipper wrote: post #78

This is cool. However, in the spirit of contributing, comparing one byte at a time is not optimally efficient. It's possible to write clever optimizations by hand, but I'd be surprised if just using https://github.com/rbdixon/glibc/blob/master/string/memchr.c doesn't cause a meaningful speedup.

The inner loop of those comparisons is indeed the spot where you can still speed up as noted in the last part of the post, the kind of optimizations that you describe are extremely effective but qualify as 'micro optimizations' and I expressly left those out because they impact readability considerably. But, you're right, if that's what it takes then so be it and then readability would have to suffer in deference to the last couple of % of speed. Maximum gain from this optimization relative to the final runtime is about 20% by my estimation. (Inner loop will step 8 bytes at the time, but will have more instructions).

Re: When Haskell Is Not faster than C

#87

Post by mej10 »

bborud wrote: post #21

If Haskell, Lisp and friends are so great for building large software systems then surely people are going to flock to them and do exactly that. And if that didn't happen, of course the proponents of these languages would sit down and try to figure out why this wasn't happening. Right?

http://www.paulgraham.com/avg.html

Re: When Haskell Is Not faster than C

#88

Post by daniel-cussen »

dasil003 wrote: post #85
VeejayRampay wrote: post #36

Earlier quoted context omitted.

I am a Ruby programmer and let it be clear, the holier-than-thou attitude can indeed be pervasive in the Ruby community. Yet, most of the proselytism int the Ruby community are different shades of "Programming with this language makes me very happy, I'd like everyone to be happy as well". Of course it's not always as clear cut and there is sometimes much to be desired in terms of behavior. But that's where the Haskel…

Rubyists aren't like hippies (hippies have no taste and they dislike drama), more like hipster art critics if anything. Haskellers being compared to Jehovah's witnesses is even more wrong. They're more like scientists, maybe of the climate change variety: most of them keep their heads down with a dedication to improving the state of the art, but when they go public it's with good reason and people should listen rathe…

That's not holier-than-thou at all.

Re: When Haskell Is Not faster than C

#89

Post by JoachimSchipper »

jacquesm wrote: post #86
JoachimSchipper wrote: post #78

This is cool. However, in the spirit of contributing, comparing one byte at a time is not optimally efficient. It's possible to write clever optimizations by hand, but I'd be surprised if just using https://github.com/rbdixon/glibc/blob/master/string/memchr.c doesn't cause a meaningful speedup.

The inner loop of those comparisons is indeed the spot where you can still speed up as noted in the last part of the post, the kind of optimizations that you describe are extremely effective but qualify as 'micro optimizations' and I expressly left those out because they impact readability considerably. But, you're right, if that's what it takes then so be it and then readability would have to suffer in deference to…

I concur that doing this directly in your code is extremely ugly; but note that you can get this speedup by just dropping in a call to glibc's memchr(), hiding the ugliness behind a well-known interface.

Re: When Haskell Is Not faster than C

#90

Post by DanWaterworth »

rtpg wrote: post #51
sold wrote: post #20

Earlier quoted context omitted.

It's different. It's like you were listening to one music genre all your life and there's suddenly something new. If, say, Python was the only language with "for(each)" loops, you'd see many blog posts about that too. After I saw this, the old style of iterating by index feels so antiquated. Haskell gives the same feeling many times. It has unique features when it comes to abstraction and I feel they are the right wa…

strangely enough, I think one of the interesting features (type classes) only ended up reappearing in Go with its interfaces (granted, only in a very limited fashion).

Go's interfaces are not like Haskell's typeclasses. Just try and write a Go interface that allows you to add two of the same things together.
Post reply on HN