Avi Bryant writes:
 > Yes, in some quick profiling I did that was a major hotspot (mostly due 
 > to Float>>negated, for some reason).  The other one was 
 > ByteArray>>detectMax:, which I'm pretty sure you can easily get rid of 
 > - just keep track of the maxLength as you put items into the lengths 
 > array in the VorbisCodebook, and you won't have to look for it each 
 > time.
 > 
 > I also wonder whether using FloatArray in some cases might be useful, 
 > where Array is used now?

Damn, I didn't realise that Ogg used Floats rather than just
integers. That will make compiling a little harder.

Purely blue-sky, if it was switched to a FloatArray and the compiler
had a general way to guess the type then compiling would be reasonably
easy. Maybe call Chuck to find the type of the receiver variables to
at: and at:put: messages.

The risk is the types could change between when Chuck is executed and
when the compiled code is executed. By optimising for Chuck's types
with a slow general send when the type changes this shouldn't be
critical. The generated code would look like that generated by a
system with type-feedback.

Knowing that the array was a FloatArray and that the arithmetic should
be optimised for floating point rather than integers would make it
reasonable to compile for.

So long as the floats are only single precision. I want to deal with
the x86s floating point stack, and my CPU only has SSE, not SSE2.

The same effect could be generated by using type-feedback to detect
the array was a FloatArray and a trivial type-inferencer to keep the
floats out of boxed objects. But that would require most of the
machinery needed for feedback driven inlining.

Looking closer, there is always the chance that it would need to
be inlined for performance. Inlining could be done in Smalltalk
but it would make the code ugly.

Bryce