OpenEuphoria

6.1.24 bench/sieve8k.ex

Prime sieve benchmark "Shootout" version

6.1.24.1 Usage

eui sieve8k <iterations> <largest>

default is 1 iteration with 8192 as largest allowable prime

6.1.24.2 Interpreter Benchmark Results

The Euphoria interpreter seems to be the world's fastest!

Although it provides subscript checking, uninitialized variable checking, full dynamic storage allocation, flexible generic data types, and integer overflow checking, it still manages to "blow away" all other programming language interpreters that we know of.

The results below are based on the prime sieve benchmark from the Great Computer Language Shootout by Doug Bagley. The numbers are taken from the WIN32 version of the Shootout at

http://dada.perl.it/shootout

We chose sieve because it was CPU-intensive, and less trivial than some of the other benchmarks. It's also integer-based, as most real programs are. Naturally, you should perform your own benchmarks, based on the type of programs that are important to you.

6.1.24.3 Our Methodology:

We measured the speed of Euphoria on the version of sieve used in the Shootout. We measured both the Euphoria interpreter, and the Euphoria To C Translator. The machine used in the WIN32 Shootout was a Pentium-4 1.6GHz running Windows XP. Our machine for the Euphoria measurements was a Pentium-4 1.8GHz, also running Windows XP. We thus adjusted our times upward by 1.8/1.6, i.e. we added 12.5%. As a check, we downloaded Python 2.1 and ran sieve with N=900 on our machine. Python was only about 3% faster on our machine, probably because CPU speed is not the only factor. Level-2 cache access time may also be important. To be fair, we nevertheless scaled up all of our Euphoria times by the full 12.5%.

We ran the Euphoria sieves with N=90000 to get accurate timings. For comparison, we divided by 100 to match the N=900 used on the WIN32 shootout, and we added 12.5%.

The Shootout used an external timer on the programs, that necessarily included start-up times. We used an internal timer in the Euphoria programs, because it's more accurate, and because we lacked a good external timing mechanism. To eliminate the start-up times of the other languages, we subtracted their time for N=1 from their time for N=900. In most cases the N=1 start-up time was just a tiny percentage of the full N=900 time. (So we were actually only timing 899 iterations for the other languages.)

6.1.24.4 The Results

Euphoria interpreter, eui.exe:

For N=90000 on 1.8GHz machine: 41.39 seconds

scaled to N=900 (divide by 100): .4139 seconds

adjusted +12.5% to compare with 1.6 GHz: .4656

Euphoria To C Translator (with C compilation by Watcom for WIN32):

For N=90000 on 1.8GHz machine: 11.28 seconds

scaled to N=900 (divide by 100): .1128 seconds

adjusted +12.5% to compare with 1.6 GHz: .1269

From dada.perl.it/shootout/ prime sieve benchmark (interpreted languages)

N=900 iterations. Start-up time (N=1) was subtracted out Pentium-4 1.6 GHz

Interpreters, sorted by seconds taken: (EtoC added for comparison)

6.1.24.5 Conclusions

1. Euphoria (interpreted) beats all of the other interpreted languages in the Shootout. All of the well-known languages are beaten by a huge margin. For instance, Perl is 16.36/.4656 = 35 times slower than interpreted Euphoria. Python is 31 times slower.
2. If you want even greater speed, the Euphoria to C Translator can give you a factor of .4656/.1269 = 3.7 versus the already-fast interpreter. In fact, EtoC easily beats many compiled languages such as Java and C-Sharp (C#) on this benchmark, and it comes close to hand-coded, fully-optimized C. This is remarkable, since Euphoria code is *much* easier to write and debug than C. EtoC beats both Perl and Python by a factor of more than 100!
3. Observe that even the version of Euphoria written in pure Euphoria can run twice as fast as Python or Perl which are both written in C.