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

111–119 of 119 posts

Re: When Haskell is Faster than C

#111

Post by DannyBee »

srean wrote: post #110
DannyBee wrote: post #88

Earlier quoted context omitted.

It's not actually the structure of C programs, it's the guarantees the language offers. So only about the first paragraph of your rant is right. Fortran had almost no memory aliasing, explicit global accesses, and offered almost unbridled implementor freedom. As long as the operations got done, it didn't care what happened behind the scenes. None of the rest of the things you talk about matter when it comes to optimi…

Lots of interesting information. However, I think you over-reacted about Fortran. After reading the parent comment and your comment it seems both of you are saying the same thing: Fortran has the advantage of having no pointer aliasing. Regarding unification based algorithms, do microsoft use any of it in their F# compiler. I ask because they have time to time tried to say we wont sue you for F# technology. Dont know…

I don't know off hand if they use it. I know they do in static analysis tools. As nice as MS is, they seem to consider compilers solely a cost center. Their compilers produce "relatively good code", but have never really been state of the art.

Re: When Haskell is Faster than C

#112

Post by shrughes »

vajrabum wrote: post #64
shrughes wrote: post #44

Earlier quoted context omitted.

Are you writing that in Haskell or in C? Because in Haskell, you'd want to use the /= operator. In C, you'd want to use strcmp.

I think you meant strncmp. Nobody ever wants strcmp, not if they know what it does.

We know what it does and it's the right thing to use. You must be thinking of strncpy or some other ennified string.h function.

Re: When Haskell is Faster than C

#113

Post by zura »

Snoptic wrote: post #78
zura wrote: post #14

Earlier quoted context omitted.

My impression is that, while it is possible to come up with a performance oriented Haskell code, it becomes quite ugly and diverges from those beautiful and idiomatic examples found in books. E.g. explicit strictness specifications, real quicksort (with Array.ST), etc..

The same applies to C, of course.

I wouldn't say so. Some books indeed skip some "real-world" details, but that doesn't affect idiomatic C, which is already performance friendly.

Re: When Haskell is Faster than C

#114

Post by jacquesm »

ay wrote: post #103
jacquesm wrote: post #62

Earlier quoted context omitted.

Sure, I'll pick it up in the post. Neat little project this. I won't peek at your code until I'm done.

Thank you! It was indeed a nice little fun exercise. It is interesting the bugs that I made by being tired and not reading the task carefully/not thinking clearly (yesterday was a bit of a long and stressy day): 1) My initial understanding was that I do need to reverse the order, yet somehow after re-reading the article I understood the order does not need to change, and the "reverse" in the name is some kind of jarg…

Hey Andrew,

Ok, I looked at your code. What you really should do (before coding up the solution) is to look at the problem specification. Other than that I like the 'direct' approach, it isn't quite as fast as what I cooked up but yours is a lot shorter.

Re: When Haskell is Faster than C

#115

Post by ay »

jacquesm wrote: post #114
ay wrote: post #103

Earlier quoted context omitted.

Thank you! It was indeed a nice little fun exercise. It is interesting the bugs that I made by being tired and not reading the task carefully/not thinking clearly (yesterday was a bit of a long and stressy day): 1) My initial understanding was that I do need to reverse the order, yet somehow after re-reading the article I understood the order does not need to change, and the "reverse" in the name is some kind of jarg…

Hey Andrew, Ok, I looked at your code. What you really should do (before coding up the solution) is to look at the problem specification. Other than that I like the 'direct' approach, it isn't quite as fast as what I cooked up but yours is a lot shorter.

Thanks! yes, this goes to show the perils of coding after a 12h work day on Friday :-). This affected the use of fgets() I/O (I understood you have to call the line-buffered routines based on their description)

Enjoyed reading your code. Beautiful. Thanks!

Re: When Haskell is Faster than C

#116

Post by dllthomas »

cgh wrote: post #57
TheOsiris wrote: post #40

Earlier quoted context omitted.

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.

The obvious C optimization is using getc_unlocked and putc_unlocked, which cuts the C run-time in better than half, beating out Haskell by a smidge.

Re: When Haskell is Faster than C

#118

Post by papsosouid »

dllthomas wrote: post #116
cgh wrote: post #57

Earlier quoted context omitted.

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.

The obvious C optimization is using getc_unlocked and putc_unlocked, which cuts the C run-time in better than half, beating out Haskell by a smidge.

And that is a valid criticism. The criticisms that were being responded to were not valid.

Re: When Haskell is Faster than C

#119

Post by dllthomas »

papsosouid wrote: post #118
dllthomas wrote: post #116

Earlier quoted context omitted.

The obvious C optimization is using getc_unlocked and putc_unlocked, which cuts the C run-time in better than half, beating out Haskell by a smidge.

And that is a valid criticism. The criticisms that were being responded to were not valid.

For sure. The chorus of "Clearly you should be writing your own buffering" has been bugging me - it's not hard but there's a lot of room for an error and you're doing a lot of obfuscating of the code actually solving your problem reimplementing infrastructure that already exists in libc... If you're consuming a single character at a time from a single thread, I don't think you're likely to beat getc_unlocked by much anyway.
Post reply on HN