Okay, if I may have your attention again, it's time for next talk by Matthias Lorsen,
this time about his unicernal and how he can run MPI code faster.
Which is yours?
So hello everyone, you take me well?
Okay, thank you.
I'm Matthias Lada, in this presentation I'm going to talk about the player in MPI applications using Total Unicernal.
This is an exploratory work, so it's an area I am still investigating, so at the end of the presentation feel free to ask me any questions because I'm still benchmarking things, I'm not pretty sure where I'm going.
So first I would like to present myself, I'm fascinated about practice system development and mutualization, and I have been working in these companies, this is my email, I did have a profile if you want to get in touch or you want to see some of my projects.
This current project is not related with my current work, so it's something that I'm just doing when I have some free time.
I would like to start by what is my intuition about what is an MPI application, I am not an expert on MPI, so it is what I understood since two years I have been working on this.
So it is an application that compiles with the implementation of the MPI standard, so there exists several implementations of the MPI standard.
The standard defines a set of APIs to synchronize and communicate parallel instances of the MPI application, so for example we have this sort of API, like MPI barrier broadcast and all reuse for example, so to set some of them.
My impression is that the only performance matter when we deploy MPI applications, so I have a feeling that the virtualization is not very popular in HPC, at least my impression for the overhead that this adds.
So my thought was that maybe MPI applications may benefit from the unicurners because for example Cisco are expensive, so in unicurners we remove that, we have calls, threads are cheaper than process, so you may know that we are not switching the page today,
every time we are doing context switching in unicurner, depending on your application you can completely remove the scheduler because you are going to run only one thread per course or something like this.
You can rely on communication and share memory for example, in the case of unicurners.
And sometimes this is something that I just added, sometimes perform better than a general operating system as I guess and I say this because sometimes you can tweak your operating system to reach good performance, let's say.
So yeah, well this is the diagram or the components that they are involved with when you are deploying an MPI application using a general proposal of the operating system.
In this case I am thinking that the MPI application is running as a built-in machine but the diagram is more or less the same in case it is bare metal.
So what we have is your MPI application, then it compiles with implementation of the MPI standard, for example OpenMPI and the OpenMPI is going to use some Cisco to communicate with the operating system to get some service like scaling file system, networking and so on.
So what unicurners propose is well let's take a look at the data.
Thank you.
you
about the scheduler.
So the scheduler in tutorial is quite simple and also well here is no scheduler, it is the way that the tutorial creates threads.
You have a dedicated API called a begin thread but it is a parameter that has to tell where the instance is going to run so you have to set up where the core is, I mean where you want that function to run.
Otherwise it is going to choose all the times the booting core.
The scheduler is quite simple, it is a cooperative scheduler, so I mean the thread is going to do something and then call this thread switch which is going to invoke the scheduler and each scheduler, I think I present that in the next one.
Yeah, I mean each scheduler is independent one another so there is no communication between the instance so each core is scheduler completely independent one another and the algorithm is quite simple, it is going to choose the next thread that is ready, not more than that.
And the idea behind that is that the idea was to have instance of the kernel that don't require any mechanism to synchronize the instance so there is no speed lock or something like this so all the access to the kernel data is lock free.
So I just talked about the scheduler, now I am going to talk about the memory, also total memory is dedicated so when the kernel initialize is split the memory in rations and then all the allocations happen from that rations depending the core.
So the splitting is quite simple, it is just split by the number of cores so you have two cores, you have two cores, you have three, so for a moment this algorithm is quite simple and maybe it could be improved for sure.
So for example we have a memory allocator that since each ration is assigned to different core the way that we implement the allocator doesn't require any synchronization between the core, keep also the same idea that each instance runs independent one another.
So for example when a thread has two allocator memories it is always coming from the same ration and also doesn't require any synchronization between the cores and so on.
The idea behind this is also to try to leverage from technologies that integrate paths that you can have a known informer memory and then you have faster access to some rations.
And in a general way all the kernel data in total is per CPU variables so it means that it doesn't require any synchronization between the core to access kernel data.
And also to access faster to these CPU variables using the chs register for example and this is an improvement that I did a couple of months ago and so we have a table and it is faster access through the chs register which is pointing to that table.
I don't remember exactly the mechanics but I think I have a blog that I wrote about that and all the access is log free.
The only moment that we require synchronization between the cores is when we wanted to for example create a thread from one core to another.
We need to synchronize somehow the cores to migrate one thread to another something like this but it's the only moment that we need it.
Otherwise this is completely independent all the instance.
And to end the principles of total I will be going to talk a bit about the core to core communication.
And the idea was to even if you as a user you can implement anything on share memory as you want.
I decided to implement the entire over share memory so each core has a set of big use that allows to get data from a remote core and say data to another core.
And it was just a bit of I mean to have fun to do it like this.
I mean I'm starting to see if I can implement the entire like this.
And the idea is that the communication is core to core so we don't have only one queue per core.
You have as many birch use as you need to communicate one to one for each core.
I don't know how to say exactly but this makes that you don't require any protection to send or keep the exclusive access to this birch use.
Because you have only one consumer or one producer and so on.
And relying on this mechanism then I could implement the API from MPI like MPI Gutter broadcast and MPI scatter which are functions that require communication between the core.
So from the root core to the root core and so on.
So I think I will just talk a bit about the benchmark I have been done.
I feel free to comment about this because I'm not really sure about the numbers I'm getting.
What I did was to choose a set of well known benchmarks called also micro benchmark which is since that it is used for benchmark in different implementations of the MPI standard.
And I pick up two of them the also barrier and also already use which what they do is just stress some function.
So for example the also barrier stress the MPI barrier function which is something to synchronize the instance of an MPI application.
It's just a software barrier let's say.
And the other one they already use is stress the MPI already use function.
Which is going to send some vector to the root core process something and get back the rest to the other cores or other instance.
What I did was comparing with Linux Bermuda and Linux in IBM and I use it.
I pick up this machine from the from a clinics which is an AMD epic with 24 cores and 64 sheen rate and the host I use it for the VN is a Wuntu with isolated cores.
No sorry yeah with isolated course.
And I ran the and I use it.
KBM team was hypervisor.
I'm sorry now the host was Wuntu and the guess was Fedora 38.
What I did is in this particular case what I did was to use a huge VM with 16 cores.
Maybe it's not the most common case for MPI people just have several nodes instead of putting everything on the same.
In my case I was trying to play with this so I decided to use a huge VM let's say and then compare with total right.
So this is how I launch the benchmark.
So for example I am using 16 threads for example.
I'm not an expert in MPI I'm not really sure if this I mean if the MPI run for example is really using one core per thread it will not be optimal otherwise I think.
And I was launching for 1000 interaction so this is the result for the Linux Bermuda.
No Linux in IBM sorry.
So these are the numbers for the host barrier.
Which is this test if I yeah.
So you can see that there is quite huge difference between the Linux VM and the Unicolon.
But still I have to read redo these numbers I'm not really sure about that I mean because there are one order of magnitude at least.
At the beginning I was interested to compare with Linux Bermuda because I think we can achieve something like this in IBM.
But then when I started to play with Linux VM I said well there is a huge already difference with the VM.
And also I was comparing with the host already used as I said before in particular with that side of the vector.
And also it's quite huge difference with the Unicolon.
So in the two cases are 16 cores in the VM and the Unicolon too.
And I think that's all about the benchmark.
To have this number also I figured out that some issues in particular I don't know if you were measuring something in VMs.
In particular in carry-in the early TCC register is not emulated so you have to be careful when you use that.
For example you have to when you are doing numbers you have to check that the carry-in is still in time.
So if you make the difference it's not going to work always so you have to be careful about that.
That's all I think.
The question is a question.
It's a question.
It's a pity I'm not doing...
The question was why I'm not doing communication between the VMs using this implementation.
Basically this implementation can only run on a single node but people are using MPI on classes with tens or hundreds or thousands of nodes.
Why?
Do you have any plans to extend that?
Well I'm thinking about that because it's not the first time that they mention this.
Maybe create an interface, I mean use butyonet or butyvisoc to communicate with other instance.
You will have multiple VMs running that.
But for the moment maybe I will do it soon.
I'm not really worried about that.
What questions?
Which MPI implementation are you implementing?
Because there are different kind of versions of MPI or Pitch or so on.
Which one are you based on?
I'm not really sure because what I'm doing is just trying to read the semantics of MPI.
I'm trying to implement it at code.
The number of the functions I'm implementing is based on what is the benchmark.
That's all. This is why I'm doing it. No more than that.
Do you have numbers when you increase the number of nodes?
Do you mean if I have numbers when you increment the number of nodes? How that behave?
Yeah.
I'm still doing that number.
The difference is still there between the VM and the Linux implementation.
Still a difference in the sense that it's faster, let's say.
I'm still doing those numbers too.
There is no point in finding the question.
I don't know.
Do you have a question about the big problems that are happening in the end of the time?
The question is if I understand why we have that difference.
I don't know.
There are a lot of ways to tweak Linux to make it more performance.
Maybe I'm lacking that.
If you tweak it, you're going to dramatically drop that difference and the configuration.
I'm not really sure from where it's coming.
But I said before, it's still numbers that I'm working on.
Okay, I think we are running out of time.
So, Api, thanks again for the talk.
Thank you.
We have a short break for five minutes.
And after that, we will have talk.
Thank you.