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

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 23 19:47:36 UTC 2010

On Tue, Mar 23, 2010 at 11:41 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

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

Not over and above what already exists in an FFI.  One can arrange that one
alloca's close to what is needed for a given call, not simply some maximum
on every call.  So when done like this alloca takes only a small percentage
more than one would allocate for a normal call, and certainly less than a
factor of two for a call with a large call frame.

In my reimplementation of the FFI the first time an FFI method is run the
alloca is 16kb plus the size of the struct return, with the call failing if
this isn't enough space.  The code then calculates how much of the 16k was
actually used and caches this in the FFI method's ExternalFunction object so
next time it alloca's only what's required.  Actual overhead is greater than
the alloca because one has to allow for the plugin function's invocation and
its local variables.  Even if the total overhead for a call were to reach
32k bytes one would have to have a deeply nested series of call-outs and
call-backs before one was in danger of overflowing a typical 1Meg/thread


> Nicolas
> > 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
> >>
> >
> >
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100323/7e09a34f/attachment.htm

More information about the Squeak-dev mailing list