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

161–170 of 227 posts

Re: When Haskell Is Not faster than C

#161

Post by pekk »

jeremyjh wrote: post #136
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…

I've never worked on a project where my job was to create 256 threads. Instead, I would be tasked with processing lots of requests or datasets in parallel. If Haskell provides convenient and idiomatic ways to do this with lightweight threads that C does not, then C is effectively slower. If C has a commonly used and available library to implement this same approach - then maybe its faster. The whole point is we are c…

C doesn't impose a specific threading model. So a C threading benchmark is specific to the library you are using. And if you choose a heavyweight thread library to compare to a language which is not using heavyweight threads, it is not an apples to apples comparison. Arguably it could be, if C imposed a specific threading model, which it does not.

You are comparing implementations, not languages

Re: When Haskell Is Not faster than C

#162

Post by mightybyte »

VeejayRampay wrote: post #15
Peaker wrote: post #13

Earlier quoted context omitted.

When you find a tool that in many ways is far better than every other tool used by the mainstream (and of course in some ways worse) you might get excited about it so you want to share the knowledge you found. Or maybe you prefer the tool you like to get more adoption so you could use it in more situations. I advocate Haskell because of those two reasons. I think that like me, many others can get enormous educational…

Tons of other languages and programming styles can provide the same benefits. It doesn't have to be Haskell against Python or C++ against Erlang. We can pick, mix and match and let the best of the bunch naturally emerge.

Wrong. There are three main things I want from a programming language: first class functions, strong static types, and purity. Haskell is literally the only language out there today that has these three characteristics and is mature enough for production systems.

Re: When Haskell Is Not faster than C

#163

Post by pekk »

nathell wrote: post #3

Yawn. It is not possible to directly compare languages wrt speed: we only can compare the speed of their implementations and reason about the features that make a language amenable to optimizations. And we all know this. So why, despite this knowledge, do we engage in "language speed flamewars" like this? That's a valid question, and it belongs in the field of psychology of hackerhood. Does anyone have a reply to wag…

I submit that these are really always about implementation speed. And this matters because at the end of the day we will be using an implementation, not a pure language without implementation.

Re: When Haskell Is Not faster than C

#164

Post by neopallium »

There is a bug that causes invalid output when the input file is larger then the BLOCKLEN. Set BLOCKLEN to 4096 and run the program on the test input file [1] (compare with output file [2]), to see the problem on a smaller input file.

The bug happens when read_sequence() is called with partial data saved from the last sequence, since (size == read) the first fread() will be asked for 0 bytes which causes the read loop to end early (n == 0).

1. http://benchmarksgame.alioth.debian.org/u32/iofile.php?test=...

2. http://benchmarksgame.alioth.debian.org/u32/iofile.php?test=...

Re: When Haskell Is Not faster than C

#165

Post by bcoates »

ajross wrote: post #159
sltkr wrote: post #148

Earlier quoted context omitted.

To be fair, QuickSort is particularly suitable for imperative languages that allow in-place modification of arrays. For functional languages, merge sort is a much more natural solution that is simple to implement, guaranteed to be efficient, and probably reasonably fast (though still unlikely to beat a QuickSort implementation in C).

To be fair, QuickSort is particularly suitable for actual computation hardware which has hardware features like numerically addressed, stateful random access memory. Imperative arrays happen to feature "in-place modification of arrays" not because it's a useful language feature but because it's a straightforward abstraction of the actual machine being programmed. That distinction is really important, and something I…

To be fair to mergesort, it's particularly suitable for actual computation hardware too. It's mostly linear reads and writes, which almost all i/o systems heavily favor. GNU sort uses mergesort (in C).

Re: When Haskell Is Not faster than C

#166

Post by ibotty »

pekk wrote: post #161
jeremyjh wrote: post #136

Earlier quoted context omitted.

I've never worked on a project where my job was to create 256 threads. Instead, I would be tasked with processing lots of requests or datasets in parallel. If Haskell provides convenient and idiomatic ways to do this with lightweight threads that C does not, then C is effectively slower. If C has a commonly used and available library to implement this same approach - then maybe its faster. The whole point is we are c…

C doesn't impose a specific threading model. So a C threading benchmark is specific to the library you are using. And if you choose a heavyweight thread library to compare to a language which is not using heavyweight threads, it is not an apples to apples comparison. Arguably it could be, if C imposed a specific threading model, which it does not. You are comparing implementations, not languages

is there a nice lightweight threading library in c that distributes _many_ small threads on _few_ (not one) posix threads? if so: please tell me. i am genuinely interested.

Re: When Haskell Is Not faster than C

#167

Post by ibotty »

ericmj wrote: post #74
sparkie wrote: post #55

Earlier quoted context omitted.

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.

well. but a no-shared-writeable-data approach (as with erlang) certainly helps. and that comes for free with purity.

i don't know how go handles that though. i'd be surprised if this was as efficient as in erlang and haskell.

Re: When Haskell Is Not faster than C

#168

Post by ibotty »

jacquesm wrote: post #107
mistercow wrote: post #102

The original article did mention that switching to use lines instead of characters would probably speed things up considerably, but argued that this makes the program harder to understand, while Haskell makes the same optimizations automatically on the character-based program. And that's a fine point to make, but I do think it was a little misleading and handwavy. The proper thing to do would be to make the change an…

The 'line reader' version of the code (not shown in the article) was actually a lot easier to read than either one of these but the article was already over long. I do have that version, if anybody is interested I can add it.

i'm sure you have all your intermediate steps as well. i really liked an example i've seen a while ago that described an optimization process in git history. you'd simply check out the right step and have a look for yourself.

Re: When Haskell Is Not faster than C

#169

Post by pohl »

dschiptsov wrote: post #154
pohl wrote: post #112

Earlier quoted context omitted.

Lisp's homoiconicity comes with the cost of some extra syntactic weight that Haskell doesn't have to bear. (It's also nice that "lambda" is considered so important that it's given a single character in Haskell). I'm not familiar with J*, and it seems to be difficult to search for. Do you have a reference so I can go learn about it? http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Has... http://rosettacode.org…

I prefer Erlang. http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Erl... And your illustration is particularly good for showing how much more "sane" (actually, in many ways) Erlang is. And how elegantly different Python could be. J* is my own abbreviation for Java and Javascript.)

I prefer Erlang.

Just out of curiosity, why is that? (With reference to the linked example, I mean.) Clearly they're in the same league, and so it's a close call. From my perspective, I like that Haskell reserved the single vertical bar for the list comprehension notation, so that it would be as close to familiar set-comprehension notation as possible. I also like how Haskell takes advantage of how the cons operator already implies in the pattern-matching that you're working with a list, and so the square brackets become unnecessary, whereas Erlang needs the noisy extra layer of brackets on top of the parenthesis needed for the pattern.

But once languages get this elegant, it's a close comparison. They're both beautiful to my eyes.

Re: When Haskell Is Not faster than C

#170

Post by sixbrx »

pretoriusB wrote: post #123
gnuvince wrote: post #80

> 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-o…

> 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. The TL;DR; is wrong too. It doesn't require micro-optimizations for a large real world C program to be faster than an equivalent Haskell program. All those abstractions and laziness in Haskell add up, and you get lower performance overall compared to ANY decent C…

By the same token, the lack of higher level abstractions in C also add up in time and mental effort, and you're more likely to end up, in my experience, writing a dumber and more dangerous algorithm than you would in a language that has better safety features and more powerful abstractions.
Post reply on HN