> I'll soon start to work on integrating our M5-based simulator, MV5, into > M5. I've read some documentation on the current status of M5, and I'd like > to share my plan/ideas with you and hear your suggestions. > Since M5 will soon replace its entire memory system modeling with Ruby&Gems, > it seems the interconnect and directory coherence modules in MV5 will have > little value for future M5. I'm wondering if the following contributions > would be interesting to you. I wouldn't be so hasty in dismissing the value of what you have done. Ruby is an important part of M5's future, but the current memory system is currently a lot faster and may be sufficient for simpler systems. I'll let others comment on this. It really depends on how much work needs to be done to get it into shape for sharing and how much bandwidth you need for core developers to help you get it into shape.
> 1. An in-order CPU module with multi-threading (switching threads upon cache > accesses) based on TimingSimpleCPU This is probably #1 on the priority list . > 2. SIMD cores: Based on TimingSimpleCPU. It models GPU-like branch handling > using the re-convergence stack. It is implemented as an array of scalar > threads rather than wider vector registers. It requires a parallel API > written in a similar style to OpenMP, with manually instrumentation to > signal the end of a branch in the parallel section of code. This sounds pretty interesting too. Does the ISA matter much, or do you think it could be pretty generic? Did you add new instructions to do things? > 3. A parallel API for writing parallel benchmarks that run in system > emulation mode. It can be used in a similar way to Pthread. It also provide > OpenMP-like programming interface, and it can work with the SIMD cores. It > also comes with various scheduling policies. So, this doesn't depend on #2? I assume that this is in syscall emulation mode? This is pretty interesting. The one issue is that there are already two? systems in m5 for doing parallel simulations and we don't want to just throw the kitchen sink into m5. Have you looked at the current m5threads stuff? Is there any overlap? > 4. A batch-simulation tool, which creates, manages, organizes, and analyzes > simulation tasks in batches. Written in Python. Good for space exploration > and sensitivity study. I manage tens of thousands of simulations over up to > 100 machines using this tool. It can work with a cluster of machines with a > shared file system. It also supports the PBS queuing system. This is a great utility and I have a pretty sophisticated one myself that has been used by several people. The biggest reason that I never made mine widely available is that it isn't easy to make this generic and it requires a fair amount of know-how to use. Perhaps you can send me a tarball/diffs so I can see what you've done and think about it. > What do you think about the above contributions? Can you prioritize them? They're probably in the right order already, but let's see what other people think. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
