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

61–70 of 227 posts

Re: When Haskell Is Not faster than C

#61

Post by simias »

looser wrote: post #45
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…

Probably the reason Haskell's introduction has more explanation is because for most, functional programming language is unusual. Evaluating a language by just reading the introduction is like reading the introduction of a book and saying that you didn't like it. Read it! :) It seems we are focusing too much in a possible weak point and forgeting about several strong points Haskell has.

I agree that I'm nitpicking a bit but I do think it's significant. It says something about the mentality of the community. First impressions matter.

But perhaps you could recommend me and others who'd like to try haskell a better introduction to the language? I'm still curious to try it.

Re: When Haskell Is Not faster than C

#62

Post by PommeDeTerre »

wereHamster wrote: post #44
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?

Education is a big part of the problem. When I attended university, we weren't even told that functional programming exists. Only later on, through one of my friends it was brought to my attention. And it's hard to change that mindset, particularly at the university I was. They are set to produce a constant stream of Java/.NET developers for the companies around them (large banks, in particular).

Which university was this, and which program?

Re: When Haskell Is Not faster than C

#63

Post by gits1225 »

benbataille wrote: post #18
seanmcdirmid wrote: post #9

Earlier quoted context omitted.

I'm trying to translate what you are saying. All languages are Turing complete, so it doesn't matter? Do you program in assembly language then? I mean, if it doesn't matter....

> All languages are Turing complete, so it doesn't matter? Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference. If you really need to argue about something go f…

>>"Precisely. The whole "my language is better" argument is completely void."

You say later that the difference is "only on how you will do it". If you stop to think for a second, you come to realise that syntax, abstractions and the big elephant in the room: how "tuned" a language is for the myriad of computing platforms/operating systems/domains (scientific, business, web) -among many other factors- play a HUGE part in how you can develop software and how performant it can/will be. So languages does matter.

>>"Note that there is no theoretical bound preventing an Haskell compiler to generate code equally fast than the one of a C compiler for any program."

But it won't, because at the end of the day, a machine has to execute the programs written in a language and C was designed for a machine with certain characteristics in mind while Haskell/Lisp and other higher level languages are an exploration in abstractions.

When Abelson & Sussman says: "Programs must be written for people to read, and only incidentally for machines to execute.", there is an implicit understanding that trade-offs are being made and its not the same as C and other lower level programming languages. Until a machine appears that isn't limited by the constrains of the present, making trade-offs is inevitable and that too, does matter.

@jacquesm: Great write-up. Enjoyed every line of it.

P.S: I make no distinction between a language and its implementation here.

Re: When Haskell Is Not faster than C

#64

Post by jacquesm »

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. Haskell will give you the same performance, or better, and cut your development and maintenance costs by 75 to 90 percent as well."

Note the 'same performance or better' in there.

Maybe you missed that bit in the original article?

This wasn't a large effort by any stretch of the imagination and a factor of 5 difference compared to the Haskell code isn't even in the same ballpark as "the same performance", and about a factor 10 difference with the C code listed in the original article. You'll notice no micro optimizations were done in the re-write, just some global re-arranging of the way data flows through the program.

The rest is in response to the misleading title, that Haskell is 'faster' than C, faster to program, faster to debug, easier to maintain and so on while making claims about performance that are not born out by real world comparisons.

Speed was the wrong thing to compare on here, and should not have been part of the original article without a serious effort to become equally proficient in both languages.

Re: When Haskell Is Not faster than C

#65

Post by betterunix »

benbataille wrote: post #18
seanmcdirmid wrote: post #9

Earlier quoted context omitted.

I'm trying to translate what you are saying. All languages are Turing complete, so it doesn't matter? Do you program in assembly language then? I mean, if it doesn't matter....

> All languages are Turing complete, so it doesn't matter? Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference. If you really need to argue about something go f…

If one language cannot be better than another, why is it so hard to name examples of BF programs that paid their own development costs and decades of research costs? I can think of a language for which there is such an example, by the way:

https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replannin...

Re: When Haskell Is Not faster than C

#66

Post by Peaker »

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.

I don't know OCaml very well, but I do know that without laziness, it does not support as much high-level/reusability[1].

Also, it lacks much of the mind-expanding stuff in Haskell (The class hierarchy explained by the Typeclassopedia).

AFAIK, GHC had surpassed OCaml's compilers' performance, concurrency support, etc. Compiler rewrite rules are also a very nice feature that other languages cannot immitate due to lack of purity.

Many of the parallelism benefits are much a result of purity, which OCaml lacks. Also stuff like software-transactional-memory rely on purity for their guarantees, which OCaml cannot provide. Reasoning about code is also much easier with purity.

1. http://augustss.blogspot.co.il/2011/05/more-points-for-lazy-...

Re: When Haskell Is Not faster than C

#67

Post by wereHamster »

PommeDeTerre wrote: post #62
wereHamster wrote: post #44

Earlier quoted context omitted.

Education is a big part of the problem. When I attended university, we weren't even told that functional programming exists. Only later on, through one of my friends it was brought to my attention. And it's hard to change that mindset, particularly at the university I was. They are set to produce a constant stream of Java/.NET developers for the companies around them (large banks, in particular).

Which university was this, and which program?

The university in Lucerne, Switzerland. Hence the reference to large banks ;)

Re: When Haskell Is Not faster than C

#68

Post by confluence »

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.

Re: When Haskell Is Not faster than C

#69

Post by Peaker »

sparkie wrote: post #55
Peaker wrote: post #39

Earlier quoted context omitted.

You could use green threads in C but you'd also need asynchronous io to work with these green threads, and an ecosystem of libraries around it. Ghc has it therefore it makes sense to use its by default green threads. In c there is no standard ecosystem around green threads therefore it is harder to write the benchmarks that way.

This misses the point on why green threads are, and can be the default behavior in Haskell. It's because the purity allows it to be. Sure you can make "green threads" in C, but you as the programmer must be very careful how you use these threads. You can't go accessing some global state (or performing many different side-effects) from them freely - so you must design your code to be as "purely functional" as possible…

I disagree. Threads and green threads are not different in any way that is related to purity.

Haskell makes threads much more pleasant due to Haskell code generally being much more orthogonal. But even in C, it would make more sense to create green threads rather than actual threads (at least any thread beyond the first thread-per-core) in most settings you'd actually use threads for.

Re: When Haskell Is Not faster than C

#70

Post by bgilroy26 »

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.

A lot of the OCaml community is French-speaking.
Post reply on HN