Sounds like the thread-ring benchmark (http://shootout.alioth.debian.org/u32/benchmark.php?test=thr...) at the shootout. It benchmarks an Erlang program that isn't the first the author ever wrote, so its performance is probably more representative.
Erlang vs. Stackless Python: a first benchmark
11–17 of 17 posts
Re: Erlang vs. Stackless Python: a first benchmark
#12not surprising that python is competitive...afaik haskell also crushes erlang in lightweight threading benchmarks (supposedly the core strength of erlang).
Fault-tolerance (uptime) is Erlang's core strength. Concurrency is just a pleasant and currently trendy side benefit.
Re: Erlang vs. Stackless Python: a first benchmark
#13I don't think Stackless is nearly as well-known as it should be. It has a solid value proposition and is blazing fast in my experience as well.
Stackless is missing some important parts. I've spent a great deal of time working with it over the past few months, and there's no good SSL socket support. The built-in socket module will block the entire process (all tasklets), and while drop-in replacements exist, they either don't work with SSL, are buggy, or both.
Stackless also lacks Erlang's transparent support for multi-process and multi-machine execution, though I talked to a guy who's working on adding that for his Master's degree.
Re: Erlang vs. Stackless Python: a first benchmark
#14I don't think Stackless is nearly as well-known as it should be. It has a solid value proposition and is blazing fast in my experience as well.
Stackless is missing some important parts. I've spent a great deal of time working with it over the past few months, and there's no good SSL socket support. The built-in socket module will block the entire process (all tasklets), and while drop-in replacements exist, they either don't work with SSL, are buggy, or both. Stackless also lacks Erlang's transparent support for multi-process and multi-machine execution, th…
I'll be the first to admit that http socket issues exist and drop-in replacements are indeed often buggy. That being said, this wouldn't be a huge issue to overcome were Stackless given more TLC. Regardless, it has many other valuable uses.
Re: Erlang vs. Stackless Python: a first benchmark
#15as was already pointed out, this isn't a very accurate benchmark; it wasn't tested on a multi-core/processor machine, nor more importantly was it tested on a cluster of machines.
Re: Erlang vs. Stackless Python: a first benchmark
#16not surprising that python is competitive...afaik haskell also crushes erlang in lightweight threading benchmarks (supposedly the core strength of erlang).
> afaik haskell also crushes erlang in lightweight threading
For some definition of "crushes"
http://shootout.alioth.debian.org/u32/benchmark.php?test=thr...
But with quad-core Erlang processes float between cores slowing things down for sequential programs
http://shootout.alioth.debian.org/u32q/benchmark.php?test=th...
Re: Erlang vs. Stackless Python: a first benchmark
#17Sounds like the thread-ring benchmark ( http://shootout.alioth.debian.org/u32/benchmark.php?test=thr... ) at the shootout. It benchmarks an Erlang program that isn't the first the author ever wrote , so its performance is probably more representative.
Yep - and both derive from this 10 year old measurement of context switching:
"Performance Measurements of Threads in Java and Processes in Erlang" http://www.sics.se/~joe/ericsson/du98024.html