3 ms·

No, see GHC here: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang

by iand675 14y ago

No, see GHC here: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... A lot of work goes into getting it that performant, but it's entirely doable with the right knowhow. (Before anyone gets pedantic, I realize that languages aren't slow, just implementations of them, etc.)

jlarocco 14y ago
Well, GHC is still slower than C, C++, Ada and Fortran, so the link doesn't really refute his point. And, looking at the code, a lot of the Haskell is subverting purity and laziness by using things like Data.ByteString.Internal and Data.ByteString.Unsafe, so I think that actually makes the case even stronger.
- iand675 14y ago
  I'd have to disagree, considering that GHC maintains similar speeds to Mono and JVM languages. The question was about functional languages being slower, but he didn't specify slower than what. If the unspecified alternative is imperative languages, then there are plenty of imperative languages that are slower in that graph and will likely never be as fast as Haskell. Granted, functional languages are never going to be as fast as low-level languages like C, but that doesn't mean they're necessarily slow either.
  - jlarocco 14y ago
    So GHC is fast as long as it's only compared to slower languages? > Granted, functional languages are never going to be as fast as low-level languages like C, but that doesn't mean they're necessarily slow either. That's the point.
- acomar 14y ago
  > subverting purity and laziness That's an interesting choice of words. Quite obviously no useful program can be totally pure (otherwise it'd do nothing but heat the machine). And Simon Peyton Jones is on record saying that he's not sure if he'd carry the laziness torch quite so far if he had to do it all over again. Neither is to say that these aren't powerful or useful techniques, but rather that in Haskell they're chosen as defaults -- impure and/or strict code are the outliers that require justification, not the other way around. So given that, in what way is using ByteStrings (safe or unsafe) subversion? Far from it -- use the tool that makes sense. With most functional languages, the usual technique to writing fast code is to first write it to be correct, and then transform it to be fast. And that's exactly what unsafe ByteStrings are: optimizations. There's nothing wrong with optimized code, and I see no problem with the technique. The only relation it bears to the OP is that it's an explicit unboxing. Perhaps the compiler should automatically do that unboxing, but that's easier said than done.
  - jlarocco 14y ago
    I guess my biggest problem is all of the people claiming Haskell is pure, lazy and fast. It seems disingenuous when to actually be fast requires swapping out the standard data structures with non-pure, non-lazy versions. To put it another way, a naive implementation in C will compile and be relatively fast, while a naive implementation in Haskell will, at the very least, require replacing the standard data structures with things like ByteStrings, just to match the default C speed.
    - acomar 14y ago
      Pure and fast is certainly feasible -- you don't always need to use unsafe bytestrings for example. Laziness makes performance hard to predict because you have no clue when something will get evaluated -- there's no contract with the compiler. Maybe one day some group of really smart people will figure out how to take advantage of that to write compilers that produce really fast code, but I think language-wide laziness is not a feature bound for mainstream languages. Targeted laziness? Probably, it's very useful for expressing data structures. But not everywhere by default. In any case, I don't think people are trying to be disingenuous. Haskell is, or can be, all three of those things. It's just very hard to get them all at the same time.

by iand675 14y ago

jlarocco 14y ago

Well, GHC is still slower than C, C++, Ada and Fortran, so the link doesn't really refute his point. And, looking at the code, a lot of the Haskell is subverting purity and laziness by using things like Data.ByteString.Internal and Data.ByteString.Unsafe, so I think that actually makes the case even stronger.

iand675 14y ago
I'd have to disagree, considering that GHC maintains similar speeds to Mono and JVM languages. The question was about functional languages being slower, but he didn't specify slower than what. If the unspecified alternative is imperative languages, then there are plenty of imperative languages that are slower in that graph and will likely never be as fast as Haskell. Granted, functional languages are never going to be as fast as low-level languages like C, but that doesn't mean they're necessarily slow either.
- jlarocco 14y ago
  So GHC is fast as long as it's only compared to slower languages? > Granted, functional languages are never going to be as fast as low-level languages like C, but that doesn't mean they're necessarily slow either. That's the point.
acomar 14y ago
> subverting purity and laziness That's an interesting choice of words. Quite obviously no useful program can be totally pure (otherwise it'd do nothing but heat the machine). And Simon Peyton Jones is on record saying that he's not sure if he'd carry the laziness torch quite so far if he had to do it all over again. Neither is to say that these aren't powerful or useful techniques, but rather that in Haskell they're chosen as defaults -- impure and/or strict code are the outliers that require justification, not the other way around. So given that, in what way is using ByteStrings (safe or unsafe) subversion? Far from it -- use the tool that makes sense. With most functional languages, the usual technique to writing fast code is to first write it to be correct, and then transform it to be fast. And that's exactly what unsafe ByteStrings are: optimizations. There's nothing wrong with optimized code, and I see no problem with the technique. The only relation it bears to the OP is that it's an explicit unboxing. Perhaps the compiler should automatically do that unboxing, but that's easier said than done.
- jlarocco 14y ago
  I guess my biggest problem is all of the people claiming Haskell is pure, lazy and fast. It seems disingenuous when to actually be fast requires swapping out the standard data structures with non-pure, non-lazy versions. To put it another way, a naive implementation in C will compile and be relatively fast, while a naive implementation in Haskell will, at the very least, require replacing the standard data structures with things like ByteStrings, just to match the default C speed.
  - acomar 14y ago
    Pure and fast is certainly feasible -- you don't always need to use unsafe bytestrings for example. Laziness makes performance hard to predict because you have no clue when something will get evaluated -- there's no contract with the compiler. Maybe one day some group of really smart people will figure out how to take advantage of that to write compilers that produce really fast code, but I think language-wide laziness is not a feature bound for mainstream languages. Targeted laziness? Probably, it's very useful for expressing data structures. But not everywhere by default. In any case, I don't think people are trying to be disingenuous. Haskell is, or can be, all three of those things. It's just very hard to get them all at the same time.