benchmarks

[root at jacob dot remcomp dot fr (root)]

A friend of mine, Christian Jullien, has released a lisp interpreter
written in C. (1)

I thought it would be interesting to see the benchmarks of different compilers
with all optimizations turned on.

Here are his results for the different benchmark functions of his interpreter:
fib, tkl, etc.

;; Gabriel's benchmark for OpenLisp
;; Watcom C 11.0    DOS (32 bits)                 12.30 s.
;; Watcom C 11.0    NT  (32 bits)                 12.50 s.
;; Microsoft C 11.0 NT  (32 bits)                 13.26 s.
;; IBM Visual Age C NT  (32 bits)                 13.30 s.
;; Symantec C 7.2   DOS (32 bits)                 14.06 s.
;; GNU GCC 2.7.2    NT  (32 bits)                 14.21 s.
;; Symantec C 7.2   NT  (32 bits)                 14.46 s.
;; LCC C Compiler   NT  (32 bits)                 15.49 s.
;; Borland C 5.00   NT  (32 bits)                 16.20 s.
;; GNU GCC 2.7.2    DOS (32 bits)                 16.37 s.
;; EGCS 1.0         NT  (32 bits)                 16.72 s.
;; Borland C 5.00   DOS (16 bits)                 29.79 s.
;; Microsoft C 8.0c DOS (16 bits)                 24.83 s.

All benchmarks were done in a pentium 200 with 64MB RAM and NT 4.0.

This impressed me for several reasons. Obviously I was very happy that my
work (lcc-win32) goes faster than Borland C 5.00... a commercial compiler.
But beyond that, it is interesting to note that :

o The absolute differences between the fastet and slower compiler in 32 bits 
  is only 4.42 seconds, i.e. approx 25%. 

o The difference between lcc-win32 and the fastest compiler is 3.19 seconds, 
  i.e. approx 20%. 

o The difference between the best version of gcc and lcc-win32 is only 8%.

o The relatively bad performance of egcs is surprising.


Given that the team for all the system in lcc-win32 is only three people, this
is a reason to be proud of. 

The optimizer I wrote for lcc is based only in one objective:
                        *reduce the code size*
Nothing executes faster than a deleted instruction. This seems to pay well!
Smaller code fits better in the cache, and reduces main memory access.

In the future and if time permits, I will try to improve it by adding CSE
and loop peephole register allocation.

I wonder what is going wrong with egcs, since it is gcc based...
Comments welcome.
---------------------------
(1) For more information on OpenLisp see: http://www.ilog.fr:8001/Eligis
---
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".