您担心多核吗？
不可否认的是：多核计算机将继续存在。
事实也是如此：高效的多核编程是相当困难的。 这不仅仅是理解 pthread 的问题。
这是有争议的：“街头开发商”需要关注这些发展。
您在多大程度上担心必须扩展多核技能？ 您正在编写的软件是否适合并行化？如果是，您是否正在做任何事情来进行自我教育（如果您还不知道这些技术）？ 或者您是否相信操作系统会处理大部分事情，语言运行时会尽自己的一份力量，您的应用程序会愉快地坐在一个核心上，让其他核心做他们的事情？
This is undeniable: multicore computers are here to stay.
So is this: efficient multicore programming is pretty difficult. It's not just a case of understanding pthreads.
This is arguable: the 'developer on the street' need concern him/herself with these developments.
To what extent are you concerned about having to expand your skillset for multicore? Is the software you are writing a candidate for parallelisation, and if so are you doing anything to educate yourself (if you didn't already know the techniques)? Or do you believe that the operating system will take care of most of it, the language runtime will do its bit and your application will happily sit on one core and let the others do their thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（20）
您的程序通常是CPU密集型的吗？
如果没有，就忘记它吧。 它与您无关，并为您的用户提供更流畅的体验，而不对您提出任何要求。
酷吧？
如果您受 CPU 限制，并且您的问题是可并行的，那么您也许可以利用多个内核。 是时候开始担心它了。
来自评论：
CPU 限制 意味着阻止程序运行得更快的是缺乏计算能力。 与IO 绑定（或有时网络绑定）进行比较。 主板和处理器选择不当也会导致机器内存受限（是的，我正在看你，阿尔法）。
因此，您需要知道您的程序时时刻刻在做什么（以及机器有多忙......）要在类 UNIX 系统上运行
top来了解情况。 在 Windows 上使用任务管理器（感谢 Roboprog）。在每核负载小于 1 的机器上（即，当您没有做太多事情时的台式机），受 CPU 限制的进程将始终占用超过 50% 的处理器（通常超过 90%）。 当平均负载高于该值时（即您有三个编译、SETI@home 和两个在后台运行的对等网络），CPU 密集型进程将具有很大一部分
（核心数） /（平均负载）。Are your programs typically CPU bound?
If not, forget it. It doesn't concern you, and gives your users a smoother experience without making any demands on you at all.
Cool, eh?
If you are CPU bound, and your problem is parallelizable, you might be able to leverage the multiple cores. That's the time to start worrying about it.
From the comments:
CPU bound means that the thing preventing the program from running faster is a lack of computational horse-power. Compare to IO bound (or sometimes network bound). A poor choice of motherboard and processor can result in machines being memory bound as well (yes, I'm looking at you, alpha).
So you'll need to know what your program is doing from moment to moment (and how busy the machine is...) To find out on a unix-like systems run
top. On windows use the taskmanager (thanks Roboprog).On a machine with a load less than 1 per core (i.e. your desktop machine when you're not doing much of anything), a CPU bound process will consistently have more that 50% of a processor (often more than 90%). When the load average is higher than that (i.e. you have three compiles, SETI@home, and two peer-to-peer networks running in the background) a CPU bound process will have a large fraction of
(# of cores)/(load average).旁注：如果您的应用程序有 GUI 并进行大量计算，则始终在单独的线程上进行大量计算。 忘记这样做就是 GUI 冻结的原因。
Just a side note: If your app has a GUI and does intense computation, ALWAYS do your intense computation on a separate thread. Forgetting to do this is why GUIs freeze up.
我不同意当前接受的答案。
多核机器最重要的一点是CPU和主内存相距很远。 这意味着除非应用程序是“高度并行”或易于并行化，否则它很可能会受到内存限制，而不是 CPU 限制。 浮点乘法大约需要 4 个时钟周期，而从主内存读取内存需要数百个时钟周期。 因此，利用缓存局部性变得很重要。
对于难以并行化的应用程序，如果单核上达到的性能足够（大多数应用程序属于此类），则不需要并行化。 但如果不是（或者您的竞争对手的应用程序由于并行化而响应速度更快），那么您最好重构您的应用程序，以更好地利用并行性和缓存局部性。 模糊地，重构的应用程序将由相对独立（或较少沟通）的子模块组成，这些子模块并行运行（请参阅这个例子就是其中之一）。
请参阅http://www.eecs.berkeley.edu /Pubs/TechRpts/2006/EECS-2006-183.html 很好地概述了多核及其发展方向。 他们所说的要点是：
I do not agree with the current accepted answer.
The foremost important aspect of multicore machines is that CPU and main memory are far apart. This means that unless the application is "embarrassingly parallel" or easy to parallelize, it is highly likely that it would be memory bound, rather than CPU bound. A floating point multiplication takes about 4 clock cycles, while a memory fetch from main memory takes hundreds of clock cycles. Therefore, exploiting cache locality becomes important.
For difficult-to-parallelize applications, if the achieved performance on single core is sufficient (majority of the applications would belong the this class), there is no need to parallelize. But if it is not (or your competitor's application is much more responsive since they parallelized), then you would do better to refactor your application to better exploit parallelism and cache locality. Vaguely, the refactored application would consist of relatively independent (or less communicative) submodules, which run in parallel (see this example, for one).
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html for a good overview on multicore and the way things are heading. The major points they say are:
这是开始学习函数式语言的一个很好的论据，函数式语言更容易优化并行执行。
It's a good argument for starting to learn functional languages, which are easier to optimize for parallel execution.
温和地说，我认为这通常值得引起兴趣。
不用说，过去几十年来 CPU 速度的大幅提升是极其有价值的，进一步的提升也同样有价值。
但从现在开始，这些收益主要包括核心数量的定期翻倍。 因此，为了从这些收益中获益，软件需要可并行化。
许多应用程序的许多计算密集型部分实际上是用 SQL 编写的，因此它们已经可以正常工作并且能够被 RDBMS 分解为并行任务。 这样那些人就可以放心了。
但我们这些主要用 C# 编写的人，即使我们正在编写 GUI，我们也需要密切关注这些东西。 GUI 经常必须对其呈现给用户的任何模型执行一些有用的操作，而当用户必须坐下来等待它完成时，他们会感到恼火。 几年后，当他们查看任务管理器并发现他们精美的新 32 核机器的利用率约为 3% 时，他们会变得更加恼火。
I think this is generally worth taking an interest in, to put it mildly.
It hardly needs saying that the massive increase in speed of CPUs over the past few decades has been extremely valuable, and that further gains will be just as valuable.
But those gains will from now on mostly consist of a regular doubling in the number of cores. So to benefit from these gains, software needs to be parallelizable.
A lot of the computation-intensive parts of many applications are actually written in SQL, so they are already functional and capable of being broken down into parallel tasks by the RDBMS. So those people can relax.
But those of us writing mostly in C#, even if we're writing GUIs, we need to pay close attention to this stuff. A GUI frequently has to perform some useful operation on whatever model it presents to the user, and the user gets annoyed when they have to sit and wait for it to finish. They'll get even more annoyed in a few years time, when they look at Task Manager and see that around 3% of their fancy new 32-core machine is being utilized.
是的，我也一直在使用线程编程。 但我还没有受虐狂到爱他们的程度。 无论你是多么的超人，无论你从同事那里得到什么帮助，线程之间的串扰仍然太容易了。 线程很容易实现，但要正确实现却非常困难，所以 Joe-Schmoe 当然很喜欢它，而且它们速度很快！ （当然，这才是最重要的）
在 *nix 上，老式的 fork() 仍然是处理很多事情的好方法。 开销并不算太糟糕（是的，有一天我需要测量它来备份我的BS），特别是如果你分叉一个解释器，然后在子进程中生成一堆特定于任务的数据。
也就是说，我听说 Windoze 上的子进程非常昂贵。 因此，Erlang 方法看起来相当不错：迫使 Joe Schmoe 编写纯函数并使用消息传递，而不是他看似无限状态自动机全局（实例）变量 whack-fest 以及额外的线程串扰盛宴。
但我并不痛苦:-)
修订/评论：
其他地方关于记忆距离的精彩评论。 我最近也一直在思考这个问题。 标记和清除垃圾收集确实损害了正在运行的进程的“局部性”方面。 旧 80286 上的 0 等待状态 RAM 上的 M/S GC 可能看起来无害，但它对多级缓存架构确实有害。 在某些情况下，也许引用计数+fork/exit作为GC实现并不是一个坏主意？
编辑：我在这里付出了一些努力来支持我的演讲（结果各不相同）：
http://roboprogs.com/devel/2009.04.html
Yeah, I've been programming with threads, too. But I'm not masochistic enough to love them. It's still way too easy to get cross-talk between threads, no matter how much of a super-man you are, plus whatever help you get from coworkers. Threads are easy to do, but very difficult to do correctly, so of course Joe-Schmoe gravitates to it, plus, they're fast! (which is all that matters, of course)
On *nix, good old fork() is still a good way to go for many things. The overhead is not too bad (yes, I'll need to measure that to back up my BS some day), particularly if you are forking an interpreter, then generating a bunch of task specific data in the child process.
That said, child processes are hideously expensive on Windoze, I'm told. So the Erlang approach is looking pretty good: force Joe Schmoe to write pure functions and use message passing instead of his seemingly-infinite-state automata global (instance) variable whack-fest with bonus thread cross-talk extravaganza.
But I'm not bitter :-)
Revision / comment:
Excellent comment elsewhere about distance-to-memory. I had been thinking about this quite a bit recently as well. Mark-and-sweep garbage collection really hurts the "locality" aspect of running processes. M/S GC on 0 wait state RAM on an old 80286 may have seemed harmless, but it really hurts on multi-level caching architectures. Maybe referencing counting + fork/exit isn't such a bad idea as a GC implementation in some cases?
edit: I put some effort into backing up my talk here (results vary):
http://roboprogs.com/devel/2009.04.html
我认为可能发生的情况是，一旦大量核心（例如 8 个以上）变得普遍，我们就会看到利用并行性的应用程序的开发，而这在单线程世界中被认为是不可行的。
我想不出具体的例子，但想想当 3D 加速器变得普遍时发生了什么。 当时的游戏（比如《毁灭战士》）受到软件渲染代码速度的限制。 拥有高度详细的 3D 模型，甚至没有考虑模拟反射/折射和每像素照明。 现在每个人都这样做。
因此，除非您当前的应用程序高度依赖 CPU，否则我不会担心它们的并行化。 如果您发现通过多个核心拥有大量 CPU 能力，那么请考虑在新项目中利用它的方法。
I think what is likely to happen is that once large numbers of cores (say 8+) become commonplace, then we'll see development of applications that take advantage of parallelism that were not considered viable in a single-threaded world.
I cant think of specific examples, but consider what happened when 3D accelerators became common. Games at the time (think Doom) were bound by the speed of their software rendering code. Having highly-detailed 3D models, simulating reflection/refraction and per-pixel lighting were not even considered. Nowadays everyone does it.
So unless your current apps are highly CPU-bound, I would not worry about parallelising them. If you find you have heaps of CPU power via multiple cores, then look at ways to exploit it in new projects.
我认为这是一个很好的问题。 因此，我在此处开始撰写一系列有关它的博客文章。
Dmckee 的答案在最狭义上是正确的。 让我在这里用我自己的话重新表述一下，含蓄地包括一些评论：
就目前而言，这是正确的，但我相信对于更广泛的程序集来说，答案会更丰富。 事实上，在生产应用程序中使用多线程以及隐式多核技术的原因有很多。 例如，将磁盘和网络 I/O 操作移出用户界面线程对用户来说是一个巨大的好处。
这与增加计算密集型操作的吞吐量无关，而与保持程序的用户界面响应能力有关。 请注意，这里不需要图形用户界面 - 命令行程序、服务和基于服务器的应用程序也可以从中受益。
我完全同意，进行 CPU 密集型操作并使其瘫痪通常是一项复杂的任务 - 需要了解细粒度同步、CPU 缓存、CPU 指令管道等知识。事实上，这可能是典型的“困难”。
但是，我认为很少有必要这样做。 需要这种细粒度并行性的问题并不多。 是的！ 它们确实存在，你可能每天都会处理这个问题，但我认为在大多数开发人员的日常生活中，这种情况非常罕见。
即便如此，我们还是有充分的理由学习多线程以及多核开发的基础知识。
事实上，操作系统已经为您做了很多事情，您可以使用启用多核的库（例如 英特尔的东西）。 但是，操作系统和库并不神奇 - 我认为对于大多数开发人员来说，学习多线程编程的基础知识是有价值的。 这将使您能够编写出让用户满意的更好的软件。
当然，并不是每个程序都应该是多线程或多核的。 有些事情用简单的单线程方式来实现就好了。 因此，不要将此视为每个程序都应该是多线程的建议 - 在这里使用您自己的良好判断。 但是，它通常是一项有价值的技术，并且在许多方面都非常有益。 如上所述，我计划从此处开始撰写有关此内容的博客。 如果您愿意，请随时关注并发表评论
I think this is a great question. So, I've begun a series of blog posts about it here.
Dmckee's answer is correct in the narrowest sense. Let me rephrase in my own words here, implicitly including some of the comments:
That is true as far as it goes, but I belive the answer is richer for a broader set of programs. Indeed, There are many reasons to use multi-threaded, and then implicitly multi-core techniques in your production applications. For example, it is a huge benefit to your users to move disk and network I/O operations off your user interface thread.
This has nothing to do with increasing the throughput of compute bound operations, and everything to do with keeping a program's user interface responsive. Note, you don't need a graphical UI here - command line programs, services, and server based applications, can benefit for this as well.
I completely agree that taking a CPU bound operation and paralyzing it can often be a complex task - requiring knowledge of fine grained synchronization, CPU caching, CPU instruction pipelines, etc. etc. Indeed, this can be classically 'hard'.
But, I would argue that the need to do his is rare; there are just not that many problems that need this kind of fine grained parallelism. Yes! they do exist and you may deal this this every day, but I would argue that in the day to day life of most developers, this is pretty rare.
Even so, there are good reasons to learn the fundamentals of multi-threaded, and thus multi-core development.
Indeed, the OS already does a lot for you here, and you can use libraries that are multi-core enabled (like Intel's stuff). But, operating systems and libraries are not magic - I argue that it is valuable for most develops to learn the basics of multi-threaded programming. This will let you write better software that your users are happier with.
Of course, not every program should be multi-threaded, or multi-core enabled. It is just fine for some things to be implemented in a simple single threaded manner. So, don’t take this as advice that every program should be multi-threaded – use your own good judgment here. But, it can often be a valuable technique and very beneficial in many regards. As mentioned above, I plan on blogging about this a bit starting here. Feel free to follow along and post comments there as you feel inclined
决不！ 我是一名 Clojure 程序员！ ：D
No way! I'm a Clojure programmer! :D
我使用线程编程已经超过 15 年了。 我一点也不担心
I've been programming with threads for over 15 years now. I am not worried in slightest
我不担心。 这些概念并不太难，更多的开发人员编写多线程应用程序 = 有关该主题的更多材料 = 更容易弄清楚您需要什么。
I'm not worried. The concepts aren't too difficult and more developers writing multithreaded apps = more material on the subject = easier to figure out what you need to.
我认为，对于大多数程序员和应用程序来说，显着多核并没有比标准多线程开发具有显着的优势或潜力。 大多数人都有线程来完成顺序作业，并且没有太大的潜力将这些线程拆分为更小的单元。
恕我直言，显着多核的大部分好处将来自于底层框架的改进（例如数据库访问、IO、GUI 和 3D 工具包等），并且绝大多数开发人员将透明地受益。
此外，未来的静态分析工具可能能够推荐可以进一步拆分为线程的片段。
I would argue that for most programmers and applications, significant-multicore does not present a significant advantage or potential over standard multithreaded development. Most people have threads to accomplish sequential jobs, and there isn't that much potential for splitting up those threads to much smaller units.
IMHO, most benefits of significant-multicore would come from improvements to underlying frameworks (e.g., database access, IO, GUI and 3D toolkits, etc.), and the vast majority of developers would benefit transparently.
In addition, future static analysis tools may be able to recommend pieces that could be split further into threads.
嗯，由于我在 ASP.Net 中进行 Web 开发，因此我可以看到多核在以下几个领域发挥作用：
1）客户端。 如果有人想利用 Javascript 来运行诸如对一长串数据进行排序之类的操作，那么如何针对具有四核 CPU 的客户端进行优化呢？ 胖客户端会随着新版本的 IE、Firefox、Safari 和 Chrome 回归吗？
2) Web 服务器上的服务器端。 在 IIS 及其使用的 .Net 框架中，PLINQ 之类的东西如何帮助使用并行或并发编程来帮助加速处理请求？ 可以进行哪些类型的 IIS 设置来增强性能并根据硬件进行调整？
3) 中间件/数据库后端。 最新的 MS-SQL Server 或 Oracle 或 MySQL 如何处理使用多核和多插槽的附加资源，例如，如果四插槽主板的每个插槽中有四核 CPU，并且顶部有超线程之类的功能，则有 32 个可以同时运行的线程，这与当时的单核 CPU 确实不同。
此外，对于 GPU 的多核方面也有话可说，其中 Crossfire 和 SLI 是开始，但现在有更多的混合图形解决方案，人们可能想知道未来将如何利用它，例如 AMD 的 Fusion 是一个想法我不确定它会做得多好，但这是我最后听说的。
关于自我教育，我不确定在某些情况下优化我的代码会有多大帮助。 我更感兴趣的是 IIS 将如何尝试利用之前的新计算领域，因为这最终可能会限制一些可以完成的事情，即使我隔离我的代码以在它自己的小世界中运行。
这些只是我目前的想法，随时可能改变。
Well, since I do web development in ASP.Net, there are a few areas I could see multicore playing a role:
1) Client-side. How can something like Javascript be optimized for the client that has a quad-core CPU if that is what someone wants to harness in running something like sorting a long list of data. Are fat-clients coming back with the new versions of IE, Firefox, Safari and Chrome?
2) Server-side on a web server. Within IIS and the .Net framework that it uses, how do things like PLINQ help use parallel or concurrent programming to help speed up handling requests? What kinds of IIS settings can be done to enhance performance and tune it to the hardware?
3) Middleware/DB Back-end. How does the latest MS-SQL Server or Oracle or MySQL handle using the additional resources of both multi-core and multi-socket, e.g. if a quad-socket motherboard has quad core CPUs in each socket and something like Hyperthreading on top there are 32 threads that could run at once which is really different than a single core CPU back in the days.
In addition, there is something to be said for the multicore aspects of GPUs where Crossfire and SLI were the beginning but now there are more hybrid graphics solutions that one can wonder how this will be harnessed in the future, e.g. AMD's Fusion is one idea that I'm not sure how well it'll do but it is coming last I heard.
On the subject of educating myself, I'm not sure how hard would optimizing my code would help in some cases. I'm more interested in how will IIS try to harness the new computing realm before it as that could ultimately be limiting some things that can be done, even if I isolate my code to run in its own little world.
These are just my current thoughts and are subject to change at any moment.
不，我不担心。
我的工作有点不寻常，可能比平均水平更容易并行，但无论如何，我认为这更多的是一个机会而不是一个问题。
部分原因是我对事情发展到真正值得针对多核进行优化的地步感到不耐烦。 我目前不知道确切的数字是多少，但我们的客户似乎有一半拥有单核机器，49% 有双核，也许 1% 有四核。 这意味着在大多数情况下，多线程并不能真正带来巨大的性能提升，因此并不值得花费太多时间。
几年后，当平均水平可能是四核时，将会有更多的情况需要花一些时间在聪明的多线程代码上 - 我认为这对我们开发人员来说将是一件好事。 我们所需要的只是英特尔和 AMD 快点生产更多这样的产品......:-)
No, I'm not worried.
My work is a little unusual and possibly parallelises more easily than average, but regardless I see it as more of an opportunity than a problem.
Partly I'm impatient for things to get to the point where it's really worth optimising for multicore. I don't know what the exact numbers are at the moment, but it seems like half our clients have a single-core machine, 49% have dual core and maybe 1% have quad. That means that multithreading doesn't really give that a huge performance gain in most cases and hence isn't really worth spending much time on.
In a few years time, when the average might be quad-core, there's going to be a lot more case for spending a bit of time on clever multithreading code - which I think is going to be a good thing for us developers. All we need is for Intel and AMD to hurry up and make more of them... :-)
我的一位面向硬件的教授告诉我们（好吧，宣讲），这是计算机科学的一个非常重要的领域。 更重要的是，这个问题要么由操作系统来解决（我注意到苹果的表现如此强劲，微软可能也是如此），要么编码员自己需要考虑并行执行（线程等......）。
CS领域相当整洁。 :)
One of my hardware-oriented professor tells us (well, preaches), that this is a massively important area of Computer Science. More so, it'll be addressed either by the OS (I noticed Apple is hitting this strong, MS is probably as well), or the coder himself will need to be thinking about parallel execution (threading, etc...).
Quite a neat area of CS. :)
作为一名独立游戏开发者，我实际上对此感到非常兴奋。 有些游戏在活跃时刻会受到 CPU 限制。 几乎所有现代 3D 游戏都对硬件要求很高。 过去几年，多核一直是视频领域的法则。 现在一些 nvidia 卡拥有超过 200 个核心。
为这些卡编写着色器是一种乐趣，我迫不及待地想看看越来越多的多进程机器会产生什么结果。
我认为随着时间的推移，这种需求将产生更好的线程支持。 我们仍然有一些疯狂的方案，例如 apaches MPM-Worker 模型，您可以同时混合多个进程和线程。 我希望看到像绿色线程这样的东西得到更好的采用，它们似乎都在同一个进程中，但实际上分布在核心上。 但当然，有人必须在共享内存方面有一些突破性的想法才能实现这一目标。
短期来看：这没什么大不了的，除非你毁坏了你的处理器
长期来看：更好地使用锁:)
As an indie game developer I'm actually very excited about it. Several games go CPU bound during active moments. And almost all modern 3D games are very taxing on the hardware. Multicore has been the law of the land for video for the past several years. With some nvidia cards nowadays having over 200 cores.
Writing shaders for these cards is a pleasure, and I can't wait to see what comes out of more and more machines being multi-proc.
I think this need will spawn better threading support over time. We still have crazy schemes like apaches MPM-Worker model where you get a mix of several processes and threads at the same time. I'd like to see better adoption of things like green-threads, where they seem to all be in the same process, but are actually distributed over cores. But of course someone will have to have some breakthrough idea with shared memory to pull that off.
Near term: It's not a big deal unless you're crushing your processor
Long term: Better get comfy with locks :)
数据流编程有望为多核问题提供相对简单的解决方案。
不过，正如维基百科所说，它需要相当大的范式转变，这似乎阻碍了编程社区轻松采用它。
Dataflow programming shows some promise for a relatively easy solution to the multicore problem.
As wikipedia says, though, it requires a fairly major paradigm shift, which seems to prevent its easy adoption by the programming community.
我一直在思考的问题是，大多数分而治之的算法不是可以大规模并行化的吗？ 每个拆分应该能够在两个单独的线程中运行...
无论如何，当我需要担心时我会担心。 当我的程序开始变慢时，我会寻找加快速度的方法。 不幸的是，这是我工作中的一个问题。
The thing I've been thinking about, is aren't most divide-and-conquer algorithms massively parallelizable? Every split should be able to be run in two separate threads...
Anyway, I'm concerned when I need to be concerned. When my program starts getting slow, then I'll look for ways to speed it up. Unfortunately, this is a problem in my line of work.
在日常工作中，我并没有过多考虑多核编程，但它始终在我的关注范围内。
我在并行处理方面一直遇到的最大问题是确定应该并行化什么？ 分出一个线程来后台处理文件很容易，但是文件处理本身可以并行吗？
我认为什么可以并且应该并行化的问题可以通过在应用程序已经很复杂的架构决策之上分层的复杂架构决策来回答。 我相信这种复杂性将通过操作系统或编程语言来解决。 C 及其后代中的传统并行线程模型并不是最终的答案。
Day-to-day I don't think much about multi-core programming, but it's always on my radar.
The biggest problem I've always had with parallel processing is determing what should be parallelized? It's easy to spin-off a thread to background process a file, but can the file processing itself be parallelized?
I think the questions of what can and should be parallelized are answered with complex architectural decisions layered on top of the already complex architectural decisions of the application in general. My belief is that this complexity will be solved either by the OS or by the programming language. The traditional thread model of parallelization found in C and its descendants is not the final answer.
不会。我认为多核将在某些编程领域产生重大影响，但几乎不会影响其他领域。 一段时间后，它所涉及的领域将吸收它并封装它，炒作将几乎不会触及其他领域。
No. I feel that multicore will make a significant difference in certain areas of programming but will barely affect other areas. After a while the areas it does will absorb it and encapsulate it and the hype will barely touch the other areas.