[Pharo-project] Status of Alien FFI

Stefan Marr pharo at stefan-marr.de
Sat Sep 19 05:11:02 EDT 2009


On 19 Sep 2009, at 10:53, Stéphane Ducasse wrote:

> ok I saw smalltalk squeak
> but then how do you interpret the graph?
Well, the graphs are... creative...
At least not intuitive.

Change one of the languages to C, then you will get a feeling for what  
they try to express.
If the first language, you base for comparison, is faster it uses only  
a fraction of the time the other language needs. The bar will be below  
the one-line. If its slower, the ratio is higher, it uses x-time the  
time the other language uses.


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