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

91–100 of 227 posts

Re: When Haskell Is Not faster than C

#91

Post by flyinRyan »

benbataille wrote: post #6

Could everyone on HN just take a course in languages theory so we can all stop with these stupid trolls about the best languages which have been emerging for a week. Hopefully it would allow everyone to realize that a language is just some syntax and semantic and that a compiler is just a program like another. Nothing sacred here. Hell you can even do imperative programming in Haskell if you wish. Coding an interpret…

This is totally wrong. Different languages have different levels of power. Sure, you could always write an interpreter but that's exactly the difference between a power language vs. a weak one: to do X will I need to write a whole interpreter here or can the language just do it?

Lisp is so powerful because you can do things like delayed evaluation of arguments, via macros. With Haskell you don't even need this due to the lazy evaluation.

Re: When Haskell Is Not faster than C

#92

Post by spookylukey »

jacquesm wrote: post #64
spookylukey wrote: post #56

This article starts by totally misrepresenting the original article ( http://paulspontifications.blogspot.co.uk/2013/01/when-haske... ) by saying that it said "Haskell beats out C when it comes to speed". If you bother to read even the TLDR of the original article you 'll find it says something completely different, which makes this article pretty poor as a response.

From TFA: "So here is the bottom line. If you really need your code to run as fast as possible, and you are planning to spend half your development time doing profiling and optimisation, then go ahead and write it in C because no other language (except possibly Assembler) will give you the level of control you need. But if you aren't planning to do a significant amount of micro-optimisation then you don't need C. Has…

Compared to the amount of optimisation that many people typically do (i.e. zero or close to zero), it was a large amount of extra work to get that performance boost. The global re-arrangements of the way data flows through the code are more difficult than many micro-optimisations, not less, so I don't understand how you can claim.

And you don't have to be an expert in C to make the claim he is making, because most people are not experts in C, but might turn to it because "it's faster". It's precisely this kind of person who needs to understand that with their level of knowledge, and the amount of effort that they might put into optimisations, Haskell can be just as good or better.

Re: When Haskell Is Not faster than C

#93

Post by shriphani »

rtpg wrote: post #47
simias wrote: post #8

This reminds me that when I was interested in learning haskell I was completely put off by their "introduction" page on their homepage. It was a couple of years ago but it doesn't seem to have changed much: http://www.haskell.org/haskellwiki/Introduction It looks like a very pretentious sales pitch to me. You have quotes like "Writing large software systems that work is difficult and expensive. [...] Functional progr…

Is there any language intro page that shows a good sized working program?

Yes. Racket has a great intro-page and download links etc. No BS.

http://racket-lang.org/

Re: When Haskell Is Not faster than C

#94

Post by MichaelGG »

VeejayRampay wrote: post #41
Peaker wrote: post #35

Earlier quoted context omitted.

I don't think other languages have the same benefits of Haskell. They have other benefits but not Haskell's. Python/Ruby: very easy to learn and be productive quickly. C: high level of control over resources and easy to get good performance. Haskell: very good static guarantees about correctness. Relatively easy to get decent and good performance. Extremely educational and mind expanding, far more than say Lisp. Allo…

What about Objective Caml? Seems to fit the bill for all those metrics as well, yet for a reason that eludes me to this day, it never quite reached the kind of "street rep" that Haskell now enjoys.

OCaml led to F#, which is getting some level of adoption, but perhaps limited to folks OK running Windows, as not everyone knows/likes Mono. The fact Microsoft ships a very complete set of tools for F# is pretty cool.

Re: When Haskell Is Not faster than C

#95

Post by flyinRyan »

norswap wrote: post #10
benbataille wrote: post #6

Could everyone on HN just take a course in languages theory so we can all stop with these stupid trolls about the best languages which have been emerging for a week. Hopefully it would allow everyone to realize that a language is just some syntax and semantic and that a compiler is just a program like another. Nothing sacred here. Hell you can even do imperative programming in Haskell if you wish. Coding an interpret…

Some people like bickering. But I think the point of the article is that C is, by nature of the language, easier to optimize than Haskell, since it is lower level.

I disagree. Have you read any articles on stream fusion in Haskell? You can tell the compiler that certain actions are equivalent and suddenly some code that makes two passes down a tree makes just one pass. Doing the same thing in C would be a lot more work precisely because you're working at such a low level.

Re: When Haskell Is Not faster than C

#96

Post by riffraff »

shriphani wrote: post #93
rtpg wrote: post #47

Earlier quoted context omitted.

Is there any language intro page that shows a good sized working program?

Yes. Racket has a great intro-page and download links etc. No BS. http://racket-lang.org/

the question was "a good sized working program", the racket page is a great page but only has a few haikus, so "no" should be your first word, even if the rest of the comment is correct :)

Re: When Haskell Is Not faster than C

#97

Post by kabdib »

sharpneli wrote: post #17

I ran into similar issue few years ago where lack of knowledge combined with large amount of fanboyism clouded someones mind. In a popular language comparisons site there was a threading benchmark. It was simple, just start 256 threads. Haskell beat C by far. I did strace. The C benchmark actually spawned 256 threads and the Haskell one spawned 4. The response I got was that it's a builtin feature in Haskell that it…

"Just start 256 threads" means you're testing the OS (or /maybe/ your runtime libraries) not the language.

Re: When Haskell Is Not faster than C

#98

Post by jacquesm »

JoachimSchipper wrote: post #89
jacquesm wrote: post #86

Earlier quoted context omitted.

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.

Good point about memchr, I missed an opportunity there.

edit: because it's clearer and faster, that's a no-brainer, updating the blog post with a remark to that effect and a link to parent.

Re: When Haskell Is Not faster than C

#99

Post by riffraff »

chongli wrote: post #31
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 still wonder to this day why Haskell programmers want their language to be loved so much. Libraries. It's the reason why anyone would want their chosen platform loved.

I'd say a healthy job market is also something anyone would want for their platform, and the more teams pick it up the more likely it would be for you to find a good job working with some stack you love.

Re: When Haskell Is Not faster than C

#100

Post by ShaunK »

pjmlp wrote: post #54
jrockway wrote: post #27

Earlier quoted context omitted.

Many languages go so far as to specify a virtual machine to run the compiled program, so your statement doesn't make much sense in that context. Languages, machines, libraries and implementation are all deeply interconnected. Try writing C without a stack. Try writing Java without java.lang.

You just prove my point. Of course languages define virtual machines, or in languages like C the abstract machine model, but that is only how the developer sees the machine through the language semantics. This does not change in any way whatsoever how the language is actually implemented.

I think it is usually easy to determine by context when someone is referring to a language and when someone is referring to the typical implementation, libraries, etc that come along with a language. In the context of performance benchmarking it is clear (to me at least) that the benchmark would be of a particular implementation, of which there is usually an obvious choice. I don't think there is really any misunderstanding of that.
Post reply on HN