用于在多核 x86 CPU 上进行测试的并行算法基准测试工具
我们想要为多核 x86 CPU 建立一个并行算法基准测试实验室，并且我们想知道是否有关于如何做到这一点的任何建议。我们希望它为我们提供尽可能确定的测量结果，因此我们一直在研究几种可能性：
- 操作系统
- RT Linux
- BareMetal 操作系统 (http://www.returninfinity.com/baremetal.html)
- 编程语言
- 低级：汇编程序或 C（这是使用 BareMetal 时仅有的两种可能性）
- 高级：RT Python 或 RT Java
我们认为最具确定性的选项是带有汇编器的 BareMetal OS，但如果我们可以使用更高级别如果语言的结果不会大幅下降，我们会更喜欢它。关于如何在保持编程效率的同时获得最佳结果有什么建议吗？
谢谢
We want to build a parallel algorithm benchmarking lab for multicore x86 CPUs and we want to know if there are any suggestions on how to do it. We want it to give us messurements as deterministic as possible, so we have been researching several possibilities:
- OS
- RT Linux
- BareMetal OS (http://www.returninfinity.com/baremetal.html)
- Programming Language
- Low Level: Assembler or C (These are the only 2 possibilities if BareMetal is used)
- High Level: RT Python or RT Java
We think the most deterministic option would be BareMetal OS with Assembler, but if we can use higher level languages without big degradations in the results, we would prefer it. Any suggestions about how to get the best results while preserving programming productivity?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我为我的论文做了很多并行程序基准测试。构建了一整套并行工作负载，并在真正的 x86 机器上运行它以进行性能测量。我有一种感觉，您正在选择一种语言来教授并行编程——如果是这样的话，我会选择 C 和汇编。对于许多项目来说，汇编的级别有点太低，但它是解释同步原语的编写答案。我用汇编编写了自己的线程原语，这是一次有益的经历。
我可能是错的，但我认为 @Gabe 关于在同一核心上运行的 python 线程是正确的。
我不同意 @powerrox 的观点，认为 MPI 是个好主意。不过我喜欢开放式议员。我总是让我的学生从 pthreads 开始，然后转向 OpenMP。 pthreads 提供了对底层情况的理解，然后 OpenMP 提供了优雅且干净的编码，而无需处理 pthread (void **)(void *)。
I did a lot of this parallel program benchmarking for my thesis. Built a large suite of parallel workloads and ran it on real x86 machines for performance measurements. I get a feeling that you are choosing a language to teach parallel programming -- if that is the case I would just go with C and assembly. Assembly is a bit too low level for many items but it is the write answer to explain synchronization primitives. I wrote my own thread primitives in assembly and it was a rewarding experience.
I may be wrong but I think @Gabe is right about python threads running on the same core.
I disagree with @powerrox that MPI is a good idea. I however love open MP. I always had my students start with pthreads, then move to OpenMP. pthreads provides understanding of whats going on under the hood and then OpenMP provides elegant and clean coding without having to deal with pthread (void **)(void *).
跨多个系统实现最高效并行处理的最流行方法是 MPI。
如果您仅谈论使用共享内存的多核、多 CPU 单系统，请瞄准 OpenMP 和 pThreads。公平警告，写得不好的 OpenMP 或 pThreads 无法扩展。 pThread 编程可能非常复杂。
OpenMP 非常适合域分解问题。 pThreads 是任务分解的唯一选择。 OpenMP 新规范可能支持任务分解。
如果您想使用汇编程序来实现并行编程 - 祝您好运。无法以富有成效的方式完成。
Gabe，Python 确实支持多线程。并且线程可以在多个核心上运行，并且不会以任何方式限制数据结构的选择。您可以使用带有线程的 python 在多个内核上运行的多个线程之间分配工作。
我会非常谨慎地接受加布的评论。在我看来，他的评论非常具有误导性。
The most popular way to have the most productive parallel processing across multiple systems is MPI.
If you are talking only about multi core, multi CPU single system using shared memory, aim for OpenMP and pThreads. Fair warning, badly written OpenMP or pThreads does not scale. pThread programing can be very complicated.
OpenMP is well suited for domain decomposition problems. pThreads is the only option for task decomposition. OpenMP new spec might support task decomposition.
And if you want to use assembler to achieve parallel programing - good luck to you. cant be done in a productive way.
And Gabe, python does support multiple-threads. And threads can run on multiple cores and does not limit the selection of data structures in anyway. You CAN use python with threads to distribute work among multiple threads that run on multiple cores.
I would be very cautious to go with gabe's comments. In my opinion, his comments are very misleading.