<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">+1000 <div dir="ltr">/—————————————————————/<div>For encrypted mail use jgpfersich@protonmail.com - Free account at ProtonMail.com<div>Web: https://objectnets.net and https://objectnets.org</div></div><div>https://datascilv.com https://datascilv.org</div><div> </div></div><div dir="ltr"> <blockquote type="cite">On May 29, 2020, at 14:37, Gastón Caruso via Cuis-dev <cuis-dev@lists.cuis.st> wrote: </blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi all! I think this summary should be in the cuis documentation, alongside with the backticks meaning. <div> </div><div>Thanks for all this knowledge!</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie., 29 may. 2020 a las 17:02, Juan Vuletich via Cuis-dev (<<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>>) escribió: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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<<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>> 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: >>> <a href="http://forum.world.st/Stability-of-the-external-plugin-interface-td5117112.html" rel="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" target="_blank">www.cuis-smalltalk.org</a> >> <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> >> <a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a> >> <a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a> >> @JuanVuletich -- Juan Vuletich <a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a> <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> <a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a> <a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="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">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div> -- Cuis-dev mailing list Cuis-dev@lists.cuis.st https://lists.cuis.st/mailman/listinfo/cuis-dev </div></blockquote></body></html>