[Scummvm-devel] templates, visuals, getDevices()

[Matt]

On Tue, 3 Mar 2009, Joost Peters wrote:

> Max Horn schreef:
>>>> Maybe if you tell us what errors you get, with which compiler, we can
>>> I was aware of the proper class names, but those forward declatations
>>> were the only way I've found so far that made the compiler in
>>> question (SGI MIPSpro) happy.
>>
>> My first thought is: Gee, yet another buggy compiler :-). One approach
>> to solve this problem is to switch to GCC, e.g. maybe this one works: <http://freeware.sgi.com/cd-2/relnotes/gcc.html
>> > or the 4.2.3 gcc provided by pkgsrc: <http://mail-index.netbsd.org/pkgsrc-users/2008/02/19/msg000417.html
>> >.
>
> While compiling with GCC certainly is an option (it's what I use since I
> don't have MIPSpro), the code that is produced tends to be less well
> optimized than that generated by MIPSpro, and on low-end hardware, this
> is the difference between ScummVM running acceptably or not.
>
> To that end, it would be nice if we could find a non-invasive workaround
> to get MIPSpro working again.
>
> OTOH, I've only used GCC3, so perhaps 4 produces considerably faster code..

GCC 4.x may or may not produce better code for the MIPS CPU you are 
targeting. There are some things that some people I know have done to get 
good performance from GCC-compiled programs on the PS2:

1. Favor -Os over -O2. The cache on the MIPS CPU in the PS2 is retardedly 
small, and the cache misses can be a major drag.

2. Generate runtime profiles using -fprofile-arcs on a non-embedded 
platform, and then feed the profiling data back into GCC when you are 
cross-compiling for your embedded target. This helps reorder branches, 
functions, and segregate out lesser used code. This increase in locality 
can be a big boost on cache-limited platforms like the PS2. Note that if 
you do more than reordering, you should really exercise all the game 
engines decently. Like, say, making every supported game go in-game. 
Anything not captured in the runtime profile will not necessarily perform 
worse, but it definitely won't perform any better.

3. In lieu of the Link Time Optimizations that will be part of the next 
GCC, there is a way to get a similar effect. For each directory, make a 
.cpp that #includes all the other .cpp files in the directory. Then 
include all of those "meta" cpp files into one big .cpp file. Get that 
file compiling (there can sometimes be name collisions if people are using 
'static' and other globals). If there are entry points, they need to be 
marked as such. This allows GCC to optimize across the entire 
program at once, instead of a unit at a time. Besides yielding a smaller 
binary (in my experience), the constant folding and tree optimizations in 
GCC 4.3 and above can do a really great job.


The simplest thing would be to use GCC 4.3.x and -Os to see if that gets 
you the performance you're looking for. If not, try these other, deeper 
suggestions.

I hope this helps!

--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt