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

171–180 of 227 posts

Re: When Haskell Is Not faster than C

#171

Post by sixbrx »

VeejayRampay wrote: post #14
friendly_chap wrote: post #7

Earlier quoted context omitted.

> wondering why no one will play with him That's kind of a strong statement about a language which has approx. 1000 users in it's IRC chatroom.

The number of people present in the IRC channel is more of a sign that they have a very engaged and active community, which is a good sign for the language itself, for sure, but doesn't necessarily correlate to the general adoption of Haskell as a whole. A measure like http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... (by no means a perfect one, quite like speed benchmarks ironically) seems to indicate…

I don't think Haskellers particularly want mainstream adoption. Adoption among library writers would suffice... :)

Re: When Haskell Is Not faster than C

#172

Post by SilasX »

tikhonj wrote: post #115
rtpg wrote: post #51

Earlier quoted context omitted.

strangely enough, I think one of the interesting features (type classes) only ended up reappearing in Go with its interfaces (granted, only in a very limited fashion).

I think one of the most important features of typeclasses is the ability to be polymorphic on just the return type of an expression. For example, there is a typeclass called Read which comes with a function called read: read :: Read r => String -> r That is, you get a function from a String to whatever type is in the typeclass. It's the opposite of toString. This is also used in a whole bunch of other contexts like n…

I'm personally on a quest to "get" Haskell right now, but I really don't see what's so special about that or unique to Haskell. Languages have long accomplished what `read` does by simply casting/coercing the string into the desired type.

In python, for example, I'd call int() on the input strings I want to turn into integers.

Re: When Haskell Is Not faster than C

#173

Post by [deleted] »

sunwooz wrote: post #133

What do you guys think I should learn next? I've been studying javascript/ruby and I would like to diversify what I can make. I don't want to rush learning new languages, but it's interesting to learn about paradigms that certain languages enforce. What's important to me(not in order): 1) Being an omni-platform developer 2) I only know two high-level languages, so learning a low level language will benefit me. 3) I w…

[deleted]

Re: When Haskell Is Not faster than C

#174

Post by jeremyjh »

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

Yes and that was my point. The benchmark is a comparison of implementations - compilers, run times and libraries. I am not sure how you would benchmark a language.

Re: When Haskell Is Not faster than C

#175

Post by ajross »

bcoates wrote: post #165
ajross wrote: post #159

Earlier quoted context omitted.

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

GNU sort is designed to sort on disk though. If you actually watch it working on a giant file, you'll see it generating lots and lots of files in /tmp containing the merge lists.

This is because quicksort obviously requires fast random access to the whole arrays, and (at least when it was written) /usr/bin/sort would be expected to be able to quickly sort data that can't fit in memory.

So... if anything I think this is evidence to my point: in the performance regime, you have to match the algorithm choice to the hardware. Specifically here: sort is making up for the lack of memory by exploiting the comparatively (relative to virtual memory) fast streaming behavior of storage media.

Notably, stateful filesystem I/O is also an area where Haskell tends to fall down. I'm not at all sure a Haskell merge sort of the form used in GNU sort would do well at all, though I'm willing to be proven wrong.

Re: When Haskell Is Not faster than C

#176

Post by gnuvince »

jmount wrote: post #116
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…

Plus quicksort is a classic morass- by the time you harden it enough to deal with real world data you could have written a proper merge sort with similar average case performance and much better worst case guarantee. My rant on quicksort: http://www.win-vector.com/blog/2008/04/sorting-in-anger/

Interesting read, thanks for linking it. When I need to write a sorting algorithm, I usually for Merge Sort, because I can never remember the exact details of swapping/partitioning of QuickSort. It seems much more natural to say "split your data in two, sort them, merge them together". And when I'm feeling damn fancy, I use an InsertSort when the size of the dataset is less than 7-8, another algorithm that I find difficult to forget (at least, the recursive definition; I usually need some paper and pencil to do the in-place version).

Re: When Haskell Is Not faster than C

#177

Post by anon1385 »

tensor wrote: post #158
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.

The old appeal to popularity. The only argument that is worse is the appeal to faith. An intellectual circle jerk occurs when one repeats the same old mantra without doing any actual research. There are plenty of "shipping" products in languages like Haskell. I'm no expert on Haskell, but this wasn't hard to find: http://www.haskell.org/haskellwiki/Haskell_in_industry A better tagline might be: Think more and don't s…

That page has generated some heat in the past: http://flyingfrogblog.blogspot.ch/2010/05/why-is-haskell-use... (admittedly this guy seems to have some personal grievances with people in the Haskell community) I don't know how much the page has changed since this rant was written, but some of the entries seem to be the same, e.g. 'Ansemond LLC' which is a company with a single mac app that hasn't been updated since a beta in 2009 and only mentions Haskell in an old blog post. The site for that company is so charmingly dated that I feel kind of bad for highlighting it, but if this is the kind of 'industry success story' they think worth mentioning then I'm not sure the wiki page is of any value.

Re: When Haskell Is Not faster than C

#178

Post by fix_error »

kevinnk wrote: post #155
microtonal wrote: post #129

Earlier quoted context omitted.

The types of polymorphism are different. Haskell's parametric polymorphism is compile-time polymorphism, Go's interfaces are run-time polymorphism. If we draw a parallel to C++, Haskell's polymorphism is like templates, Go's interfaces are like abstract base classes (except that they use compile-time duck typing). For example, consider the (+) function in Haskell: (+) :: Num n -> n -> n -> n If you use an Integer as…

> If we draw a parallel to C++, Haskell's polymorphism is like templates It's important to note that even if Haskell's classes feel like C++ templates they are actually implemented more like abstract classes. In C++ you essentially create a new function for each template instantiation. In Haskell the function is passed an additional pointer telling the function how to implement the class. Kind of like a vtable pointe…

GHC is pretty good at specializing type-class-using functions for particular instances, e.g. if you have

  fac :: (Num a, Eq a) => a -> a
  fac 0 = 1
  fac n = n*fac (n-1)

  main = do
    x
it will create a specialization (without any indirect calls)

  fac_Int :: Int -> Int
and call that (in fact, in this case fac_Int will even be implemented by a worker function of type Int# -> Int# (unboxed ints)).

If you don't want to rely on this automatic optimization, you can always add a pragma {-# SPECIALIZE fac :: Int -> Int #-}.

(I used a recursive example because a non-recursive function would usually simply be inlined, avoiding any indirect calls too, assuming the call site is monomorphic).

Re: When Haskell Is Not faster than C

#179

Post by confluence »

tensor wrote: post #158
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.

The old appeal to popularity. The only argument that is worse is the appeal to faith. An intellectual circle jerk occurs when one repeats the same old mantra without doing any actual research. There are plenty of "shipping" products in languages like Haskell. I'm no expert on Haskell, but this wasn't hard to find: http://www.haskell.org/haskellwiki/Haskell_in_industry A better tagline might be: Think more and don't s…

That page is just sad when compared to C/C++/Java.

When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me.

Furthermore:

> Bad science. The Haskell community generate an unprecedented amount of bad science, setting out to draw the conclusion that Haskell is great and using every trick in the book to make that conclusion seem feasible. In many cases, it requires quite some effort to uncover the truth. For example, Saynte published results for "naively" parallelized ray tracers and concluded that Haskell was the easiest language to parallelize efficiently, requiring only a single line change. This deception was perpetrated by starting with a "serial" version that had already been extensively reworked in order to make it amenable to parallelization and then disabling optimizations only for the competitors (and even adding their compile times in one case!) in order to make Haskell appear competitive. Moreover, that reworking could only have been done on the basis of extensive benchmarking and development. Even the academics publishing Haskell research are up to it. For example, in the recent paper Regular Shape-polymorphic parallel arrays Manuel Chakravarty et al. artificially close the gap between Haskell and C by benchmarking only cache ignorant algorithms (that spend all of their time stalled on unnecessary cache misses), incorrectly states that such algorithms are "widely used", describes the one-line change required to parallelize the C code as "considerable additional effort" despite the fact that both the serial and parallel C solutions are substantially more concise than their Haskell counterparts, refused to provide me with their C code so that I could try to verify their findings (until I published this blog post, their code is now here) and cherry picked Haskell's highest performing results as a function of the number of threads (which peaks at an unpredictable number before seeing performance degradation). When I voiced my concerns, Don Stewart abused his moderator status on the forum by deleting my criticisms. To date, these flaws in the paper have not been addressed.

Source: http://flyingfrogblog.blogspot.ch/2010/05/why-is-haskell-use...

Guess Haskell knows a thing or two about misrepresentation.

Re: When Haskell Is Not faster than C

#180

Post by [deleted] »

tikhonj wrote: post #121
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?

That's assuming people are rational and willing to put up with large up-front costs on the promise of future returns. Haskell is different, and learning Haskell is closer to learning programming all over again than just picking up another algolish language. Most programmers don't even seem willing to do the latter, much less learn something truly novel. The people who do use Haskell professionally (e.g. Standard Char…

[deleted]
Post reply on HN