[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
|