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

71–80 of 227 posts

Re: When Haskell Is Not faster than C

#71

Post by revelation »

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…

That wiki link to an actual implementation of quicksort in Haskell is pure comedy gold (1):

"Unfortunately none of the above "real" quicksorts seems to compile as given"

"The program below is working very very slowly. It's probably slowsort."

"A more specific/direct translation (neither this nor the C version is polymorphic) is offered by Daniel Fischer, who reports that this version runs within 2x of the C version"

(and it's a completely unreadable mess that is clearly a line by line copy of the C code given)

What a complete and utter trainwreck.

[1]: http://www.haskell.org/haskellwiki/Introduction/Direct_Trans...

Re: When Haskell Is Not faster than C

#72

Post by James_Duval »

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).

Is this common? I'm taking the "Introduction To Programming Languages" at Coursera and we're using SML straight out of the gate. It's really fun and totally different from the Java and before that the basic AS/JS I experimented with. Do universities not tend to offer these types of courses?

Is this an advantage of the free courses (relatively unpopular or obscure languages being taught for learning's sake) which paid courses can't or won't offer?

Re: When Haskell Is Not faster than C

#73

Post by nicholassmith »

chii wrote: post #57
nicholassmith wrote: post #2

Nice refutation. The problem about doing language comparisons for speed is that they generally require a non-trivial example, so you have to be an excellent programmer in all the languages you've compared. Of course, language speed charts are generally as useful as PC spec charts and YouTube videos of Nürburgring laptimes when you're buying a new car.

well, what about an existing piece of software, and compare on more than just speed, but ease of maintenance (meaning, how quickly you can add features or fix a bug)? There seems to be a myriad of window managers and web frameworks. Someone should do an unbiased comparison.

Same thing again, it depends entirely on really specific domain logic. How easy it is to add a new feature on a C based web browser versus one built on Haskell is mostly useless, it just tells you how quickly one person added one feature on one specific thing.

Languages aren't inherently comparable, you can get useful benchmarks but they shouldn't be taken as gospel.

Re: When Haskell Is Not faster than C

#74

Post by ericmj »

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…

Purity has nothing to do with green threads. Many languages that doesn't have the concept of purity have green threads, like Erlang or Go. In fact, green threads are not a part of Haskell, but a part of the runtime. Purity is just a nice thing to have when working with threading or concurrent programs.

Re: When Haskell Is Not faster than C

#75

Post by bgilroy26 »

pretoriusB wrote: post #32
benbataille wrote: post #18

Earlier quoted context omitted.

> 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. 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. That is extraordinarily wrong. Syntax: 1) affects the structure of a program, 2) affects how we think about it, 3) affects what is easy to do and what i…

> No one using Brainfuck will never be as productive as Python, to take an extreme case.

Isn't it a good thing then, that no one prefers using Brainfuck to using Python at work? Leaving things up to preference doesn't mean that all the choices are the same. It means that the languages and the use cases are so varied that it isn't a good idea to restrict oneself blindly to a language before evaluating the use case. It doesn't seem like you are really in disagreement.

Re: When Haskell Is Not faster than C

#76

Post by pretoriusB »

bgilroy26 wrote: post #75
pretoriusB wrote: post #32

Earlier quoted context omitted.

> 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. That is extraordinarily wrong. Syntax: 1) affects the structure of a program, 2) affects how we think about it, 3) affects what is easy to do and what i…

> No one using Brainfuck will never be as productive as Python, to take an extreme case. Isn't it a good thing then, that no one prefers using Brainfuck to using Python at work? Leaving things up to preference doesn't mean that all the choices are the same. It means that the languages and the use cases are so varied that it isn't a good idea to restrict oneself blindly to a language before evaluating the use case. It…

>It doesn't seem like you are really in disagreement.

Oh, I'm very, very much in disagreement.

It's not just about "preference" as if preference is arbitrary.

Superficial syntactic preference IS arbitrary.

Substancial syntax issues are not.

Brainfuck is not just left alone because people don't "prefer" its syntax. That's reading it in reverse. People don't prefer Brainfuck's syntax because it is objectively, and for reasons related to human psychology, cognition, etc bad.

E.g it makes it measurably difficult to discern different program states.

Re: When Haskell Is Not faster than C

#77

Post by polymatter »

simias wrote: post #61
looser wrote: post #45

Earlier quoted context omitted.

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.

I highly recommend (http://learnyouahaskell.com/)

Re: When Haskell Is Not faster than C

#78

Post by JoachimSchipper »

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.

Re: When Haskell Is Not faster than C

#79

Post by wnewman »

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 be "self documenting" and thus speak for itself. Analogously, to an important extent, shipping code can work so well that its demonstrated excellence tells you something about the techniques that it uses, and thus it speaks for itself. However, it's hard to use that kind of speaking-for-itself effect to communicate some abstract issues , such as the issue of why something was done that way. Text explaining "here's why such-and-such [inheritance/functional/macro/declarative/whatever] techniques are important here" can be hard to replace with "look at the code". This problem can be quite severe for languages with extremely unusual paradigms, like the Haskell or Prolog examples that people have mentioned.

Beyond that, many important issues only become significant in sizable programs, to the extent that they are imperceptible in examples less than a few pages. (This is not only an issue for language features: books like _Refactoring_ and _Large-Scale C++ Software Design_ are devoted to issues that become important with scale, and would probably be very hard to appreciate for someone who's never constructed or maintained a piece of software that required more than 5 hours of programmer time.) So if you get your mind around an entire application domain and a software system for it which is a good fit to an exotic programming language --- as, e.g., the HOL Light machine-checkable proof assistant seems to be a good fit to OCaml --- then you will very likely learn something about the strengths and weaknesses of the language and its paradigm. But some fraction of people, even perhaps some fraction of HN readers, will treat a software system like HOL Light as "tl;dr", so a 5-minute or 30-minute pitch on how the language fits the problem may be more effective in practice.

Re: When Haskell Is Not faster than C

#80

Post by gnuvince »

> 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-optimised C, but real everyday C code is not like that, and is often several times slower than the micro-optimised version would be. Meanwhile the high level of Haskell means that the compiler has lots of scope for doing micro-optimisation of its own. As a result it is quite common for everyday Haskell code to run faster than everyday C. Not always, of course, but enough to make the speed difference moot unless you actually plan on doing lots of micro-optimisation.

From this, I understood that in a larger program, most programmers wouldn't be doing the kind of micro-optimizations that they do for the Benchmarks Game. I figure that most code would be written following this pattern:

* Write code to follow the spec (usually without thinking too much about performance)

* Run the code, and evaluate its performance

* If the performance is good enough, you're done

* If the performance needs to be better, run a profiler

* Find the biggest bottleneck and optimize it

* Re-run the code and re-evaluate its performance

The original article took a micro-benchmark (a mistake in my opinion, because it's easy to micro-optimize every single detail of that code) and showed that in the case of Haskell, the first version was too slow, but that with the help of a profiler, finding the cause was easy, and the fix was trivial, while in C the profiler didn't show any problem with the code of the user, so it must be a problem in the standard library's code, and to fix it required changing the design of the program and making it more different than the spec. And I felt this was the author's real point; that to get the maximum performance from a C program, you'll need to code it not like a human would imagine it, but like a computer would, and it makes the code harder to maintain later on.

Post reply on HN