On 9 November 2016 at 02:09, Dimitris Chloupis <kilon.al...@gmail.com> wrote:
> I have only played with c structs and it looks like they do the job fine . > If json parsing is slow especially in Pharo then it's out of the question. > Parsing must be kept close to zero because I will be running some very > tight loops of 100 frames per second and there is no way that I will let > Pharo take its time as the whole idea of using the fastest way to IPC was > to keep Pharo in sync with unreal . Heavy lifting will be done only by > Unreal. Pharo will be used just for logic. > > Well, it depends what you want: if you want to give away a complete/general solution for IPC with Pharo via shared memory, then you should create some kind of library (both C++ and Pharo) which would allow users to setup the bridge configuration in the way they want, leaving the application-specific exchange to the hands of users.. And if you just want to make own data exchange for own purpose, then you are basically done. > In any case there is a ton of testing and profiling needed to be done . So > these are just the first steps. > On Wed, 9 Nov 2016 at 02:58, Igor Stasenko <siguc...@gmail.com> wrote: > >> JSON? -- But you were talking about speed. Once you put JSON as a base >> for IPC, then say goodbye to speed. >> >> Because JSON parsing/writing will eat like 90% of time even if you would >> use sockets. >> So, why not using some kind of binary protocol? >> Unless you wanna use JSON for initial handshaking exchange. Then it is >> quite reasonable. >> >> But all of that still won't free you from inventing some kind of >> contract(s) which would allow parties to agree who writes where and/or who >> writes, while other waits then reads etc. >> >> >> On 9 November 2016 at 00:06, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >> >> *https://youtu.be/pI4PR3XaX6Q <https://youtu.be/pI4PR3XaX6Q>* >> >> *What is it ?* >> >> CPPBridge is a library that allows Pharo to share memory with any C/C++ >> application. Opening the door not only to IPC and data sharing but also >> even complete control of C++ code from Pharo and vice versa. >> >> *How to install ?* >> >> In a few hours it should be available from Package Browser, if not you >> can always fetch it with Metacello from here because it comes with a >> Baseline >> >> https://github.com/kilon/CPPBridge >> >> *Why bother making such a library ? * >> >> In my saga to find a way to use Pharo as a scripting language for Unreal >> Game Engine, I had two options >> >> a) Build Unreal as a Library and use Pharo UFFI to launch and control it >> b) Embed Pharo inside the Unreal Executable (this is what every other >> scripting language uses for controlling Unreal) >> >> Option (a) was a no go, because Unreal is huge , complex and uses its own >> custom made build tools, making a DLL for Pharo or an army of DLLs out of >> the question >> >> Option (b) Embeding Pharo inside an executable is impossible and >> implementing it also insanely complex >> >> Naturally my mind went first into sockets which is what I use to make >> Pharo able to use Python libraries. However sockets have proven too slow >> for the insanely fast loops of Unreal. >> >> *What are the advantages ?* >> >> 1) *No need to move data around.* Sharing memory means you don't have to >> move data around, you can use directly the shared memory >> >> 2)* Extend the Pharo image beyond Pharo.* Shared memory is mapped into a >> file means that you can do with C++ what you can do with Pharo image, save >> the live state directly to a binary file. That means we no longer need to >> worry about sessions and reinitializing C/C++ data since memory mapped file >> acts as an extension of the Pharo image. >> >> 3) *Blazing fast. *Memory mapping is a function that comes directly from >> the OS kernel and as such it has to be extremely fast. Memory mapping is >> also what is used for dynamically linked shared libraries an extremely >> important feature for any application including Pharo that heavily depends >> on (see Cairo for Athens). So its a very mature , well tested method. >> >> 4) *No extra libraries needed* to be installed, CPPBridge uses OS >> libraries to work out of the box >> >> 5) *Low level handling of memory.* Direct access to memory you can even >> manipulate the memory byte by byte >> >> 6)* Memory efficient.* Memory mapping excels at large data, the bigger >> the better. Can take full advantage of your entire free memory and not >> waste a byte. That means also that can be used to optimise Pharo memory, >> since you could compress your Pharo objects to bytes and mapped file will >> store the live state. >> >> 7) *Tons of Languages. *Because memory mapping is a core functionality >> for every OS out there, pretty much every programming language supports it. >> CPPBridge currently supports only C/C++ but all languages can be supported >> giving access to Pharo to any library for any programming language. Sky is >> the limit >> >> 8) *Self Documented. *CPPBridge is small, simple and with large class >> comment and comments for every method. YouTube video tutorial also >> available and linked on top. >> >> 9) *Works both ways*, C/C++ and Pharo can access and modify the shared >> memory. Making it possible for C/C++ to use Pharo libraries and Pharo to >> use C/C++ libraries. >> >> 10) Experiments have proven that it improves sex life... if it does not >> please file a bug report ;) >> >> >> *What are the disadvantages ?* >> >> 1) *Candy Crash Saga*. Dare do something incorrectly and Pharo will >> crash. CPPBridge can easily point to wrong address if you are not aware of >> what you doing. >> >> 2) *C++/C* . If you think you can avoid learning C/C++ and that this is >> a magic solution , think again. The C/C++ application must be modified to >> include shared memory mapping for CPPBridge to work . >> >> 3) *Local only*. Unlike sockets, Shared Memory works only on the same >> machine so no remote execution and manipulation of code like in my socket >> bridge to Python >> >> 4) *UFFI still No1 option*. No replacement for UFFI it actually depends >> on it to work , so if you can turn your C/C++ code into a DLL that should >> be your first option. >> >> *Roadmap * >> >> Currently CPPBridge works only on MacOS , most likely on Linux too >> (because it uses the Unix architecture) but I will have to test it. >> >> Windows is coming next ASAP, since its my No1 platform for creating >> commercial games. >> >> Maybe establish a small protocol of communication via the Shared Memory , >> JSON looks like a good universal format >> >> *Thanks* >> >> Big thanks to Eliot for inspiring me and Esteban for helping me figure >> out things. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
