Perhaps by the time we get to GCC 3.95 we might be able to beat 2.95's performance. ;)
I'm way below the experience curve too! DaR > -----Original Message----- > From: Joel Rees [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 09, 2002 6:54 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; Dennis Ruffer > Subject: Re: [gforth] OS X 10.2 builds and benchmarks > > > > Dennis Ruffer wrote: > > > > > > Again, I don't see any difference with the -fno-gcse flag > (yes, it is in > > > both Makefiles), but the -D_POSIX_SOURCE flag does allow > engine/signals.c to > > > remain unchanged. > > > > So, it's a puzzle! > > Not really. > > First, most of the operations here are integer. If we're talking two > cycles for a move or add, it's two cycles. Interrupt latency, > the vector > unit, and other such issues won't come into play with the > test programs > you're trying to use as benchmarks. > > Second, the primary determinant is how well the high-level > instructions > will map to the low level. With GCC 3, there's apparently > another level of > symbolic representation being inserted. All architectures > have suffered. > (Don't forget that gforth has to depend on GCC's ideas of > optimization. > > Third, there are a lot more programmers with experience > optimizing code for > the iNTEL architectures than with experience optimizing for PPC > architecture. Unfortunately, it takes, not just a lot of > experience, but > a _whole_ lot of experience before you quit focusing on easy > optimizations that really don't buy you much in real code. > > > Surely it's not the difference between G3 > > and G4? > > Oh, yeah, there's that too. The pipelines are different, G4's is > optimized towards allowing vectorization, so integer routines > that have > a lot of branching will take something of a hit in the > hardware. Unless > you figure out some way to profitably vectorize the inner interpreter > <wink/>, you're just going to have to get the inner interpreter out of > the way or expect sub-optimal performance. > > (I wish I could help with that project, but I don't have either the > experience or the time, I think.) > > > > Also, the switch to gcc2 can be done > right in your > > > gfconfig files by simply specifying: > > > > > > env "CC=gcc2 ..." > > > > Thanks, for the info! > > > > > On my G4/1GHz, 133MHz bus, 256KB L2 cache, 1MB L3 cache, > 512MB RAM, I get: > > > > > > sieve=1.39 bubble=1.49 matrix=1.01 fib=1.98 > > In an ideal world, the compiler might be able to vectorize all four of > these for the G4. I don't know how well GCC 3 is able to pick up on > vectorizable operations for CPUs with vector processors, but I suspect > it does not do so well. Even if it did well, getting gforth to > communicate the vectorizability of the code to the GCC > back-end might be > quite a trick. > > -- > Joel Rees <[EMAIL PROTECTED]> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
