Re: [9fans] GUI toolkit for Plan 9

[Eric Dorman <edorman@san.rr.com>]

Who said something about feeding the troll?  Hehe.
I'm in a benchmarky mood since I'm doing the same thing
in baselining our project code in my day job.  

Anyway here's a sort-of integer-ish comparison:

Test case is the ancient Little Smalltalk v3.  The benchmark
is running the compiled interpreter on multiple iterations 
of the test suite.  All tests passed (such as they are :) ).  
This is mostly indexing, switches and indirections.  FP is 
also a test case but the impact of the bytecode interpreter 
is far more significant.

On Plan9, the interpreter use bio(2) so compiles directly under 
8c rather than ape (a port done by myself).  There are no other
changes from the Linux code.  For gcc the environment was 
RH-Linux-7.2 running w/o gui.  The hardware was a 2xP-III @ 1.0Ghz.  
Plan9 netbooted onto the same hardware.  I/O was not tested.  
The application isin't multithreaded so any SMP overhead is 
the OS's own fault :) .. gcc-3.0.3 and -2.96 were used, with 
no significant differences in the results (except as noted).  
-mcpu=i386 was used for all gcc's (note 'i386' vice '386'; see 
gcc -dumpspecs).  With other interpreters (like Squeak Smalltalk,
which gnu-ifies the interpreter to exploit gcc-isims)
playing with -mcpu can get you 2-5% but there is a lot of
coupling between architecture, -mcpu, -O level and etc.  YMMV.

Generally gcc -O was 3% avg faster than 8c for all iteration 
sizes.  gcc -O2 was 7% avg faster than 8c for all sizes.  
Higher -O levels had no significant impact. 

8c -N was 17% slower than 8c.  Oddly gcc-2.96 was 33% slower 
than gcc -O.  gcc-3.0.3 was better, 13% slower than gcc-3.0.3 -O.

Time-to-compile is hard to compare since Linux runs on the local
ATA100 disk while Plan9 runs from a fileserver on switched 
100BaseT, and there really isin't all that much code to 
compile :)  Anyway gcc-3.0.3 clocks in at ~ 3.2 secs ( -j1 ) 
while Plan9 compiles in about a second (NPROC=1).  I don't have 
much faith in these numbers, however; too much variance.  Then
again, gcc-3.0.3 takes > 7minutes to compile itself (all stages 
plus library) -j2, but 8c takes a few seconds at NPROC=2.  My
experiences with gcc have led me to put little faith in the stage[12]
exercise as a verification tool.

IMHO the real deal is whether it's fast enough to do what you want
it to do.  No doubt 8c would benefit if it had the same zillions 
of both paid and unpaid hours gcc has, but that's not saying 
anything earth-shattering; for this particular app it does reasonably
well, IMO, given the level of effort put into it.  If somebody 
wants 8c to go faster then they are welcome to turn the crank 
to make it happen....

Regards,

Eric.