Hope nobody finds this annoying. Somehow I missed this message when
it was originally sent, but I thought my reply might be useful to
sombody.

Jim Freeze wrote:
>On Tuesday, 2 September 2003 at 4:48:58 +0900, Steven Lumos wrote:
>> Maybe you're using the wrong Sun:
>>
>> $ time ruby tail # blind gcc compile
>> 499999500000
>>
>> real 0m3.943s
>> user 0m3.910s
>> sys 0m0.000s
>
>What do you mean wrong Sun?
I mean a Sun that is slower than my Sun. :-) If I posted Intel numbers
that didn't make sense, people might be likely to wonder whether I was
using a 486. I wonder something similar about the Sun numbers. In my
case, the "right" Sun happened to be an 8-way 4800 with 72GB RAM.
That's absurdly big just because I can, but the numbers are almost
identical on a Blade 2000 with 1 CPU and 1GB RAM, which is what I
would consider to be a pretty good minimum for anyone claiming to be
running a modern Sun.
>> or the wrong compiler:
>>
>> $ time ruby tail # Sun compiler with optimizations[1]
>> 499999500000
>>
>> real 0m1.608s
>> user 0m1.590s
>> sys 0m0.010s
>>
>> Of course, some people care a little more about IO than addition!
>
>Have you tried to get the same performance with gcc?
I haven't, and I wouldn't be surprised to find that it isn't possible.
The GCC guys have (understandably) spent a lot of time on Intel
optimization and a little time on Sun optimization. There have even
been serious bugs in Sun optimization in recent times.

But I bet you could get a lot of improvement just enabling the full
instruction set (-mcpu=ultrasparc (?)). By default, it compiles
something that will run on old SPARCs with the legendary abysmal
integer performance, so no wonder that the addition benchmark seems
slow.
>Do you have a process for building Ruby with the
>optimizations below?
Just set those in your environment (except I forgot CC=cc) and
configure. Note that if you want 64-bit code, you have to have all
libraries built 64-bit too. 64-bit can be a pain sometimes so it might
not be worth it to everybody. It's worth it to me because I have a
machine with (recently upgraded to) 96GB of RAM*. I'm pretty sure you
can get the UltraSPARC instruction set in a 32-bit binary by removing
the getconf parts and the -xarch=v9. If you have the Sun compiler
tools installed, you should have documentation in
/opt/SUNWspro/docs/index.html. There is a "C User's Guide", which is
what I used to come up with the recipe.
>> [1] CFLAGS="$(getconf LFS64_CFLAGS) -dalign -fns -ftrap=%none
-nofstore
>> -xbuiltin=%all -xtarget=native -xarch=v9 -xO5
-D__sparc_v9__"
>> LDFLAGS="$(getconf LFS64_LDFLAGS) -L/opt/SUNWspro/WS6U2/lib"
>> DLDFLAGS="$(getconf LFS64_LDFLAGS) -L/opt/SUNWspro/WS6U2/lib"
>> LIBS="$(getconf LFS64_LIBS) -lfast"
Speaking of benchmarks, how about using the time Rubicon takes to
compare different platforms?

Steve
[*] Funny how I never cared about 64-bit until recently. :-) I never
cared about native threads until recently either.