Chris> Indeed weird. I figured using more advanced features of the
Chris> MIPS architecture might help, but in this case I guess they're
Chris> getting in the way.
The biggest problem, of course, is that we're dealing with compiler
optimization. That's only going to buy us so much; the optimizations
that are done there aren't typically going to be going to be such that
we get a great performance boost in one processor, and then suffer
loss on another... they try to keep things relatively win/win so
anyone with any relatively recent processor can benefit from someone's
build.
Our application is a bit more specific than usual :-)
Chris> Is the -o32 -mips -O3 version the one currently in circulation?
Chris> If not, I'd like to get a copy to test. Out of curiosity,
Chris> which IRIX version and machine did you compile on? Could it be
Chris> possible that the -mips4 might run better on an O200 versus the
Chris> Onyx?
By the way, my workstation here is running IRIX 5.3. Does anyone need
an IRIX 5 client? If so, and either Justin or Guy don't have access
to an IRIX 5 box, I'll get the sources from Rocke and do a build.
Also, I think I got a little delete-happy earlier when looking at the
SGI optimizations that were done, but I don't remember seeing these
guys:
GCC 2.6:
-mcpu=r2000
-mcpu=r3000
-mcpu=r4000
-mcpu=r6000
-mips2
-mips3
SGI CC
-mips1
-mips2
crap ... I can't find my manuals for the darn thing. Anyway, we might
want to see if it makes any signficant difference if we try to
generate processor-specific clients for IRIX. (-O2 might or might not
do a whole lot, but if we can also tell it to generate MIPS II
instructions, we might find a significant speedup on processors that
deal with that instruction set. I believe both CC and GCC default to
MIPS I (i.e., R2000) instructions.)
-- Matt Curtin Chief Scientist Megasoft, Inc. cmcurtin@research.megasoft.com http://www.research.megasoft.com/people/cmcurtin/ I speak only for myself Death to small keys. Crack DES NOW! http://www.frii.com/~rcv/deschall.htm