Cryptographic Primitives

bryce at bryce at
Fri Oct 6 22:41:44 UTC 2006

J J writes:
 > Also it would be interesting to hear Bryce's input on this.  Speeding up now 
 > is good, but if the JIT turns out fast (as it sounds like it will) then we 
 > would want as much as possible to be pure smalltalk, no?

For now, if you've got a demonstratable need for speed write a 
plugin. Exupery is not yet ready for production use.

I've a few ideas that should allow Smalltalk to run at the same speed
as C for both floating point and 32 bit integer work. The general case
needs SSA based optimisation which is years away. However there's an
interesting special case that could be implemented now.

The cost for both floating point calculation and 32 bit integer work
is object creation.

In the expression:

   x := a + b + c + d

You only really need to create one object to hold the result. To
optimise this you just need to know that a, b, and c are floats (or 32
bit integers). This can be read from the polymorphic inline
caches. Exupery does this now to optimise #at: and #at:put: for
different types. Then you need to remove the redundant conversions
into Squeak floats (boxing) then back into machine floats (unboxing).
The removal can be done by a simple tree travesal, there's a little
bit of complexity in case "a" is ever something other than a float.
Exupery does this to remove the overhead of booleans in expressions
such as "a < 10 ifTrue: [...]".

To optimise the use of floats or 32 bit integers inside a statement
you need to be able to dynamically inline primitives and to do simple
optimisations involving tree traversals. Exupery does both of these
now. What's missing is an implementation of either floating point
values or 32 bit integers for Exupery.

So removing the overhead for floats and 32 bit integers inside
statements is easy. Removing it across statements is harder. That
requires proper program analysis. That unfortunately will involve
waiting for Exupery 3.0. 

I'm interested in Hans-Martin's Squeak implementation of DES in Squeak
as something to look at compiling. However for now I'm focussing on
regular code.


More information about the Squeak-dev mailing list