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

Sun May 31 00:16:34 PDT 2020

+1000

/—————————————————————/
For encrypted mail use jgpfersich at protonmail.com - Free account at ProtonMail.com
Web: https://objectnets.net and https://objectnets.org
https://datascilv.com https://datascilv.org


> On May 29, 2020, at 14:37, Gastón Caruso via Cuis-dev <cuis-dev at lists.cuis.st> wrote:
> 
> 
> 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
> -- 
> 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/20200531/21a75a3b/attachment-0001.htm>