<div dir="auto"><div>Andres,<div dir="auto"> </div><div dir="auto">Agreed... I was mainly trying to point out that Alien isn't the uniformly superior approach that it often seems to be portrayed as nor are plugins obsolete (which seems to be the case Eliot is making). It would be nice to have a single approach that did it all but we're not there yet.</div><div dir="auto"> </div><div dir="auto">Thanks,</div><div dir="auto">Phil</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020, 3:29 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, just remember there are a multitude of situations where FFI is the wrong approach (like, literally, it's undefined behavior). FFI alone is not enough. On 5/27/20 12:10, Phil B via Cuis-dev wrote: > Related to the discussion is this rather dated thread: > <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147241.html" rel="noreferrer noreferrer" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147241.html</a> I > haven't yet seen much in the way of objective analysis since then to > render it obsolete. (if it exists and I've missed it, please point it out!) > > Conventional wisdom (prior to Cog & Spur VMs... that likely changes the > equation at least a bit along with whatever (de-)evolution has occurred > in the respective approaches over the years) used to be that Plugin > > FFI > Alien from a raw performance standpoint. But Alien had > callbacks... and when you need them, you need them. Also, IIRC Alien > utilizes introspection and therefore wouldn't run without a sources file > which is an issue for some deployment scenarios. > > As you mention the (at least theoretical) advantage of abstracting > functionality by pushing it to the VM shouldn't be dismissed. I've > experienced both the good and bad side of this with things like the > sound and ssl plugins. When they work, it's great: you don't care what > platform you're on: it just works. With an FFI solution, you're dealing > with different libraries/locations and possibly entirely different APIs > entirely on different platforms and it's usually up to you to sort it > out. However, when there is a plugin problem (i.e. mismatched library > versions etc), you have all of the issues of dealing with plugin and FFI > code. So a lot of this potential advantage comes down to how well > plugins are maintained. If they aren't, you may be better off with FFI > since sometimes fixing a broken plugin can be more work than just > rolling your own solution. > > Thanks, > Phil > > On Wed, May 27, 2020 at 1:49 PM Juan Vuletich via Cuis-dev > <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">cuis-dev@lists.cuis.st</a>>> wrote: > > Hi Philip, > > On 5/27/2020 2:17 AM, Philip Bernhart via Cuis-dev wrote: > > Hi, > > > > I recently asked on the squeak vm-beginners list about the stability > > of the external plugin interface. The general vibe from Eliot was: > > don't! Use FFI instead! > > > > See: > > > <a href="http://forum.world.st/Stability-of-the-external-plugin-interface-td5117112.html" rel="noreferrer noreferrer" target="_blank">http://forum.world.st/Stability-of-the-external-plugin-interface-td5117112.html</a> > > Ok. Specifically on this. I've used buth alternatives over the years. I > developed or fixed bugs in JPEGReadWriterPlugin2, BitBltPlugin, > ExtendedClipboardPlugin, SoundPlugin, (old experiment) > VectorCanvasPlugin. I ported FFI to 64 bit Cuis (the 32 bit FFI was > inherited from Squeak), and used it for OpenCL. I don't have a > favorite, > and I think there shouldn't be one. So, today I spent a couple of hours > writing this: > > ================================ > > FFI or Vm Plugins? > ------------------ > > There are two main ways to call external code in the Cuis / Squeak > world. One is FFI (what is usually used in other dynamic languages) and > VM Plugins (a mechanism that is specific to the Squeak VM). There might > be use cases where one of them is preferable to the other. Let's take a > look at what they do, to see their pros and cons. > > FFI > --- > FFI is a general mechanism to call external platform libraries. DLLs > and > the like. The mechanism is general, so for each different function we > might call, we need a way to build the native platform call stack > (function arguments). This is different for each platform, and > different > for each function. This function+platform specific specification lives > in the Smalltalk image. > > FFI break with the idea that the VM defines the boundary between the > Smalltalk world and the external world: > - Any platform specific difference in functions called via FFI is > handled in the Smalltalk image > - The Smalltalk image is aware of each platform we might want to run on > > For a non trivial example, evaluate `Feature require: 'OpenCL'` and > browse the OpenCLPrimitiveInterface hierarchy. > > VM Plugins > ---------- > VM Plugins are a Squeak VM specific way to call C code. The call > mechanism is general, and handled by the VM. The C code is specific to > the problem to solve, and must follow the rules for building > plugins. In > many cases it is not platform specific. This function specific code in > plugin form lives in Slang or C code. > > VM plugins follow the idea that the VM defines the boundary between the > Smalltalk world and the external world: > - Smalltalk image is platform independent > - VM + Plugins are platform dependent > > As examples of their use, you might browse all methods containing > string > `module: 'FloatArrayPlugin'>` or module: 'JPEGReadWriter2Plugin'> > > > Use cases > --------- > Both FFI and VM Plugins can be used in a variety of scenarios, with > possible different needs: > (1) Using platform specific functionality (for instance, the Windows > API) > (2) Using third party code distributed as dynamic libraries (for > example, TensorFlow) > (3) Using third party code distributed as source code or static linked > libraries (for example, libJPEG, stdlib.h memcpy(), math.h float stuff) > (4) Own code, written in Slang or C for performance reasons (BitBlt, > FloatArray) > (5) Own code, needing to deal with Smalltalk object internals, or VM > services. > > Additionally, some calls need to be done with strict real time > restrictions (like music / audio), or execution might be so quick > and so > frequent that any call overhead needs to be minimized (for example, > BitBlt, LargeInteger). > > > How do they compare? > -------------------- > > a) Ease of development and prototyping. > For the scenarios where FFI is well suited, (1) or (2), working with > FFI > is much faster and easier. It is possible to reuse API docs and general > know how from outside the Smalltalk world. On the other hand, code that > needs to deal with Smalltalk object internals and VM services (5) is > easier to do as a plugins. For code written in C (and not regular > Smalltalk) for performance reasons (4), if you already have the > required > setup, writing a plugin is easier and faster, as you don't need to deal > with the platform stack. > -- Bottom line: It depends. > > b) Ease of modifications, ease of updating users installations. > Modifying a plugin usually requires the developer to compile a new dll. > Modifying FFI calls can be done with just Smalltalk code. > -- Bottom line: Clear win for FFI. > > c) Call Speed. > Plugin calls are almost as fast as regular numbered primitives. FFI > calls range from terribly slow to just plain slow, when compared to > that. > -- Bottom line: Plugin wins, if you really need low call overhead. > > d) Support for callbacks > Recent implementations of FFI do support real callbacks. With VM > plugins, the best we can do is to register a semaphore for the > plugin to > signal. This is usually safer, as the callback is done as a Smalltalk > Process switch, making it easier to protect shared state. But there > might be a large delay from the moment the semaphore is signaled to the > moment where the "callback" is actually ran. > -- Bottom line: FFI (callbacks enabled) clear win, if you need > callbacks. > > e) Access to VM services and data structures to deal with Smalltalk > objects > VM plugins have a lot of services provided by available VM functions, > and types provided by VM maker. Slang/C code needing to deal with the > internals of Smalltalk objects is usually much easily done in plugins. > -- Bottom line: Plugin wins, if you need this. > > > What is each alternative good for? > ---------------------------------- > > FFI is good for: > - Tight integration with host platform (Host windowing system, native > widget libraries) > - 3rd party code that is meant to be linked dynamically, and everyone > else calls via FFI > - Application specific stuff (where dealing with platform specific > details is not a problem) > - Functionality that requires real callbacks > - Stuff that is in development, APIs that are not yet stable, > experimental code > > Plugins are good for: > - Own code written for performance > - 3rd party code that is meant to be linked statically > - Kernel Smalltalk functionality > - Functions that take very short time to run, and overhead becomes > dominant time > - Stable functionality that will be used by many people over a long time > > > ================================ > > I hope I haven't left out too many details. Feel free to argue, > correct, > discuss, etc. > > Thanks, > > -- > Juan Vuletich > <a href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer" target="_blank">www.cuis-smalltalk.org</a> <<a href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer" target="_blank">http://www.cuis-smalltalk.org</a>> > <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> > <a href="https://github.com/jvuletich" rel="noreferrer noreferrer" target="_blank">https://github.com/jvuletich</a> > <a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a> > @JuanVuletich > > -- > Cuis-dev mailing list > <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a>> > <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> > > -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div></div>