🗐 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:
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.
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
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.)
Euphoria interpreter, exw.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
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)
Euphoria 0.13 - EtoC Translator / Watcom
Euphoria 0.47 - Interpreted with exw.exe
eu in eu 7.15 - PD source Euphoria translated/compiled to eu.exe
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. If you are looking for an open source language to modify, observe
that even the Public Domain source version of Euphoria,
written 100% in Euphoria, can run twice as fast as Python or Perl
which are both written in C. Which source would you prefer to modify
and debug? Which speed would you like to have for your modified