Gforth compiled with LLVM and gcc

This is a discussion on Gforth compiled with LLVM and gcc within the Forth forums in Programming Languages category; I just tried several recent gcc versions as well as a version of llvm-gcc on the current Gforth development version. Here are the timing results on an Opteron 270 (2GHz): sieve bubble matrix fib 0.216 0.272 0.112 0.364 gcc-4.3.1 0.224 0.272 0.112 0.392 gcc-4.2.4 0.232 0.272 0.112 0.340 gcc-4.1.3 20080623 (prerelease) (Debian 4.1.2-23) 1.888 2.184 1.596 2.512 llvm-gcc 4.2.1 (Based on Apple Inc. build 5546) The good part is that gcc-4.2 and -4.3 don't need new workarounds (at least for AMD64; PowerPC looks worse even with gcc-4.1). The bad part is that LLVM is no alternative for plain gcc yet ...

Go Back   Application Development Forum > Programming Languages > Forth

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 08-16-2008, 11:29 AM
Anton Ertl
Guest
 
Default Gforth compiled with LLVM and gcc

I just tried several recent gcc versions as well as a version of
llvm-gcc on the current Gforth development version. Here are the
timing results on an Opteron 270 (2GHz):

sieve bubble matrix fib
0.216 0.272 0.112 0.364 gcc-4.3.1
0.224 0.272 0.112 0.392 gcc-4.2.4
0.232 0.272 0.112 0.340 gcc-4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
1.888 2.184 1.596 2.512 llvm-gcc 4.2.1 (Based on Apple Inc. build 5546)

The good part is that gcc-4.2 and -4.3 don't need new workarounds (at
least for AMD64; PowerPC looks worse even with gcc-4.1).

The bad part is that LLVM is no alternative for plain gcc yet (at
least in this version). A contributor to the low performance is that
dynamic code generation is disabled, because a configuration test for
it failed. This is due to the funny representation of
labels-as-values, that also breaks SEEing primitives: labels seem to
be representated by small integers that probably index into a table
that contains the actual code addresses (that does not help
performance, either).

However, there must also be other performance problems. Disabling
dynamic code generation on the gcc-4.3.1-generated gforth gives the
following timings (2-4 times better than what llvm-gcc produces):

sieve bubble matrix fib
0.432 0.632 0.708 0.800 gcc-4.3.1; gforth-fast --no-dynamic

Unfortunately I could not SEE the primitives, and therefore don't know
what else is amiss.

Some other curiosities are that llvm-gcc complains about the following
line:

Address code_here=NULL+CODE_BLOCK_SIZE;

(where CODE_BLOCK_SIZE is a constant) with this error:

../main.c:179: error: initializer element is not computable at load time

That was easy to work around, and it remained the only such problem.

llvm-gcc also does not work with libtool in the way that we use it (we
might be able to fix that, but given the other problems it seems
pointless).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008: http://www.euroforth.org/ef08.html
Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 03:27 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.