[Cuis-dev] FFI vs. Plugins - Re: Alien? ThreadedFFIPlugin?

Fri May 29 14:37:30 PDT 2020

Hi all! I think this summary should be in the cuis documentation, alongside
with the backticks meaning.

Thanks for all this knowledge!

El vie., 29 may. 2020 a las 17:02, Juan Vuletich via Cuis-dev (<
cuis-dev at lists.cuis.st>) escribió:

> Hi Philip,
>
> On 5/27/2020 3:26 PM, Philip Bernhart via Cuis-dev wrote:
> > Hi Juan,
> >
> > thanks for the summary of the FFI vs VM Plugins. I can
> > put that in the project directoy somewhere if you don't mind.
> > It has some clarifications and adds interesting nuances in
> > choosing between these two approaches of including external
> > code into the running Smalltalk Image.
>
> Sure, thanks. It could also be referenced from the docs in the FFI repo.
>
> > BUT what I wanted to ask, does Cuis support Alien or the ThreadedFFI
> > which Eliot was talking about? I think I missed that when I poked
> > in the FFI around at some point.
>
> Both should be straightforward to port to Cuis. I'm sure they will be
> useful in some scenarios.
>
> Thanks,
>
> > Thanks for your time,
> > Philip
> >
> > Juan Vuletich<juan at jvuletich.org>  writes:
> >
> >> 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
> >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> >> https://github.com/jvuletich
> >> https://www.linkedin.com/in/juan-vuletich-75611b3
> >> @JuanVuletich
>
>
> --
> Juan Vuletich
> 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
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200529/67539651/attachment.htm>