4 ms·

I think it would be uncontroversial to say that optimized GHC Haskell (statically typed, compiled, optimized, native code) is always faster than current Erlang

by dons 15y ago

I think it would be uncontroversial to say that optimized GHC Haskell (statically typed, compiled, optimized, native code) is always faster than current Erlang implementations (dynamically typed, interpreted, lightly optimized). For example, the fastest Erlang programs on the benchmarks game are all slower than all the GHC Haskell programs, * http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=erlang http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Median slowdown relative to GHC is 7x. GHC is aiming for the high performance computing world of late, as well. The Erlang language just doesn't have the facilities for raw number crunching that's needed.

fijal 15y ago
It's always controversial to claim performance numbers without any actual evidence. Note that shootout numbers are by far not evidence about web-server performance.
- jfoutz 15y ago
  Argument from authority is not much of an argument, but dons is intensely focused on ghc performance, here's an easy to google example. http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/ http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell... It's not to hard for you to go get benchmark numbers in haskell, check out http://www.serpentine.com/blog/2009/09/29/criterion-a-new-benchmarking-library-for-haskell/ http://www.serpentine.com/blog/2009/09/29/criterion-a-new-be... or read about how snap does its benchmarking. As for erlang, there's a lot of papers about reliability. I'm not saying the performance isn't there, it's just not a focus of the erlang community. You'll have a much tougher time figuring out instruction counts for a given function in erlang. Given that erlang is interpreted, without a major focus on performance, it seems unlikely erlang would be quicker. This is just - what i perceive as - the general consensus. I'd love for you to generate some numbers to prove me wrong.
tete 15y ago
Erlang is interpreted. Since this is not about a simple CGI application a benchmark in which you compare the running time of a compiled executable with the interpretation and running time a another program it doesn't make a lot of sense. Also this performance usually isn't the best way to argument about languages for web applications. Often your bottleneck is somewhere else and i you really have resource intensive stuff why not just interface C?
- SomeOtherGuy 15y ago
  >Erlang is interpreted No it isn't, it is compiled to bytecode and executed on a virtual machine, just like most scripting languages are. >Since this is not about a simple CGI application a benchmark in which you compare the running time of a compiled executable with the interpretation and running time a another program it doesn't make a lot of sense. Read the site, this concern is explicitly addressed. The tests are long running, not short tests repeated a million times. So the byte code compilation step ends up too small to notice. That is why using a PHP bytecode caching plugin doesn't increase PHP's performance on the shootout, and why java isn't dead last from the massive startup time of the JVM. >Also this performance usually isn't the best way to argument about languages for web applications This is a myth. Very few web applications actually have one CPU intensive portion that can be moved out into a C module. Most web apps have pretty flat profiles, where overall language speedups make the biggest difference. When 90% of your time is spent in 10% of the code, a C module is a reasonable option. When 90% of your time is spent in 90% of your code, your only option is a faster language.

by dons 15y ago

fijal 15y ago

It's always controversial to claim performance numbers without any actual evidence. Note that shootout numbers are by far not evidence about web-server performance.

jfoutz 15y ago
Argument from authority is not much of an argument, but dons is intensely focused on ghc performance, here's an easy to google example. http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/ http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell... It's not to hard for you to go get benchmark numbers in haskell, check out http://www.serpentine.com/blog/2009/09/29/criterion-a-new-benchmarking-library-for-haskell/ http://www.serpentine.com/blog/2009/09/29/criterion-a-new-be... or read about how snap does its benchmarking. As for erlang, there's a lot of papers about reliability. I'm not saying the performance isn't there, it's just not a focus of the erlang community. You'll have a much tougher time figuring out instruction counts for a given function in erlang. Given that erlang is interpreted, without a major focus on performance, it seems unlikely erlang would be quicker. This is just - what i perceive as - the general consensus. I'd love for you to generate some numbers to prove me wrong.

tete 15y ago

Erlang is interpreted. Since this is not about a simple CGI application a benchmark in which you compare the running time of a compiled executable with the interpretation and running time a another program it doesn't make a lot of sense. Also this performance usually isn't the best way to argument about languages for web applications. Often your bottleneck is somewhere else and i you really have resource intensive stuff why not just interface C?

SomeOtherGuy 15y ago
>Erlang is interpreted No it isn't, it is compiled to bytecode and executed on a virtual machine, just like most scripting languages are. >Since this is not about a simple CGI application a benchmark in which you compare the running time of a compiled executable with the interpretation and running time a another program it doesn't make a lot of sense. Read the site, this concern is explicitly addressed. The tests are long running, not short tests repeated a million times. So the byte code compilation step ends up too small to notice. That is why using a PHP bytecode caching plugin doesn't increase PHP's performance on the shootout, and why java isn't dead last from the massive startup time of the JVM. >Also this performance usually isn't the best way to argument about languages for web applications This is a myth. Very few web applications actually have one CPU intensive portion that can be moved out into a C module. Most web apps have pretty flat profiles, where overall language speedups make the biggest difference. When 90% of your time is spent in 10% of the code, a C module is a reasonable option. When 90% of your time is spent in 90% of your code, your only option is a faster language.