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

31–40 of 227 posts

Re: When Haskell Is Not faster than C

#31

Post by chongli »

VeejayRampay wrote: post #5

I still wonder to this day why Haskell programmers want their language to be loved so much. At times it feels like that kid at the playground that spends half his time telling everyone how he's the best thing since sliced bread and cries himself to sleep at night wondering why no one will play with him and his monads. Don't get me wrong, Haskell looks like a great language with obvious qualities and I don't knock any…

>I still wonder to this day why Haskell programmers want their language to be loved so much.

Libraries. It's the reason why anyone would want their chosen platform loved.

Re: When Haskell Is Not faster than C

#32

Post by pretoriusB »

benbataille wrote: post #18
seanmcdirmid wrote: post #9

Earlier quoted context omitted.

I'm trying to translate what you are saying. All languages are Turing complete, so it doesn't matter? Do you program in assembly language then? I mean, if it doesn't matter....

> All languages are Turing complete, so it doesn't matter? Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference. If you really need to argue about something go f…

>Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it.

That is extraordinarily wrong.

Syntax:

1) affects the structure of a program,

2) affects how we think about it,

3) affects what is easy to do and what is not,

4) adds or removes mental strain on reasoning about the program,

5) forbids or enables certain kinds of errors.

And much more.

The idea that syntax doesn't matter and is "a matter of preference" is completely bogus. The human mind has certain limitations and capabilities. Some syntaxes cater to that, some do not.

No one using Brainfuck will never be as productive as Python, to take an extreme case.

Re: When Haskell Is Not faster than C

#33

Post by davidw »

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…

> So why, despite this knowledge, do we engage in "language speed flamewars" like this?

Because here in the real world, speed sometimes matters? And many languages are fairly closely associated with given implementations that live in the real world, and are more or less fast.

These days, I mostly write Ruby because time to market is more important than having code run fast, but in its current form, it's generally a slower language than C. There, I said it! Yes, of course I really mean implementation, but realistically, there are no Ruby implementations that are faster than compiled C code.

Re: When Haskell Is Not faster than C

#34

Post by zxcdw »

Shish2k wrote: post #23
norswap wrote: post #10

Earlier quoted context omitted.

Some people like bickering. But I think the point of the article is that C is, by nature of the language, easier to optimize than Haskell, since it is lower level.

> C is, by nature of the language, easier to optimize than Haskell, since it is lower level. Depends what level you mean - if you want to do all the optimisations yourself, C is better; but if you want to write code and let the compiler do the details, I would think higher-level is better (you can just write doWhatIMean() and the compiler will automatically choose the optimal implementation for your current problem a…

> "(you can just write doWhatIMean() and the compiler will automatically choose the optimal implementation for your current problem and platform - where if you'd specified the implementation details yourself, you'd be sub-optimal in many cases)"

How far are we with declarative programming in sense of being expressive and expecting the compiler to understand what we mean? I'd believe that without strong AI human will always be better off with imperative programming than a compiler with declarative, for anythig beyond relatively simple isolated pieces of code/algorithms. In general we have so much more experience and knowledge about the target system and environment than the compiler does, this is less true for JIT compilers, but they come with their own overhead.

I'd really love to see superoptimization[1] to be done as a service for compilers. Say you have a function with certain semantics the compiler is fully certain about. The compiler fingerprints this function and uploads a fingerprint + behavioral analysis to somewhere in cloud> where it's being exhaustively optimized by bruteforcing all the meaningful instruction sequences which conform to the semantics of the function. After the most optimal piece of instructions is being found, it's associated with the finerprint and stored in a database and then returned to the compiler. Now, when ever someone else writes the exact same function(or code with exact same semantics) the compiler queries the some cloud service> for the optimal piece of code. Of course, a system like this would need more information about the actual target of the code(CPU architecture, cost of things like memory access, cache miss, branch mispreciction etc.).

[1]: https://en.wikipedia.org/wiki/Superoptimization (The system I roughly described is far more extensively analyzed in some of the papers. Really great read!)

Re: When Haskell Is Not faster than C

#35

Post by Peaker »

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.

I don't think other languages have the same benefits of Haskell. They have other benefits but not Haskell's.

Python/Ruby: very easy to learn and be productive quickly.

C: high level of control over resources and easy to get good performance.

Haskell: very good static guarantees about correctness. Relatively easy to get decent and good performance. Extremely educational and mind expanding, far more than say Lisp. Allows very high levels of abstraction. Great concurrency and parallelism support.

Lisp: easy to extend syntax with macros and manipulate programs programmatically.

All these languages have benefits, but not quite the same ones.

Re: When Haskell Is Not faster than C

#36

Post by VeejayRampay »

jrockway wrote: post #26
VeejayRampay wrote: post #5

I still wonder to this day why Haskell programmers want their language to be loved so much. At times it feels like that kid at the playground that spends half his time telling everyone how he's the best thing since sliced bread and cries himself to sleep at night wondering why no one will play with him and his monads. Don't get me wrong, Haskell looks like a great language with obvious qualities and I don't knock any…

I'd say Haskell does one percent of the proselytising that Ruby does. You hear about it a lot on HN because people write interesting articles about it. Remember, most articles that are submitted aren't being upvoted. There's probably someone writing about how their ImmutableSet implementation for Java is the best thing ever, but it's not being upvoted because the community doesn't consider it interesting.

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 Haskell in MY PERSONAL OPINION (so to take with a pinch of salt) is slightly different in how it seems to be variations of "Haskell is a superior language, everyone that doesn't use it has not reached enlightenment"

TL;DR: Ruby people can be annoying like hippies can be annoying, Haskell enthusiasts I've found to be more akin to the Jehovah's witnesses of programming.

And just so we're clear, I am going on a slightly provocative/trollish bender here, one that I hope will not offend too much, it's all in good fun.

Re: When Haskell Is Not faster than C

#37

Post by benbataille »

jrockway wrote: post #27
pjmlp wrote: post #12

Earlier quoted context omitted.

It amazes me how bad developers seem to be prepared nowadays in compiler design and language theory. Back in the day we were able to understand that language and implementation are separate concepts. As well as why certain languages had a specific implementation as the default one. Now young developers seems to think language and implementation are the same thing.

Many languages go so far as to specify a virtual machine to run the compiled program, so your statement doesn't make much sense in that context. Languages, machines, libraries and implementation are all deeply interconnected. Try writing C without a stack. Try writing Java without java.lang.

Thank you for brilliantly proving his point. What you wrote just prove that you completely mixed what is a language and what is its implementation.

Of course C semantic uses a calling stack in its definition. Does that mean you need a physical stack to implement it ? Not at all, you can perfectly implement C in anything as long as you can simulate a stack. Just look at the JVM and Dalvik. Dalvik is register based while the JVM is stack-based and they both run Java.

java.lang is a standard library. It's only part of the language definition in a really broad sense. It's actually written in Java. Any complete Java compiler can and will compile it (with some modification for the purely JVM oriented functions). There is a lot of projects out there trying to compile Java on a target which is not the JVM.

Re: When Haskell Is Not faster than C

#38

Post by chii »

Swizec wrote: post #11
VeejayRampay wrote: post #5

I still wonder to this day why Haskell programmers want their language to be loved so much. At times it feels like that kid at the playground that spends half his time telling everyone how he's the best thing since sliced bread and cries himself to sleep at night wondering why no one will play with him and his monads. Don't get me wrong, Haskell looks like a great language with obvious qualities and I don't knock any…

Two things I love about Haskell. 1. It is very terse/expressive. I can look at code I haven't touched in 6 months and still understand what it's doing. Perhaps because my code is newbie code and thus somewhat simple. 2. It is the only language that brings me back to the days of Turbo Pascal when the joy of coding came from coding itself, not from building cool things. A small but vital distinction. That said, I rarel…

have you tried http://roy.brianmckenna.org/ ? its sort of haskell like, but compiles down to javascript, so you could use it in the browser.

Re: When Haskell Is Not faster than C

#39

Post by Peaker »

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…

You could use green threads in C but you'd also need asynchronous io to work with these green threads, and an ecosystem of libraries around it. Ghc has it therefore it makes sense to use its by default green threads. In c there is no standard ecosystem around green threads therefore it is harder to write the benchmarks that way.

Re: When Haskell Is Not faster than C

#40

Post by ignore_secret »

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.

There aren't any other languages that can provide the exact same group of benefits.

What you do is you weigh the benefits and disadvantages of the languages you are considering.

Haskellers just want the benefits of their language known so that it isn't overlooked due to being too difficult/unfamiliar/uncommon etc.

This article missed the point of the original article it was addressing, which is that haskell is often fast enough for the job with a minimal amount of optimisation.

The problem is that the original article author chose a shootout example, where speed was the objective. Idiomatic Haskell is rarely going to win on speed.

The C code in this article is by the authors admission not very robust against invalid input. A robust Haskell implementation would likely take less effort to produce than a robust C implementation. Which is better depends on the goal.

Post reply on HN