[squeak-dev] Re: Why FFI is not included with latest squeak ?

Lawson English lenglish5 at cox.net
Sat Aug 18 03:27:23 UTC 2012


On 8/17/12 1:21 PM, Yanni Chiu wrote:
> On 17/08/12 2:46 PM, Lawson English wrote:
>>
>> Which is a huge downside to the current implementation of NativeBoost,
>> although, in theory, you could create a version that would compile to C
>> via slang rather than using Igor's x86 assembler syntax.
>
> But it's called *Native*Boost. Are you suggesting non-native boost? 
> Wouldn't that be Cog/JIT?
>
>
>
>

The difference is that you have full control of what is going on. Cog 
has to make *some* assumptions, including the one that it can release 
memory for the JIT-ed compiled method if it hasn't been called lately. 
But what if the speed of that method, no matter how seldom it is called, 
is essential to the proper functioning of your application?

Also, a more common situation is simply that the overhead of boxing and 
unboxing of floats is going to make things unusable in a practical 
situation. For example, the speed of  the inner loop of a mandelbrot set 
generator is many dozens of times slower using Cog than the same loop 
implemented in C as an external library. Since the "dwell table" of a  
1000x1000 pixel image of the entire set can be generated in 1/10 of a 
second using the naive M-set code written in C, you don't need to worry 
too much about the VM stalling if that loop were implemented using 
NativeBoost. Of course, for any arbitrarily "deep" render of the set, 
you still need to work with the set via an external library running in 
its own thread or process because such images can take days or even 
years to fully render.

A more interesting usecase would be implementing robust raytracing or 
physics for a Cobalt-like/Croquet-like application or even a normal 
standalone 3D game.

What I am suggesting is that a simple slang to C compiler could be 
implemented in Squeak which injects native bytecode into a 
CompiledMethod object in the same way that NativeBoost does, which would 
give you almost as much control as the NativeBoost assembler, and which 
would work even if the compiler hadn't yet been implemented in a 
specific platform. It could be added later as a plugin.

In theory, such a beast could be implemented in a few days or weeks, 
even by someone like me, by simply passing the properly pre-processed 
Slang code as arguments to the gcc compiler and then injecting the 
bytecodes in the same way that NativeBoost does. This, of course, would 
be horrible for anything but a proof of concept but I think Igor says 
such a thing has already been done by some students somewhere.


L

-- 
Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner).
https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all



More information about the Squeak-dev mailing list