Smalltalk › Pharo › Pharo Smalltalk Users

Pharo and OpenMP

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

kilon.alios

Pharo and OpenMP

First my apology for the very long post but I think this will interest a lot of people.

I have seen that someone out there .... HELOOOOOOO.... has tried Pharo with OpenMP

https://pharoweekly.wordpress.com/2015/07/17/pharo-and-openmp/

For those that dont know what the hell OpenMP is, it nothing more than a collection of C pragmas, not very diffirent to our pharo pragmas , that tell to a compiler how to make code parallel.

By parallel I don't mean pharo threads which are not really code that executes at the same time but true hardware threads and taking advantage of multiple cores etc. A pharo holy grail.

Parallel coding is a bitch, there a lot of logical problems to face when you have pieces of code executing at the same time and you have to be aware of how the hardware is doing it because if you dont it so easy to get code as slow as running it on a single thread.

I have been watching youtube tutorials by one of the guys that made OpenMP and I have to say I am very impressed. And it got me wondering "why the hell not pharo". The nice thing about OpenMP is that it does not matter that pharo VM can do only 1 thread which is the main thread, you can do multiple threads at C side using OpenMP and then collapse them to one thread and send the result back to pharo.

Also note OpenMP is engineered by Intel so its a very serious library and comes included with most modern compilers and that includes GCC. Visual Studio and Clang / LLVM

On the other hand lately I am also researching shared memory, actually its shared memory that lead me to OpenMP. My idea is basically extending the live coding enviroment of pharo beyond pharo.

Its sound a bit crazy but the way I see it from my very small knowledge of C and shared memory is that right now, pharo live coding evniroment is isolated from outside world. You can do live coding while inside pharo but the moment you go outside , say you call a C library , live coding goes out of the window. This why we need to have session management to manage resource of calling C libraries to make sure when we reload the image , the image does not freak out that the live state of the C libraries is gone.

This is also why many people push things to the image side. And of course its much more fun to code in Pharo than C.

Now bare with me because things are now getting really interesting....

what if we could have an image flle for C code ?

The things is that I am interested into shared memory because I want a very fast IPC, shared memory is the faster. I want to communicate Pharo with Blender, that I have accomplished via sockets, I can call python code and python libraries from pharo. But sockets are expensive in large loops, they work great for simple communication and much faster than pipes when used locally but try a large loop and socket will lag.

Shared memory on the other hand is super fast, it basically it gives a part of memory that is shared among process that means also different applications.

Now how a C image file fits into all this you may ask.

Its simple.

The most popular way of shared memory is called "memory mapped file", what it does is that it takes a file and loads it to memory as it is... sound familiar ? ;)

what however is also doing is that it allows you share that part of the memory with any other application/ process as long as it also tries to load the file mapped to memory the same way.

So what that means that we can have a place in memory that is shared between C code, including C dlls, and Pharo code. That file can act as an image file because we take that shared memory at any time that has been modified either by pharo, C or whatever else has access to shared memmory and store it back to that file. This is functionality that memory mapped files provide called msync.

We talk here about a C image that work at least on surface very similarly to Pharo image.

Now where OpenMP fits in all this ?

Since OpenMP is about code that eats processors like peanuts , yes we could call it from a DLL, but with my approach even if that code crashes we will be able to restore it back to its live state because of that image format. All we do is reopen the memory mapped file and restore from it the shared memory. So we end up with true parallel live C/Pharo code with live state that and of course live code that is shared between Pharo and pretty much anything that uses C or python or why not other languages.

So far I know how to do all of the above, well at least I am learning it now.

Now the real challenge, which I have no clue about, is to make a Pharo parser to C using OpenMP. My thinking is as following.

Why code in C and OpenMP when you could take something like Slang, which is basically pharo code that compiles to C, use pharo code with some pharo pragmas corresponding to OpenMP pragmas that will allow you to compile Slang OpenMP to C OpenMP and then compile it to an executable or dll that uses the shared memory memory mapped file solution.

Crazy ? realistic ? far fetched ? maybe ? good in theory back in practice?

Open to your thoughts.

David Allouche

Re: Pharo and OpenMP

On 26 Jan 2016, at 18:24, Dimitris Chloupis <[hidden email]> wrote:

First my apology for the very long post but I think this will interest a lot of people.

I found that intriguing.

I wonder whether the lack of response means:

The message was too long.
Nobody cares.
It's too wrong to respond.
It's too clever to respond.
All of the above.

Just curious…

PS: Working hard on concision ;-)

Offray Vladimir Luna Cárdenas-2

Re: Pharo and OpenMP

Hi,

On 30/01/16 18:26, David Allouche wrote:

On 26 Jan 2016, at 18:24, Dimitris Chloupis <[hidden email]> wrote:

First my apology for the very long post but I think this will interest a lot of people.

I found that intriguing.

I wonder whether the lack of response means:

The message was too long.

Nobody cares.

It's too wrong to respond.

It's too clever to respond.

All of the above.

Just curious…

PS: Working hard on concision ;-)

When I have messages without any answer in Pharo communities is almost always related with the first option (message was to long) or another reason is that is still pretty distant in the sense of being theoretical, hypothetical or something like that. What works best is concrete questions about practical issues, usually including code snippets (at least for me), while leaving long/distant stuff for blog post. That was the exploration I made here:

http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html

Cheers,

Offray

Paul DeBruicker

Re: Pharo and OpenMP

In reply to this post by David Allouche

If it helps - The "original" OpenMP thread is here:

http://forum.world.st/NativeBoost-and-OpenMP-td4837865.html

David Allouche wrote

> On 26 Jan 2016, at 18:24, Dimitris Chloupis <[hidden email]> wrote:
>
> First my apology for the very long post but I think this will interest a lot of people.

I found that intriguing.

I wonder whether the lack of response means:
The message was too long.
Nobody cares.
It's too wrong to respond.
It's too clever to respond.
All of the above.

Just curious…

PS: Working hard on concision ;-)

Ben Coman

Re: Pharo and OpenMP

In reply to this post by kilon.alios

On Wed, Jan 27, 2016 at 1:24 AM, Dimitris Chloupis
<[hidden email]> wrote:

> First my apology for the very long post but I think this will interest a lot
> of people.
>
> I have seen that someone out there .... HELOOOOOOO.... has tried Pharo with
> OpenMP
>
> https://pharoweekly.wordpress.com/2015/07/17/pharo-and-openmp/
>
> For those that dont know what the hell OpenMP is, it nothing more than a
> collection of C pragmas, not very diffirent to our pharo pragmas , that tell
> to a compiler how to make code parallel.
>
> By parallel I don't mean pharo threads which are not really code that
> executes at the same time but true hardware threads and taking advantage of
> multiple cores etc. A pharo holy grail.
>
> Parallel coding is a bitch, there a lot of logical problems to face when you
> have pieces of code executing at the same time and you have to be aware of
> how the hardware is doing it because if you dont it so easy to get code as
> slow as running it on a single thread.
>
> I have been watching youtube tutorials by one of the guys that made OpenMP
> and I have to say I am very impressed. And it got me wondering "why the hell
> not pharo". The nice thing about OpenMP is that it does not matter that
> pharo VM can do only 1 thread which is the main thread, you can do multiple
> threads at C side using OpenMP and then collapse them to one thread and send
> the result back to pharo.
>
> Also note OpenMP is engineered by Intel so its a very serious library and
> comes included with most modern compilers and that includes GCC. Visual
> Studio and Clang / LLVM
>
> On the other hand lately I am also researching shared memory, actually its
> shared memory that lead me to OpenMP. My idea is basically extending the
> live coding enviroment of pharo beyond pharo.
>
> Its sound a bit crazy but the way I see it from my very small knowledge of C
> and shared memory is that right now, pharo live coding evniroment is
> isolated from outside world. You can do live coding while inside pharo but
> the moment you go outside , say you call a C library , live coding goes out
> of the window. This why we need to have session management to manage
> resource of calling C libraries to make sure when we reload the image , the
> image does not freak out that the live state of the C libraries is gone.

I guess you won't avoid session management with this idea of memory
mapped C-image, since the external resources provide from the OS like
files, display buffers, network buffers & GPU threads would still be
destroyed by the OS when Pharo exits. Consider the case of moving your
Pharo-image + C-image to another machine.

>
> This is also why many people push things to the image side. And of course
> its much more fun to code in Pharo than C.
>
> Now bear with me because things are now getting really interesting....
>
> what if we could have an image flle for C code ?
>
> The things is that I am interested into shared memory because I want a very
> fast IPC, shared memory is the faster. I want to communicate Pharo with
> Blender, that I have accomplished via sockets, I can call python code and
> python libraries from pharo. But sockets are expensive in large loops, they
> work great for simple communication and much faster than pipes when used
> locally but try a large loop and socket will lag.
>
> Shared memory on the other hand is super fast, it basically it gives a part
> of memory that is shared among process that means also different
> applications.
>
> Now how a C image file fits into all this you may ask.
>
> Its simple.
>
> The most popular way of shared memory is called "memory mapped file", what
> it does is that it takes a file and loads it to memory as it is... sound
> familiar ? ;)
>
> what however is also doing is that it allows you share that part of the
> memory with any other application/ process as long as it also tries to load
> the file mapped to memory the same way.
>
> So what that means that we can have a place in memory that is shared between
> C code, including C dlls, and Pharo code. That file can act as an image file
> because we take that shared memory at any time that has been modified either
> by pharo, C or whatever else has access to shared memmory and store it back
> to that file. This is functionality that memory mapped files provide called
> msync.
>
> We talk here about a C image that work at least on surface very similarly to
> Pharo image.
>
> Now where OpenMP fits in all this ?
>
> Since OpenMP is about code that eats processors like peanuts , yes we could
> call it from a DLL, but with my approach even if that code crashes we will
> be able to restore it back to its live state because of that image format.
> All we do is reopen the memory mapped file and restore from it the shared
> memory. So we end up with true parallel live C/Pharo code with live state
> that and of course live code that is shared between Pharo and pretty much
> anything that uses C or python or why not other languages.
>
> So far I know how to do all of the above, well at least I am learning it
> now.
>
> Now the real challenge, which I have no clue about, is to make a Pharo
> parser to C using OpenMP. My thinking is as following.
>
> Why code in C and OpenMP when you could take something like Slang, which is
> basically pharo code that compiles to C,

Just to clarify (for myself also if someone likes to correct me) I
have gathered the idea that Slang should be thought of less as
Smalltalk compiling to C, and more as C with Smalltalk syntax which
works well with our usual tools. So compiling Slang to C is "trivial"
compared to compiling general Pharo code to C. The trick I guess would
be dynamically generating and compiling the C code and then linking it
back in.

> use pharo code with some pharo pragmas corresponding to
> OpenMP pragmas that will allow you to compile Slang
> OpenMP to C OpenMP and then compile it to an executable or dll that uses the
> shared memory memory mapped file solution.
>
> Crazy ? realistic ? far fetched ? maybe ? good in theory back in practice?
>
> Open to your thoughts.

I think applying some kind of OpenMP pragma to random parts of the
image's code would be quite difficult because it of the interaction
with the VM - but if it was restricted to code that ran detached from
the image (e.g. in a separate native or on a GPU) then that could be
interesting -- but I can't think of how you would marshall parameters
and results between them.

cheers -ben

kilon.alios

Re: Pharo and OpenMP

Thanks for posting the link to the original post , I tried to find it but I failed.

On the matter why people did not reply is probably because the idea is too "vague" and very "theoretical" and probably because the post is long.

Just for the record I have since dismissed as an idea both the C-image and shared memory model. The bad news is that Apple does not allow one executable to run another executable in iOS which means the pretty much kills the very foundation of my idea and makes it impossible to use Pharo with Unreal on iOS.

OpenMP wise again, I found out that Unreal has its own threading model which is very easy to use and runs under the hood. So I dont need that either.

"I guess you won't avoid session management with this idea of memory
mapped C-image, since the external resources provide from the OS like
files, display buffers, network buffers & GPU threads would still be
destroyed by the OS when Pharo exits. Consider the case of moving your
Pharo-image + C-image to another machine. "

No session management is still necessary , the goal was not to make it redundant but rather to keep live state of the C side. But that of course that means that this would not work automagically , the C code will have to use the shared memory mapped file or else the state would be lost. You will need a session manager to trigger the functions that were running at the time the c image file was closed but those functions would be able to continue from where they were left since the state would be restored.

"Just to clarify (for myself also if someone likes to correct me) I
have gathered the idea that Slang should be thought of less as
Smalltalk compiling to C, and more as C with Smalltalk syntax which
works well with our usual tools. So compiling Slang to C is "trivial"
compared to compiling general Pharo code to C. The trick I guess would
be dynamically generating and compiling the C code and then linking it
back in.
"

No not really, its actually the first. Slang has a lot of things C can do that slang cannot do this is why much of the VM is written in C and not Slang. There you expose another weakness of my idea that Slang would need an overhaul to do what I want.

"I think applying some kind of OpenMP pragma to random parts of the
image's code would be quite difficult because it of the interaction
with the VM - but if it was restricted to code that ran detached from
the image (e.g. in a separate native or on a GPU) then that could be
interesting -- but I can't think of how you would marshall parameters
and results between them. "

it should not be a problem since the threading would happen in the separate process that VM does not depend on , pharo would have only access to the shared memory. So basically it would be like

Pharo: C calculate this with X many threads and when you finish share the result in this part of the memory
C : Sure buddy in a few minutes you will have your result , i will alert you
Pharo: Thanks mate.

In any case that was a pure "theoretical" idea, I posted here to find its weaknesses. I see now its not such a good idea as I initially though for the above reasons.

It looks like I wont be using Pharo so much with Unreal afterall since the only viable solution would be to embed it which currently is not possible at least the easy way.

Oh well I may still use Pharo here and there to automate some Blender and Unreal stuff :)