This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug optimization/1046] gcc less efficient than jdk for recursion!


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046



------- Additional Comments From jacques dot bouchard at onera dot fr  2003-07-16 11:28 -------
Subject: Re:  gcc less efficient than jdk for recursion!

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046

> ------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-12 04:37 -------
> Could you try again with 3.3 or mainline?  As usual, there have been lots of changes.
> For that matter, try again with the new JDK, which is reportedly slower.  (heh).

Here are my new results:

GCC 3.2.2 (Slackware's) :
=========================

gcc -v
Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/usr --enable-shared --enable-threads=posix 
--enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i386-slackware-linux 
--host=i386-slackware-linux
Thread model: posix
gcc version 3.2.2

gcc -O2 -s fib.c -o fib (as in 1st report):

\time fib
267914296
18.50user 0.00system 0:18.51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (79major+10minor)pagefaults 0swaps

gcc -O2 -fomit-frame-pointer -s fib.c -o fib :

\time fib
267914296
17.77user 0.01system 0:17.77elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (79major+10minor)pagefaults 0swaps

GCC 3.3 :
=========

gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs
Configured with: /home/bouchard/gcc-3.3/configure --enable-languages=c,c++,f77 --prefix=/usr
Thread model: posix
gcc version 3.3

gcc -O2 -s fib.c -o fib (as in 1st report):

\time fib
267914296
18.30user 0.01system 0:18.30elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (79major+10minor)pagefaults 0swaps

gcc -O2 -fomit-frame-pointer -s fib.c -o fib :

\time fib
267914296
16.28user 0.01system 0:16.28elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (79major+10minor)pagefaults 0swaps

J2SDK1.4.2 :
============

java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

javac -target 1.4 -g:none -O Fib.java :

\time java Fib 1
1
0.25user 0.03system 0:00.28elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1267major+537minor)pagefaults 0swaps

\time java Fib
267914296
16.07user 0.06system 0:16.17elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1350major+548minor)pagefaults 0swaps

ENVIRONMENT :
=============

Laptop Dell with Pentium III 500 MHz & 128 MB (same hardware as in 1st report)
Linux Slackware 9.0 (kernel 2.4.20 + glibc 2.3.1)

CONCLUSION :
============

The C code is 24% faster ((1-16.28/21.36)*100) than in the 1st report.
The Java Code is 7.7% faster ((1-(16.17-0.28)/(17.83-0.61))*100) than in the 1st report.

The Java code is now only 2.4% faster ((1-(16.17-0.28)/16.28)*100) than the C one.

'-fomit-frame-pointer' is clearly useful with GCC 3.3.
BTW, in gcc-info, that option is said to be "Enabled at levels `-O', `-O2', `-O3', `-Os'"
which is obviously false for i386.

NOTE: only the best times from several runs are shown in this report.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]