[partitionpenguin]

Sure, here is a tarball of the source, it includes the binary in it, but i've also attached it alone to the post. I'm not sure if it will work on its own really, but I guess it's worth a shot.

https://drive.google.com/file/d/1mnCq0fT...sp=sharing

Raion, I don't think it's so much of an IRIX or MIPSPro optimization issue, I'd trust that GCC is doing decent optimization actually, but I bet it's more that the code is not optimized for the graphics hardware. Perhaps it uses certain GL calls that are slower on SGI hardware but negligible on other systems, something like that - there's also graphical glitches with it that can be resolved. Drmadison said he was looking at it but he hasn't responded to the forum post yet. I'd like to keep it on RSE ideally for the moment because that would mean it could get packaged as an RPM and I think that would be a nice solution. But maybe MipsPro is worth a shot too.

I'm going to avoid turning this into a debate over optimization, but let me explain my methods:


MIPSPro has features GCC does not. In particular, the -TARG function. You can specify a processor or platform (IP board) to specifically compile against. I'm not 100% clear on platform, and that appears to have a far less prominent effect, but basically:

By default, even if you crank -O3, MIPSPro omits some processor-specific opts. So if I specify TARG:proc=r10000 it will enable R10000 specific features 

GCC does NOT have this flag. So you're basically betting generic optimizations against CPU-specific opts. Someone with more experience can tell me if platform= would enable graphics-specific opts. 

Another benefit - MIPSPro's optimizer does have some bugs, but there's a workaround (all optimizers can sometimes break things, that's why they tell you to avoid -Ofast because that breaks float) the -OPT flag can set a procedure size, above which it will leave alone. -OPT:limit=n is the function there. There's other things too. GCC probably has something like this, but GCC documentation is a rat's nest. 

I'm not sitting on my ass being a MIPSPro zealot, despite how people idiotically tend to portray me. I'm simply pointing out facts. If you think a few nonscientific metrics, from me, or from someone else, can conclusively prove it, that's untrue. These are all personal attestations. 

As for the code not being optimized for the graphics hardware, that's still entirely possible. As others pointed out, that star flipping issue is an example of GL calls that don't exist on IRIX. 

But, for games in particular, and Gijoe77 can attest:

He ported dgen-sdl a while ago. The MIPSPro C/C++ build did FAR better than the one with GCC 4.7. And in my completely unscientific tests, GCC 4.7 and GCC 8.2 on IRIX for C code does virtually identical for things like pixz, pigz, bash etc. 

Other code, it just depends. Some things GCC does about the same or a little better, but games is not one of them. I have a visualboyadvance build around here that did better, as did gnuboy or cingb, I forget which.

I know about the target flag, but you completely dismissed my point about OpenGL calls. I'm not sure why you like to assume everything is related to GCC, no one has even bothered looking at this GL backend which is running on hardware that is probably completely different than what the designers of the backend were expecting (Windows 95/98 with OpenGL I think). There's no reason to assume this code which was (by my own admission) hacked together to run on IRIX would have good performance over the compiler itself being able to optimize it.

It would be one thing if graphics specific optimizations were applied that way, in that case I'm genuinely curious how that works, but aren't those things already compiled and linked into libGL on the CPU side? It's not like there are shader compilers for SGI hardware either so, I'm not really sure how that would factor in.