[Pharo-project] Status of Alien FFI

Stefan Marr pharo at stefan-marr.de
Sat Sep 19 04:41:47 EDT 2009


On 19 Sep 2009, at 08:46, Igor Stasenko wrote:

> Lua is SLOW :)

> But still - you can go and see the speed comparison of different
> numerical algorythms implemented in different languages.
> Squeak leaves Lua far behind..
That sounds like FUD.
But, maybe I misunderstand you here.

However, Lua 5.x is FAST, especially for an interpreted language. Its  
register-based implementation seems to be much better for  
interpretation in terms of speed than the stack-based bytecode in  
Squeak.

See: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=squeak&box=1

And: Virtual Machine Showdown: Stack Versus Registers
Yunhe Shi and Kevin Casey and M. Anton Ertl and David Gregg
ACM Trans. Archit. Code Optim.4(4):1--36(2008)


Best regards
Stefan

> Especially, i think, if you use language for scripting, so scripts
> will tend to contain more logic than heavy numeric crunching (because
> for numerical crunching hardcore devs using C & GPU) - smalltalk will
> win even more.
>
>> Stef
>>
>> On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:
>>
>>> 2009/9/18 Stéphane Ducasse <stephane.ducasse at inria.fr>:
>>>> yes this is one of my dream but ....
>>>> I'm not good enough to make it come true.
>>>>
>>>
>>> Lua is specifically designed from the very starting to live well as
>>> embedded system, written in C. No wonder that its having very good C
>>> interoperability.
>>> And that's why, at the time i found the smalltalk, first thing i
>>> thought, that
>>> creating an interoperability layer between C and smalltalk will
>>> unleash its potential
>>> for use in scripting.
>>> Unfortunately, almost every implementation i found & read about
>>> smalltalk vere designed as a
>>> self-sustained (or self-sufficient) sandboxed environment with a
>>> little care about host interoperability in mind.
>>> Even existence of FFI in Squeak doesn't changes that, because Squeak
>>> VM architecture
>>> as well as language-side design prevents you from controlling
>>> interpreter from outside.
>>> A less painful way for achieving a kind of embedding, as Andreas
>>> mentioned, that you can write the
>>> plugin which using callback machinery and create an image which  
>>> simpli
>>> 'listening' for calls from outside
>>> then handle them and put response back.
>>> But i can't tell, how efficient it could be comparing to Lua  
>>> scripting
>>> interface.
>>>
>>> For instance, if i would want to enable the dynamic primitive
>>> publishing (which host application may want to
>>> use), then this would require VM changes.
>>> That's why i proposed , some time ago, to modify the VM internal
>>> infrastructure to have a kind of namespace,
>>> which is dynamically built-up using associations of symbols (C
>>> strings) with some pointer/values.
>>> Then you can publish primitives at any time you wanting to, replace
>>> them at run time and do many other
>>> kind of tricks, which is possible, when function pointer is not  
>>> bound
>>> at compile time, but discovered by VM
>>> at run time. At some point we could even use a JIT to generate the
>>> primitives and then let VM to pick them up at run time.
>>> This means, that at some point you could JIT everything you need,  
>>> and
>>> replace the C-compiled VM stuff after booting the
>>> image, and from now on, VM is not something which is made from stone
>>> like all C-compiled binaries. So different
>>> images could carry own system inside which, once its booted up, no
>>> longer needs the statically compiled crap.
>>> This also means, that by having a good JIT and VM tuned for this, we
>>> don't really need writing any C code anymore, because
>>> main reason why we doing this is speed and easy interoperability  
>>> with
>>> host environment. :)
>>>
>>>> Stef
>>>>
>>>> On Sep 18, 2009, at 6:40 PM, Lawson English wrote:
>>>>
>>>>> Johan Brichau wrote:
>>>>>> On 16 Sep 2009, at 20:37, Ken Treis wrote:
>>>>>>
>>>>>>
>>>>>>> * I'm creating a partial Alien library for GemStone so that I  
>>>>>>> can
>>>>>>> use the CairoGraphics package in both Pharo and GLASS. But on
>>>>>>> x86-64, there there's a size difference between a pointer/long  
>>>>>>> and
>>>>>>> an integer. It'd be nice to have some more explicit APIs on  
>>>>>>> Alien,
>>>>>>> so I could say "Alien newCInteger" or "Alien newCLong" and have
>>>>>>> the
>>>>>>> platform return me the proper size Alien. Even without the
>>>>>>> platform
>>>>>>> size differences, it seems awkward to use "Alien newC: 4"
>>>>>>> everywhere
>>>>>>> I want an integer, "Alien newC: 8" where I want a double, etc.
>>>>>>>
>>>>>>
>>>>>> Exactly.
>>>>>>
>>>>>> It becomes worse once you start having structs and nested structs
>>>>>> or
>>>>>> structs with pointers to structs ;-)
>>>>>>
>>>>>> I'm using Alien as the FFI to port JavaConnect from Visualworks  
>>>>>> to
>>>>>> Pharo/Squeak. As you say, it is a pain to work at such a low- 
>>>>>> level
>>>>>> compared to the DLLCC in VW. I am planning to do some work on
>>>>>> creating
>>>>>> a higher-level interface for it such that we can operate it as  
>>>>>> you
>>>>>> mention, including the correct bytesizes for all platforms.
>>>>>>
>>>>>> At the moment, I'm mostly focusing on getting the port to work
>>>>>> right
>>>>>> before I start creating an interface on top of the current Alien
>>>>>> interface.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Something to keep in mind is the need for a straightforward way of
>>>>> going
>>>>> the other way: John Mcintosh's port of the Squeak VM to iPhone
>>>>> implies
>>>>> that the same thing could be done in other Lua-ish situations,
>>>>> allowing
>>>>> people to use smalltalk syntax for game scripting. With the right
>>>>> libraries for an IDE, I would think squeak could be very
>>>>> attractive to
>>>>> at least some people in place of/in addition to using Lua.
>>>>>
>>>>>
>>>>> Lawson
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> Pharo-project at lists.gforge.inria.fr
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- 
>>>>> project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project at lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- 
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax:   +32 2 629 3525





More information about the Pharo-dev mailing list