Modeling & design multi-core NUMA simulator
•Télécharger en tant que PPTX, PDF•
0 j'aime•811 vues
Modeling & design multi-core NUMA simulator, typologies and protocols.
Recommandé
Contenu connexe
Tendances
Tendances (18)
Similaire à Modeling & design multi-core NUMA simulator
Similaire à Modeling & design multi-core NUMA simulator (20)
Dernier
Dernier (20)
Modeling & design multi-core NUMA simulator
- 1. Design & Modeling Multi-core NUMA simulator and protocols
- 2. Why simulator? Propose Solution What is NUMA? Problems Modeling process Simulation integration Demo
- 4. Propose Solution Modeling & Design a tool that simulate Multi-core NUMA hardware and protocols
- 6. What is NUMA? CPU 1 CPU 2 RAM 1 GPU 1GPU 2GPU 3
- 7. Problems Software problems Mapping Scheduling Hardware problems Fixed topologies So expensive Not customable
- 9. Define basic function Core Functions Load() Compute() Store()
- 10. Define basic function Bank Memory Functions Read() Write()
- 11. Define basic function Inter Connection Network Functions Receive() Send()
- 13. Package diagram
- 14. Class diagram
- 16. ( example of second class) ( example of fixed parameter )
- 17. Whole model
- 20. Events based model We have a model that is totally independent from simulator. Core 1 BUS LM Simulator
- 21. Events based model Core 1 BUS LM
- 23. Why existing simulator? Because it has already a whole engine system from: Entity object Simulation object Event manager object Queue Also, a lots of functions: Cancel(); Start(); Suspends();
- 24. JAVASIM
- 25. Core 1 BUS LM JavaSim Local Memory Access
Notes de l'éditeur
- This is a quote from last year thesis. Where he was working on mapping and scheduling policies but he face a big problem testing it. because he didn’t have a real machine to test on it. There is not such a tool for researchers to design and test different policies on it.
- We want to create a platform (library) to test on it, and can be reusable, extensible and maintainable. That can provide as much as possible of information about the machine such as execution time, ration of local and remote memory access and information about every single event happening on machine.
- NUMA machine is a multiple nodes connecting by interconnection network. Each nodes has ram, cpus, cores and caches connecting by buses.
- graphics processor unit (GPU) Physical NUMA machine
- It’s has a lot of problems: *Software problems - Remote and local access memory most important cost!!!!! *Hardware problems - Ex: if we have machine with four nodes in lab, researcher will test his algorithm on a fixe topology and he cannot see how his algorithm will perform on different topologies. - And without a hardware we can’t test the software ( algorithms ).
- To model a NUMA machine, we start seeing the barriers and obstacles. Then, We build the model architecture based on physical NUMA machine and we build on top of that more systems witch we will see in next slides. Next slide is basic functionalities. Each component has a basic function
- All those components need to be related by a hierarchical system. Witch we create using … next slide
- HWLOC: Hardware Locality from university of Bordeaux Throw our study to NUMA machine we found, NUMA machine is based on hierarchical architecture. Witch, guide us to create our own hierarchical system. Real -> topology Simulated model <- topology …next slide
- This a package diagram witch we are using in our library.
- We create class and package diagram after we study the physical NUMA machine.
- We munched earlier about the hierarchical system. Interfaces class allow us to create the complex model of NUMA.
- Not only this but our model is extensible mean well, any programmer can create new class with the specification he wants without changing the related classes. Even in process of create the topology all components are grouped under name of children. We didn’t fixed the parameter of constructor.
- Our model now is extensible, reusable, maintainable and structured. But we need statistics and events records and so on.
- *We have used an event fire mechanism in our model to be listened by the simulator. * Will drive the model using simulation kernel. *Example: Event fire is simple method in IHierarchical interface class extends by all components ( IMachine)
- Our model need to be simulated in order to get the information. So, we integrate our model to an existing simulator. Witch what will see in next slides.
- We are not going to reinvent the wheel “réinventer la roue” Simulation object The overall simulation model. Input data, starting& terminate simulation , and printing reports as an output. Event manager object Maintains simulated time and the list of future and conditional events to be executed. Entity object The basic object for the simulation. Can be permanent or temporary during the simulation run and can be either active or passive in the model logic. Scheduler Queue
- After, we go throw a lot of existing simulators. We pick JAVASim because of familiarity. JavaSIM has been available since 1997 and is an object-oriented simulation package based upon C++SIM * let’s take an example of local memory access. To see how the whole model should act.
- But how we can achieve this?
- This class test will listener to each event and log it into console. Witch each event has args such as : name of event, type, msg, time of execution and a component.
- Because JAVASim handle the events. We should see this sequence of events on our console. Witch will see later on the demo
- Now, after we saw the modeling process and the integration process. This is an overview on our model and simulator relationship. And now We can see some scenario.