goran at krampe.se writes:
 > ...can be found over at Lambda:
 > 
 > http://lambda-the-ultimate.org/node/1277
 > 
 > The presentation is from a game developer and was quite interesting to
 > look through (the slides are pretty self explanatory). It would be very
 > interesting to hear the reactions on these issues from a Squeak
 > perspective - like what do the Croqueteers say and what do you say
 > Bryce?

I doubt that we need any language changes for scalar numeric
performance. Loop counters should be optimisable via induction
variable analysis and floating point calculations can be made fast so
long as the float isn't converted into a full object which is possible
if it's stored in a floating point array.

For logic it's also possible to be fast enough. Such code is likely to
be branch heavy, so even if Squeak executes a few more instructions it
might not be any slower.

I'm not sure what the best way to structure the code for explicit
parallelism. For numeric work, it's possible that vectorisation will
expose a lot of instruction level parallelism. My hunch is the best
bet would be to provide most of the language level support from inside
the image keeping the VM level parallelism very simple. Different
problems are likely to require different programing styles to manage.

There are a few issues with parallelising the current Squeak/Exupery
system. One is making sure that PICs can be updated, or providing a
separate code cache for each hardware thread. The GC is also an
issue. So's the image which is likely to contain races with
OS/hardware threads. All of them should be resolvable.

Given funding, performance will not be a problem.
Bryce