[Pharo-project] Status of Alien FFI

Stéphane Ducasse stephane.ducasse at inria.fr
Sat Sep 19 04:53:19 EDT 2009


ok I saw smalltalk squeak
but then how do you interpret the graph?

On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote:

>
> 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
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list