[erlang-questions] Erlang is the best choice for building commercial application servers

[Jan Burse]

Hi,

Looks my mac book pro is much slower... Sniff
I don't have Erlang on it, since I do
not build.

But here are some figures that show the difference
between JDK 1.6 / JDK 1.7 on a mac. I didn't
use the micro benchmark I posted, I used my
Prolog interpreter test suite:

java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07-393-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-393, mixed mode)
Total	in 12049	(206 gc) ms

openjdk version "1.7.0-u4-b225"
OpenJDK Runtime Environment (build 1.7.0-u4-b225-20120119)
OpenJDK 64-Bit Server VM (build 23.0-b10, mixed mode)
Total	in 10388	(92 gc) ms

I don't see a difference -client versus -server
for the test suite. So difference is not that big,
but still!

Bye

P.S.: Correction of Richard O'Keefe Java measure
done with JDK 1.6: 19.2 ms * 10388 / 12049 = 16.5 ms,
how funny, on par.


Richard O'Keefe schrieb:
> Jan Burse's naive reverse for Erlang is not quite what we usually mean
> by nrev; he measures the time to create the initial data list as well,
> which the Java version doesn't.
>
> Revising the Erlang code slightly, I got 2.8 usec per call.
> I also revised the Java code slightly, for example, NOT to
> use accessor methods, and NOT to require any casting during
> the benchmark.  Also, both benchmarks were revised by
> doing
>
> 	t0 = now
> 	run a dummy benchmark calling an identity function
> 	t1 = now
> 	run the real benchmark
> 	t2 = now
> 	report ((t2 - t1) - (t1 - t0))/(double)number-of-iterations
>
> as is traditional in the naive reverse benchmark.
>
> The final score:
>
> Erlang:  2.8 usec per call
> Java  :  3.2 usec per call (reported as 3226.977 nsec)
>
> Machine: a MacBook pro with a 2GHz Intel core 2 Duo cpu running
> Mac OS X 10.6.8.
>
> Multiplying these numbers by 6000 to match Jan Burse's:
> 	Me	    Him	     Him, scaled
> Erlang  16.8 m      ~60 ms   ~ 72.9 ms
> Java    19.2 ms     ~30 ms   ~ 36.5 ms
> (The scaled column assumes that the 2430 number is CPU
> speed; if that's not what it is, ignore that column.)
>
> There's one tiny change that accounts for this.
>
> And it's the reason this benchmark really tells us nothing worth knowing.
>