[squeak-dev] Re: Trying to load ALienOpenGL into 4.1 alpha...

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 23 18:41:19 UTC 2010

2010/3/23 Eliot Miranda <eliot.miranda at gmail.com>:
> On Mon, Mar 22, 2010 at 9:21 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>> On 3/22/2010 7:27 PM, Lawson English wrote:
>>> Croquet OpenGL is dependent on all sorts of things. Have you managed to
>>> get Croquet working in a modernish version of Squeak/Pharo?
>> I can probably whip one up fairly easily. The actual dependencies are
>> rather minor - all you need to do is drop the positional argument variants
>> (we've thrown these out in our own images too) and load the FFI first.
>>> Also, I was under the impression that Alien FFI was faster than the
>>> standard FFI.
>> Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims
>> it have ever ever run an actual benchmark, have you?
>> There is interesting out-of-context quote in the Alien documentation that
>> brings as one of the arguments for Alien something that I said about the
>> FFI, namely that the "FFI is slow ..." but unfortunately it doesn't quote
>> the other half of that statement which is "... when compared to the Squeak
>> plugin interface". That is undoubtedly true in the context of a discussion
>> that compares the FFI and the Squeak plugin interface since the FFI has
>> marshalling overhead that is not incurred by a regular plugin. That said,
>> the FFI isn't slow per se - in particular not when compared with doing
>> marshalling inside Squeak (as Alien does).
>> Put on top that people seem to use Alien in the most naive (e.g., slow)
>> way looking up the functions on each call, and I'd say the FFI will beat
>> Alien in *any* practical performance tests today (and for the foreseeable
>> future). Doesn't mean Alien can't be improved, but the next time someone
>> claims that "FFI is slow and Alien is fast" ask for the benchmark they ran
>> instead of taking the claim at face value :-)
>> The main reason for using Alien today is callbacks. There is still no
>> support for callbacks in the FFI so if you need callbacks Alien is your
>> choice. One of the things that I've got on my TODO list with Eliot is to
>> improve interoperability between Alien and the FFI. It should be possible to
>> pass Aliens straight into FFI calls at which point you could have your cake
>> and eat it, too.
> Right.  I won't stand by the "slow" comment anymore.  I've done a much
> faster version of FFI here that has essentially the same performance as
> Alien.  The important thing is to use alloca to allocate the outgoing stack
> frame and marshall to that. The old FFI code marshalled to static memory and
> then copied to the stack frame.  This makes the old implementation
> inherrently slower /and/ non-reentrant.  Now this is solved FFI is
> essentially as fast as Alien.

Naive question: is there any potential stack overflow problem with alloca ?


> The advantage FFI has right oer Alien call-outs (as opposed to Alien data
> representation) is more typing and so a better chance of dealing correctly
> with RISC calling conventions.  So the clear path is to merge the data
> management side of Alien into FFI and extend FFI with true callbacks, a la
> Alien.  We then have the best of both worlds.  That's something I want to
> get done this year, e.g. as part of the GSoC.
>> Cheers,
>>  - Andreas

More information about the Squeak-dev mailing list