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

When Haskell is Faster than C

paulspontifications.blogspot.com

Post reply on HN
Print view View original

51–60 of 119 posts

Re: When Haskell is Faster than C

#51

Post by jacquesm »

ChuckMcM wrote: post #49
haberman wrote: post #41

These "faster than C" claims are almost always embarrassing (usually involving C code that would easily win if it were as aggressively optimized as the high-level language) but that's almost not the point. The real point is the larger narrative. The subtext of these posts is what we are really arguing about. So let's just duke that out directly. High-level language fans have a point, which is that high-level language…

I wish I could up vote this 10x. When folks were saying "Oh with HotSpotUltimateOptoMix III Java is going to be faster than C code!" or whatever the optimizer de-jour was I would sigh. We have very much reached a stage where there are computers which can dedicate way more cycles to your effort than you need to get it done in time, we can spend this "surplus" on making writing code easier, and that is a huge win. Enjo…

Unless of course the idle loop isn't idle. Since the end of the assembler era there has always been a trade-off: programmer time vs processor time. And programmer time is about as expensive as it was in the past, cycles have gotten cheaper and cheaper.

But the cost of a cycle still isn't 0, and likely it will never be. Optimizing a chunk of code and making it perform 10 times as fast can be a huge competitive advantage when you're operating a sizeable cluster that is really working instead of idling.

For one-offs and incidental use optimization of any kind is nonsense.

Re: When Haskell is Faster than C

#52

Post by tikhonj »

haberman wrote: post #41

These "faster than C" claims are almost always embarrassing (usually involving C code that would easily win if it were as aggressively optimized as the high-level language) but that's almost not the point. The real point is the larger narrative. The subtext of these posts is what we are really arguing about. So let's just duke that out directly. High-level language fans have a point, which is that high-level language…

Just as you're not arguing to use C for everything, people liking high-level languages aren't arguing you should never use C (or, at the very least, a similarly low-level language).

Rather, the point is that using C is very often a premature optimization. It also comes with a sacrifice in terms of productivity, maintainability, safety, testability and readability.

So you should certainly use C. Sometimes. And the question to ask is always: "why C?" and never "why not C?".

Also, you can get quite far by doing something like generating C from a DSL embedded in OCaml or Haskell, giving you both powerful type-level features and many of the advantages of a high-level language without sacrificing low-level control of C. You could use something like CIL[1] to avoid many of C's usual pitfalls. I haven't tried this myself, but I know some people happy with that approach.

[1]: http://www.cs.berkeley.edu/~necula/cil/index.html

Re: When Haskell is Faster than C

#53

Post by ChuckMcM »

jacquesm wrote: post #51
ChuckMcM wrote: post #49

Earlier quoted context omitted.

I wish I could up vote this 10x. When folks were saying "Oh with HotSpotUltimateOptoMix III Java is going to be faster than C code!" or whatever the optimizer de-jour was I would sigh. We have very much reached a stage where there are computers which can dedicate way more cycles to your effort than you need to get it done in time, we can spend this "surplus" on making writing code easier, and that is a huge win. Enjo…

Unless of course the idle loop isn't idle. Since the end of the assembler era there has always been a trade-off: programmer time vs processor time. And programmer time is about as expensive as it was in the past, cycles have gotten cheaper and cheaper. But the cost of a cycle still isn't 0, and likely it will never be. Optimizing a chunk of code and making it perform 10 times as fast can be a huge competitive advanta…

I don't think we disagree. I assert both things are true:

1) There are situations in which extracting the most work out of a given compute infrastructure is the best use of ones time and effort.

2) There are situations in which optimization will only lead to additional free cycles which will go unused thus investment in such optimizations is a waste of time.

Re: When Haskell is Faster than C

#54

Post by confluence »

I want an article that says "Why it doesn't matter what's faster than what - just ship product people use". I code everything I create using the language that gives me the least amount of friction between me and the working product.

On Android that's Java/C/C++, for my servers it's Python/Ruby/Java/C++/C (everything is service oriented consumable APIs), for the browser it's Javascript. Any time I want something faster - I recode and bind it in C/C++ if at all possible.

I feel like a lot of these language comparison posts are just a massive pissing contest. All that matters is that people use the thing that you made. Billions of lines of code have been written in the past. Make sure your code isn't part of the billion that nobody cares about.

Re: When Haskell is Faster than C

#55

Post by mpyne »

haberman wrote: post #41

These "faster than C" claims are almost always embarrassing (usually involving C code that would easily win if it were as aggressively optimized as the high-level language) but that's almost not the point. The real point is the larger narrative. The subtext of these posts is what we are really arguing about. So let's just duke that out directly. High-level language fans have a point, which is that high-level language…

Actually pointers are a sore spot. Of course we have `restrict` in C (and not C++, for some strange reason) but it leaks elsewhere too, like qsort.

Of course your main point still holds (you could write macros that implement your container without void* everywhere) but I feel those are the issues where a HLL is most likely to outperform a naïve C implementation (since it would take gyrations to most efficiently implement the same in C).

Re: When Haskell is Faster than C

#56

Post by bcoates »

jrockway wrote: post #38
ozataman wrote: post #12

Earlier quoted context omitted.

I'm no C expert - too bad to hear that about his C code. However I can tell people here that Vector.Unboxed is a very common optimization as soon as you start thinking about performance in Haskell. Nothing "expertly" about it, really. I, for one, use it in all of my computational Haskell code.

It's also important to notice that Data.Vector.Unboxed has the same API as the other Data.Vector implementations and provides the same typechecking that the other implementations do. All it requires is that the underlying type have a Unbox instance. In most cases, you change: import Data.Vector as V to import Data.Vector.Unboxed as V and your code now gets the performance increase. (The reason it's not the default is…

If they have the same semantics why doesn't the library do an unboxing implementation for types that support it and not for the rest?

Re: When Haskell is Faster than C

#57

Post by cgh »

TheOsiris wrote: post #40
papsosouid wrote: post #36

Earlier quoted context omitted.

>He cherry picks optimizations for the Haskell, such as using Data.Vector.Unboxed instead of the regular lists and removing calls to isLetter Neither of those complaints are reasonable at all. What is wrong with using Vectors? That is like complaining that a C++ version uses vectors, which it presumably would. And how is changing a single function call that is unicode aware to one that isn't unfair? How is using getc…

The unfairness is that he optimizes the Haskell code but then doesn't do the same for the C code and declared Haskell faster. Not what I'd call a reasonable test.

He profiled both programs and made exactly one optimisation to the Haskell program (removing the call to isLetter). Profiling didn't reveal any obvious C optimisations. So he went with what he had. It all seems pretty reasonable to me.

C fans (I am one, by the way) shouldn't get too upset by this. You still aren't going to write an operating system kernel in Haskell.

Re: When Haskell is Faster than C

#59

Post by tedunangst »

bcoates wrote: post #56
jrockway wrote: post #38

Earlier quoted context omitted.

It's also important to notice that Data.Vector.Unboxed has the same API as the other Data.Vector implementations and provides the same typechecking that the other implementations do. All it requires is that the underlying type have a Unbox instance. In most cases, you change: import Data.Vector as V to import Data.Vector.Unboxed as V and your code now gets the performance increase. (The reason it's not the default is…

If they have the same semantics why doesn't the library do an unboxing implementation for types that support it and not for the rest?

This sounds like exactly the sort of optimization that I'm always hearing a sufficiently smart compiler will make for me.

Re: When Haskell is Faster than C

#60

Post by ay »

jacquesm wrote: post #20
Xcelerate wrote: post #17

Hmm... it seems to me that whenever any article is posted that claims "X is faster than C", there are immediately 40 replies saying "Well, the author's C is horrible. If I wrote that, it would be much different." Okay, as someone who has NOT been programming in C 8 hours a day for years on end, I would actually like to see somebody do this -- to show me what GOOD C looks like. So if someone wouldn't mind, could you t…

Ok, I pledge to re-write this properly and to benchmark the current implementation vs a nice one. I'll post the results. I need something to get my mind off things and this is as good as any. It will take at least until Monday (it is my sons birthday tomorrow).

Hey Jacques, may ask for a code review ? :-)

http://stdio.be/revseq.c

Compiled with "gcc -pipe -Wall -O3 -fomit-frame-pointer -std=c99 -pthread" on my Mac, it's about twice as fast at the blog author's version.

Time spent: coding: 30 minutes bugfixing: 30 minutes

I have a feeling there is some kind of catch in the description of the algorithm in terms of implementing the output, but I for the life of me could not grok whether they wanted me to parse the entry into these three pieces or not...

EDIT to add: The only optimization I made was inlining the tightly-called "subst" function, did it without any profiling (so the optimization process literally took about 30 seconds:). Before inlining this version was still about 15% faster than the blog author's one.

Post reply on HN