> Why is the FreeBSD Rotor version so slow? If it is a Rotor thing, then
the device might need lots of cycles; if the CLI uses an interpreter instead
of JIT, it seems like it might have to be a very fast interpreter.
If you break down the overhead I would assume it's coming from the
Activation process where code is being loaded, and then jitted for the first
time, as well as the overhead of the GC and the PAL, but I would have a hard
time thinking that Rotor and other similar VM's would require super fast
processors to work reasonably on the type of applications you would want to
run on an embedded device.
I can't imagine the overhead would be coming predominantly from the clock
cycles of the EE itself, maybe it's the inefficiencies of the PAL that you
are noticing as opposed to the inefficiencies of the EE itself.
Memory on the other hand is definitely a biggie.
Consequently you definitely wouldn't want to use a Switch Loop Interpreter,
that would indeed be very slow, but there has been quite a number of
advances in the Smalltalk Community with respect to high performance Virtual
Machine Interpreters.
With respect to Rotor I am a little more worried about the size of the Rotor
implementation of the VM and the minimum required libraries to get a simple
program running.
A while back I saw a talk on the Compact Framework and the presenter stated
that the CE implementation was designed from the ground up for the embedded
device profile meaning the data structures used to implement the EE, the set
functionality with respect to instructions provided by the EE itself, the
chosen libraries were all based on scenarios of a small device context which
could then fit on the potential resources provided by the embedded device.
I see the some of the potential MODs as the following:
1. Custom Jitter to an "internal" Single Byte Instruction Set
2. Threaded Code Interpreter
3. Obvious pruning of the libraries
I don't know the details of the CE CLI implementation to know if they chose
a different object representation to cut down on the per class space
overhead.
Personally I am very interested in seeing more information on what some of
the MODS should be to get Rotor to run on a small scale system for example
P3 600, 32 MEGs of RAM and a 4 GB hard drive.
Yahya
