多核系统的编程和编译状态 [英] The state of programming and compiling for multicore systems

问题描述

我正在研究多核处理器；特别是我正在寻找为多核处理器编写代码，以及为多核处理器编译代码.

I'm doing some research on multicore processors; specifically I'm looking at writing code for multicore processors and also compiling code for multicore processors.

我对该领域的主要问题感到好奇，这些问题目前可能阻止广泛采用编程技术和实践以充分利用多核体系结构的功能.

I'm curious about the major problems in this field that would currently prevent a widespread adoption of programming techniques and practices to fully leverage the power of multicore architectures.

我知道以下工作(其中一些工作似乎与多核体系结构没有直接关系，但似乎与并行编程模型，多线程和并发性有更多关系)

I am aware of the following efforts (some of these don't seem directly related to multicore architectures, but seem to have more to do with parallel-programming models, multi-threading, and concurrency):

• Erlang (我知道Erlang包含促进并发的结构，但是我我不确定它在多核架构中的利用率如何
• OpenMP (似乎主要与多处理和利用集群功能有关)
>
• 统一并行C
• Cilk
• 英特尔线程模块(这似乎与多核系统直接相关；它来自英特尔.除了定义某些编程结构外，它似乎还具有告诉编译器针对多核体系结构优化代码的功能.

• Erlang (I know that Erlang includes constructs to facilitate concurrency, but I am not sure how exactly it is being leveraged for multicore architectures)
• OpenMP (seems mostly related to multiprocessing and leveraging the power of clusters)
• Unified Parallel C
• Cilk
• Intel Threading Blocks (this seems to be directly related to multicore systems; makes sense as it comes from Intel. In addition to defining certain programming-constructs, it also seems have features that tell the compiler to optimize the code for multicore architectures)

通常，根据我对多线程编程的很少了解，我知道考虑到并发性和并行性的编程绝对是一个困难的概念.我也知道多线程编程和多核编程是两回事.在多线程编程中，您要确保CPU不会保持空闲状态(在单CPU系统上.正如James指出的那样，操作系统可以安排不同的线程在不同的内核上运行，但是我更感兴趣的是从语言本身，还是通过编译器).据我所知，您不能真正进行并行操作.在多核系统中，您应该能够执行真正的并行操作.

In general, from what little experience I have with multithreaded programming, I know that programming with concurrency and parallelism in mind is definitely a difficult concept. I am also aware that multithreaded programming and multicore programming are two different things. in multithreaded programming you are ensuring that the CPU does not remain idle (on a single-CPU system. As James pointed out the OS can schedule different threads to run on different cores -- but I'm more interested in describing the parallel operations from the language itself, or via the compiler). As far as I know you cannot truly do parallel operations. In multicore systems, you should be able to perform truly-parallel operations.

所以在我看来，当前多核编程面临的问题是:

So it seems to me that currently the problems facing multicore programming are:

• 多核编程是一个困难的概念，需要大量技能
• 当今的编程语言中没有本机结构可为多核环境的编程提供良好的抽象效果
• 除了Intel的TBB库之外，我还没有在其他编程语言中做出任何努力来利用多核体系结构的强大功能进行编译(例如，我不知道Java或C#编译器是否为多核系统优化了字节码，还是即使JIT编译器可以做到)

我很想知道可能还有其他问题，以及作品中是否有解决这些问题的解决方案.链接到研究论文(以及类似性质的东西)将很有帮助.谢谢！

I'm interested in knowing what other problems there might be, and if there are any solutions in the works to address these problems. Links to research papers (and things of that nature) would be helpful. Thanks!

编辑

如果我不得不将我的问题简化为一句话，那就是:当今的多核编程面临哪些问题，并且该领域正在开展哪些研究来解决这些问题?

If I had to condense my question down to one sentence, it would be this: What are the problems that face multicore programming today and what research is going on in the field to solve these problems?

更新

在我看来，多核也需要关注三个层次:

It also seems to me that there are three levels where multicore needs to be concerned:

1. 语言级别:构造/概念/框架，抽象化并行化和并发性，并使程序员易于表达相同的意思
2. 编译器级别:如果编译器知道其要编译的体系结构，则可以针对该体系结构优化已编译的代码.
3. 操作系统级别:操作系统优化了正在运行的进程，并可能安排了不同的线程/进程以在不同的内核上运行.

1. Language level: Constructs/concepts/frameworks that abstract parallelization and concurrency and make it easy for programmers to express the same
2. Compiler level: If the compiler is aware of what architecture it is compiling for, it can optimize the compiled code for that architecture.
3. OS level: The OS optimizes the running process and perhaps schedules different threads/processes to run on different cores.

我搜索了ACM和IEEE，并找到了几篇论文.他们中的大多数人谈论同时思考有多困难，以及当前的语言如何没有表达并发的适当方法.有些人甚至声称我们拥有的当前并发模型(线程)不是处理并发的好方法(即使在多个内核上).我有兴趣听取其他意见.

I've searched on ACM and IEEE and have found a few papers. Most of them talk about how difficult it is to think concurrently and also how current languages don't have a proper way to express concurrency. Some have gone so far as to claim that the current model of concurrency that we have (threads) is not a good way to handle concurrency (even on multiple cores). I'm interested in hearing other views.

推荐答案

多核编程的主要问题与编写任何其他并发应用程序相同，但是在计算机中具有多个cpus的情况并不常见很难找到其中只有一个内核的任何现代计算机，因此，要利用多核，多种cpu架构，就会面临新的挑战.

The major problems with multicore programming is the same as writing any other concurrent applications, but whereas before it was uncommon to have multiple cpus in a computer, now it is hard to find any modern computer with only one core in it, so, to take advantage of multicore, multiple cpu architectures there are new challenges.

但是，这个问题是一个老问题，每当计算机体系结构超出编译器范围时，后备解决方案似乎都将退回到功能编程，因为严格遵循该编程范例可以创建可并行化的程序，就像您不这样做一样.例如，没有任何全局可变变量.

But, this problem is an old problem, whenever computer architectures go beyond compilers then it seems the fallback solution is to move back toward functional programming, as that programming paradigm, if strictly followed, can make very parallelizable programs, as you don't have any global mutable variables, for example.

但是，并非所有问题都可以使用FP轻松解决，因此，目标是如何轻松地使其他编程范例易于在多核上使用.

But, not all problems can be done easily using FP, so the goal then is how to easily get other programming paradigms to be easy to use on multicores.

第一件事是，许多程序员避免编写良好的多线程应用程序，因此开发人员的准备不足，因为他们学会了使编码变得更难做的习惯.

The first thing is that many programmers have avoided writing good mulithreaded applications, so there isn't a strongly prepared number of developers, as they learned habits that will make their coding harder to do.

但是，与对cpu所做的大多数更改一样，您可以查看如何更改编译器，为此，您可以查看Scala，Haskell，Erlang和F#.

But, as with most changes to the cpu, you can look at how to change the compiler, and for that you can look at Scala, Haskell, Erlang and F#.

对于库，您可以看一下MS的并行框架扩展，它是使并发编程更容易的一种方式.

For libraries you can look at the parallel framework extension, by MS as a way to make it easier to do concurrent programming.

它正在工作，但是我最近在IEEE Spectrum或IEEE Computer上发表了有关多核编程问题的文章，因此请查看关于这些问题的IEEE和ACM文章，以获取更多关于正在研究的内容的想法.

It is at work, but I recently either IEEE Spectrum or IEEE Computer had articles on multicore programming issues, so look at what IEEE and ACM articles have been written on these issues, to get more ideas as to what is being looked at.

我认为最大的障碍将是使程序员难以更改其语言，因为FP与OOP完全不同.

I think the biggest impediment will be the difficulty to get programmers to change their language as FP is very different than OOP.

除了开发以这种方式有效工作的语言外，还有一个研究地方是如何处理访问内存的多个线程，但是，与该领域的许多事情一样，Haskell似乎在测试此想法方面处于领先地位，因此您可以看看Haskell发生了什么.

One place for research besides developing languages that will work well this way, is how to handle multiple threads accessing memory, but, as with much in this area, Haskell seems to be at the forefront in testing ideas for this, so you can look at what is going on with Haskell.

最终会有新的语言出现，也许我们有DSL可以帮助抽象更多的开发人员，但是如何对程序员进行培训将是一个挑战.

Ultimately there will be new languages, and it may be that we have DSLs to help abstract the developer more, but how to educate programmers on this will be a challenge.

更新:

您可能会发现第24章.感兴趣的并发和多核编程， http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html

这篇关于多核系统的编程和编译状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！