<br><br><div class="gmail_quote">On Tue, Mar 23, 2010 at 11:41 AM, Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2010/3/23 Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;:<br>
<div><div></div><div class="h5">&gt;<br>
&gt;<br>
&gt; On Mon, Mar 22, 2010 at 9:21 PM, Andreas Raab &lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 3/22/2010 7:27 PM, Lawson English wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Croquet OpenGL is dependent on all sorts of things. Have you managed to<br>
&gt;&gt;&gt; get Croquet working in a modernish version of Squeak/Pharo?<br>
&gt;&gt;<br>
&gt;&gt; I can probably whip one up fairly easily. The actual dependencies are<br>
&gt;&gt; rather minor - all you need to do is drop the positional argument variants<br>
&gt;&gt; (we&#39;ve thrown these out in our own images too) and load the FFI first.<br>
&gt;&gt;<br>
&gt;&gt;&gt; Also, I was under the impression that Alien FFI was faster than the<br>
&gt;&gt;&gt; standard FFI.<br>
&gt;&gt;<br>
&gt;&gt; Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims<br>
&gt;&gt; it have ever ever run an actual benchmark, have you?<br>
&gt;&gt;<br>
&gt;&gt; There is interesting out-of-context quote in the Alien documentation that<br>
&gt;&gt; brings as one of the arguments for Alien something that I said about the<br>
&gt;&gt; FFI, namely that the &quot;FFI is slow ...&quot; but unfortunately it doesn&#39;t quote<br>
&gt;&gt; the other half of that statement which is &quot;... when compared to the Squeak<br>
&gt;&gt; plugin interface&quot;. That is undoubtedly true in the context of a discussion<br>
&gt;&gt; that compares the FFI and the Squeak plugin interface since the FFI has<br>
&gt;&gt; marshalling overhead that is not incurred by a regular plugin. That said,<br>
&gt;&gt; the FFI isn&#39;t slow per se - in particular not when compared with doing<br>
&gt;&gt; marshalling inside Squeak (as Alien does).<br>
&gt;&gt;<br>
&gt;&gt; Put on top that people seem to use Alien in the most naive (e.g., slow)<br>
&gt;&gt; way looking up the functions on each call, and I&#39;d say the FFI will beat<br>
&gt;&gt; Alien in *any* practical performance tests today (and for the foreseeable<br>
&gt;&gt; future). Doesn&#39;t mean Alien can&#39;t be improved, but the next time someone<br>
&gt;&gt; claims that &quot;FFI is slow and Alien is fast&quot; ask for the benchmark they ran<br>
&gt;&gt; instead of taking the claim at face value :-)<br>
&gt;&gt;<br>
&gt;&gt; The main reason for using Alien today is callbacks. There is still no<br>
&gt;&gt; support for callbacks in the FFI so if you need callbacks Alien is your<br>
&gt;&gt; choice. One of the things that I&#39;ve got on my TODO list with Eliot is to<br>
&gt;&gt; improve interoperability between Alien and the FFI. It should be possible to<br>
&gt;&gt; pass Aliens straight into FFI calls at which point you could have your cake<br>
&gt;&gt; and eat it, too.<br>
&gt;<br>
&gt; Right.  I won&#39;t stand by the &quot;slow&quot; comment anymore.  I&#39;ve done a much<br>
&gt; faster version of FFI here that has essentially the same performance as<br>
&gt; Alien.  The important thing is to use alloca to allocate the outgoing stack<br>
&gt; frame and marshall to that. The old FFI code marshalled to static memory and<br>
&gt; then copied to the stack frame.  This makes the old implementation<br>
&gt; inherrently slower /and/ non-reentrant.  Now this is solved FFI is<br>
&gt; essentially as fast as Alien.<br>
<br>
</div></div>Naive question: is there any potential stack overflow problem with alloca ?<br></blockquote><div><br></div><div>Not over and above what already exists in an FFI.  One can arrange that one alloca&#39;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.</div>
<div><br></div><div>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&#39;t enough space.  The code then calculates how much of the 16k was actually used and caches this in the FFI method&#39;s ExternalFunction object so next time it alloca&#39;s only what&#39;s required.  Actual overhead is greater than the alloca because one has to allow for the plugin function&#39;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 stack.</div>
<div><br></div><div>HTH</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Nicolas<br>
</font><div><div></div><div class="h5"><br>
&gt; The advantage FFI has right oer Alien call-outs (as opposed to Alien data<br>
&gt; representation) is more typing and so a better chance of dealing correctly<br>
&gt; with RISC calling conventions.  So the clear path is to merge the data<br>
&gt; management side of Alien into FFI and extend FFI with true callbacks, a la<br>
&gt; Alien.  We then have the best of both worlds.  That&#39;s something I want to<br>
&gt; get done this year, e.g. as part of the GSoC.<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt;  - Andreas<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br>