Squirrel

Hi everybody,

We prototyped an application on the PC where it runs perfectly fine then moved it to the Wii.
The said application is fully written in Squirrel (with a lot of low-level grunt work binding to the engine).
Problem: More than 70% of a 60hz frame is spent in SQVM::Execute() with 30% in SQVM::Get() on the Wii.

Now this console has a rather painfully slow CPU but I did not expect such a dramatic hit on performance.
My UMPC with a Celeron ULV 1Ghz hardly reaches 1.0% of CPU usage executing the scripts of the same application.

I double-checked everything, made sure memory allocations were done from the right (the fast MEM1) memory pool, etc...
But, out of luck, I am posting here hoping that somebody with a similar prior experience might have a good tip or two.
Otherwise I will port the scripts to native C++ and the problem should be gone.

Thanks

Ps: I am using Squirrel 3.0ALPHA1.

mmh, unfortunately I don't know much about the Wii other than the specs. However I know for Square-Enix released the last Final Fantasy Crystal Chronicles on the Wii and they say is mostly written in Squirrel. Maybe if someone at Square-Enix is reading this.... :) ?

One thing I can think of is that you compiled squirrel in debug mode, interpreters are extremely slow in debug mode(20x slower+) as they have very hot spots(like SQVM::Execute); to the point that even on PC running our game with squirrel in Debug gives a noticeable slowdown, we keep it in release also in debug builds(with the assumption that there are no crash bugs in squirrel).

Does wee run 64bits? if so, is squirrel compiled with _SQ64? otherwise you could have some memory misalignmet problem that on PowerPCs could impact your perfs, but this is pure speculation.

Alberto

Yes, the problem may be very hard to trace since the Wii is not a public development platform.
Unfortunately I am not an expert with CodeWarrior but the huge difference in performances made me think of an unexpected Debug build as you suggest. That did not seem to be the problem however as a real debug build is indeed much slower (>1500% of a 60hz frame spent in SQVM::Execute()).

CodeWarrior seems to be generating acceptable code as the rest of the engine performs as expected. But I also have been using Squirrel for close to 3 years now and I know it is efficient and very well built.

So, I'm pretty stuck with the VM at the moment. My guess is that something is going completely wrong, either with the memory access pattern or the compiler itself. Maybe it is time I looked through the assembly code generated and see what is going wrong exactly.

I'll post progress here for reference.
Thank you for the fast support as always.

Just to know...

What is the one structure (if there is such a thing) that could benefit from hand padding in order to ensure proper memory alignment?
The memory allocator I use takes care of aligning malloced blocks but Squirrel may allocate big chunks of memory then layout small data chunks in it directly.
I remember having to pad quite a few structures by hand on the Playstation 2 with CodeWarrior a good number of years ago to get back a few % of the CPU.
There might be something to do on this front...

So, I wrote a profiler for the VM using the Squirrel debug hook and was able to fix a good number of critical spots in the scripts. By rewriting the costly parts as I would write assembly and avoiding a few mistakes proper to Squirrel I reduced the VM usage on the Wii from 80% of a 60hz frame to about 14%, not bad. Here is a quick summary of what I did:

• Replacing if (v == n) {...} else if (v == m) {...} ... sequences to the much faster equivalent switch(v) statement.
  
• A large number of function calls where made by building a Vector(1, 1, 1) as a parameter. Refering to a global g_unity_vector instead shaved a good 10% CPU usage from the VM. Now, the newly supported default argument feature is the best alternative to this problem as the default argument would refer to the same already constructed global object. The API did not support this back when I wrote the initial binding code however.
• foreach(i, v in array) is surprisingly slower than array[ i ] in my case.

The other thing that probably got out of sight when writing this prototype code is that the Squirrel compiler does not perform much optimisations so there seem to be no dead code removal, no expression factorisation, etc... So keeping that in mind, especially when dealing with redundant expressions involving array/dictionnary accesses, is very important.