When Haskell Is Not faster than C • Hacker News Board

Re: When Haskell Is Not faster than C

#121

Post by tikhonj » Mon, Jan 21, 2013, 4:54 PM UTC

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 Charter or some number of hedge funds) seem to be very happy with it.

Now, there are some core problems--largely with education and ecosystem maturity--that make Haskell harder to adopt. Recently, people have actually started working on both of these[1]. But neither is a quality of the language itself.

[1]: http://fpcomplete.com/

Re: When Haskell Is Not faster than C

#122

Post by dasil003 » Mon, Jan 21, 2013, 4:55 PM UTC

daniel-cussen wrote: post #88

dasil003 wrote: post #85

Earlier quoted context omitted.

Rubyists aren't like hippies (hippies have no taste and they dislike drama), more like hipster art critics if anything. Haskellers being compared to Jehovah's witnesses is even more wrong. They're more like scientists, maybe of the climate change variety: most of them keep their heads down with a dedication to improving the state of the art, but when they go public it's with good reason and people should listen rathe…

That's not holier-than-thou at all.

Okay then, cut off your nose to spite your face.

Re: When Haskell Is Not faster than C

#123

Post by pretoriusB » Mon, Jan 21, 2013, 4:58 PM UTC

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 implementation of a real world program, not just "highly optimized" ones.

Re: When Haskell Is Not faster than C

#124

Post by dllthomas » Mon, Jan 21, 2013, 5:05 PM UTC

sparkie wrote: post #49

VeejayRampay wrote: post #41

Earlier quoted context omitted.

What about Objective Caml? Seems to fit the bill for all those metrics as well, yet for a reason that eludes me to this day, it never quite reached the kind of "street rep" that Haskell now enjoys.

OCaml isn't purely functional, so it misses some of the most important benefits of Haskell. It's also not entirely honest (in the fact that you can do things that the type system doesn't tell you about.)

With unsafePerformIO, Haskell is also not "entirely honest"...

Re: When Haskell Is Not faster than C

#125

Post by xymostech » Mon, Jan 21, 2013, 5:06 PM UTC

kabdib wrote: post #97

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…

"Just start 256 threads" means you're testing the OS (or /maybe/ your runtime libraries) not the language.

I think that if you were comparing, say, erlang threads to Haskell threads then you would be comparing the languages because both of them have their own internal threads.

Because C has no such concept, and can only use hardware/OS threads, the comparison is moot.

Re: When Haskell Is Not faster than C

#126

Post by dllthomas » Mon, Jan 21, 2013, 5:11 PM UTC

"Third, a comparison on speed between Haskell and C is almost meaningless, speed is not Haskells strongest point and it would be folly to bench it against C for that particular reason."

I disagree wholeheartedly. If I am choosing Haskell over C, I am giving up some (possibility of) performance. The question of how much is an important piece of information, entirely relevant to that decision.

As I observed in a comment on that other post, the actual performance of both the Haskell and the C depends on the amount of effort expended to make them faster (first in general, and then possibly on a particular architecture). At the limit, the C beats the Haskell by some margin - the size of that margin is informative; but that's also not the whole story - what the margin is earlier also matters, and for a particular project, it might matter more.

This is not to say that the particular benchmarks in the earlier article were good choices - I don't have a clear position on that.

Re: When Haskell Is Not faster than C

#127

Post by btilly » Mon, Jan 21, 2013, 5:12 PM UTC

codygman wrote: post #104

DanWaterworth wrote: post #90

Earlier quoted context omitted.

Go's interfaces are not like Haskell's typeclasses. Just try and write a Go interface that allows you to add two of the same things together.

What do you mean add two of the same things together exactly? If I'm not mistaken, what you are talking about is possible but I don't totally understand what you are saying. Could you provide an example?

He's talking about the inability to specify an interface that specifies functions that take two arguments of the same type. Go can't do that.

You can sometimes work around it. For instance consider sorting. The natural approach is to specify a type that allows comparisons. Go can't do that. But in go you can have a collection which has a function Less(i, j int) bool that takes in two integers and compares the objects at those positions (which in turn just happen to be of the same type).

But this is a limited work around, and there are plenty of cases where you can want something more flexible.

Re: When Haskell Is Not faster than C

#128

Post by jff » Mon, Jan 21, 2013, 5:13 PM UTC

dasil003 wrote: post #85

VeejayRampay wrote: post #36

Earlier quoted context omitted.

I am a Ruby programmer and let it be clear, the holier-than-thou attitude can indeed be pervasive in the Ruby community. Yet, most of the proselytism int the Ruby community are different shades of "Programming with this language makes me very happy, I'd like everyone to be happy as well". Of course it's not always as clear cut and there is sometimes much to be desired in terms of behavior. But that's where the Haskel…

Rubyists aren't like hippies (hippies have no taste and they dislike drama), more like hipster art critics if anything. Haskellers being compared to Jehovah's witnesses is even more wrong. They're more like scientists, maybe of the climate change variety: most of them keep their heads down with a dedication to improving the state of the art, but when they go public it's with good reason and people should listen rathe…

We're not worthy! We're not worthy!

Re: When Haskell Is Not faster than C

#129

Post by microtonal » Mon, Jan 21, 2013, 5:14 PM UTC

codygman wrote: post #104

DanWaterworth wrote: post #90

Earlier quoted context omitted.

Go's interfaces are not like Haskell's typeclasses. Just try and write a Go interface that allows you to add two of the same things together.

What do you mean add two of the same things together exactly? If I'm not mistaken, what you are talking about is possible but I don't totally understand what you are saying. Could you provide an example?

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 the first argument, the second argument must also be an integer, as well as the return type. You can observe this by currying, binding only the first argument:

  Prelude> :type (+) (1 :: Integer)
  (+) (1 :: Integer) :: Integer -> Integer
  Prelude> :type (+) (1 :: Double)
  (+) (1 :: Double) :: Double -> Double

In Go, you could write an interface Num and define a function:

  func foo(a Num, b Num) Num

However, if float64 and int both implement the Num interface, you could also foo a float64 and int. And it would return something that conforms to the Num interface, but what type is actually constructed depends on the implementation of foo.

In other words, type classes have relatively little to do with Go interfaces, aside that they both implement a (different) form of polymorphism.

It's possible to make something akin to Go's polymorphism in Haskell, but you'd need to hide the type parameter of the typeclass using existential quantification.

  data NumBox = forall n. Num n => MkNumBox n

You can now use the NumBox for runtime polymorphism:

  Prelude> :type [1::Int, 4.4::Double]
  [...]
     Couldn't match expected type `Int' with actual type `Double'
  [...]
  Prelude> :type [MkNumBox (32 :: Int), MkNumBox (22.32 :: Double)]
  [MkNumBox (32 :: Int), MkNumBox (22.32 :: Double)] :: [NumBox]

Re: When Haskell Is Not faster than C

#130

Post by graue » Mon, Jan 21, 2013, 5:29 PM UTC

dasil003 wrote: post #85

VeejayRampay wrote: post #36

Earlier quoted context omitted.

I am a Ruby programmer and let it be clear, the holier-than-thou attitude can indeed be pervasive in the Ruby community. Yet, most of the proselytism int the Ruby community are different shades of "Programming with this language makes me very happy, I'd like everyone to be happy as well". Of course it's not always as clear cut and there is sometimes much to be desired in terms of behavior. But that's where the Haskel…

Rubyists aren't like hippies (hippies have no taste and they dislike drama), more like hipster art critics if anything. Haskellers being compared to Jehovah's witnesses is even more wrong. They're more like scientists, maybe of the climate change variety: most of them keep their heads down with a dedication to improving the state of the art, but when they go public it's with good reason and people should listen rathe…

I love how easily us nerds get sucked into debating analogies and whether they're right or not and which analogy is the best one, even when it has no bearing on anything. It's a really funny phenomenon to watch.