[Cuis-dev] FFI vs. Plugins - Re: Alien? ThreadedFFIPlugin?
Andres Valloud
ten at smallinteger.com
Wed May 27 12:29:36 PDT 2020
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:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147241.html 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
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> 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:
> >
> http://forum.world.st/Stability-of-the-external-plugin-interface-td5117112.html
>
> 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
> www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>
More information about the Cuis-dev
mailing list