<br><br><div class="gmail_quote">On Mon, Mar 22, 2010 at 9:21 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 3/22/2010 7:27 PM, Lawson English wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Croquet OpenGL is dependent on all sorts of things. Have you managed to<br>
get Croquet working in a modernish version of Squeak/Pharo?<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I was under the impression that Alien FFI was faster than the<br>
standard FFI.<br>
</blockquote>
<br></div><div class="im">
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims it have ever ever run an actual benchmark, have you?<br>
<br></div>
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).<br>
<br>
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 :-)<br>
<br>
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.<br>
</blockquote><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>