代码之家  ›  专栏  ›  技术社区  ›  HenryR

你担心多核吗?[关闭]

  •  13
  • HenryR  · 技术社区  · 17 年前

    这是有争议的:“街头开发商”需要关注这些开发项目。

    你在多大程度上担心必须扩展你的多核技能?你正在编写的软件是并行化的候选者吗?如果是这样,你是否在做任何教育自己的事情(如果你还不知道这些技术)?或者,你是否相信操作系统会处理大部分工作,语言运行库会各司其职,你的应用程序会愉快地坐在一个核心上,让其他核心做自己的事情?

    20 回复  |  直到 17 年前
        1
  •  27
  •   dmckee --- ex-moderator kitten    17 年前

    你的


    改进答案的建议:粗略解释

    这意味着阻止程序运行得更快的是缺乏计算能力。与比较 IO绑定 (或有时 网络绑定 内存限度 α)。

    top

    在每个核心负载小于1的机器上(即当你什么都不做的时候,你的台式机),CPU受限的进程将始终拥有超过50%的处理器(通常超过90%)。当负载平均值高于此值时(即您有三个编译,SETI@home,以及在后台运行的两个对等网络)一个CPU密集型进程将具有很大一部分 (# of cores)/(load average) .

        2
  •  21
  •   mghie    17 年前

        3
  •  12
  •   amit kumar    17 年前

    多核机器最重要的方面是 CPU和主存储器相距甚远 这意味着,除非应用程序是“令人尴尬的并行”或易于并行化的,否则它很可能是内存受限的,而不是CPU受限的。 浮点乘法大约需要4个时钟周期,而从主存储器中读取内存需要数百个时钟周期 因此,利用缓存局部性变得重要。

    this example

    http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html 为了对多核技术及其发展方向有一个很好的概述。他们说的要点是:

    • 时钟速度不再像以前那样增加。
    • 内存离CPU越来越远
    • 几年后,将有 1000个核心
    • .
        4
  •  8
  •   Morendil    17 年前

        5
  •  6
  •   Daniel Earwicker    17 年前

    委婉地说,我认为这通常值得关注。

    但从现在开始,这些收益将主要包括核心数量的定期翻倍。因此,为了从这些收益中受益,软件需要可并行化。

    许多应用程序的许多计算密集型部分实际上是用SQL编写的,因此它们已经具有功能,并且能够被RDBMS分解为并行任务。所以这些人可以放松。

    但是,我们这些主要用C#编写的人,即使我们正在编写GUI,也需要密切关注这些东西。GUI经常必须对它呈现给用户的任何模型执行一些有用的操作,当用户不得不坐下来等待它完成时,他们会感到恼火。几年后,当他们看到任务管理器时,他们会更加恼火,因为他们看到大约3%的新型32核机器正在被使用。

        6
  •  6
  •   Roboprog    17 年前

    是的,我也一直在用线程编程。但我没有足够的受虐狂来爱他们。无论你是多么的超人,再加上你从同事那里得到的任何帮助,在线程之间产生串扰仍然太容易了。线程很容易做到,但很难正确做到,所以乔·施莫当然会喜欢它,而且它们很快!(当然,这才是最重要的)

    在*nix上,好的旧fork()仍然是许多事情的好方法。开销还不算太糟糕(是的,总有一天我需要测量它来备份我的BS),特别是如果你要分叉一个解释器,然后在子进程中生成一堆特定于任务的数据。

    但我并不苦涩:-)

    修订/评论:


    http://roboprogs.com/devel/2009.04.html

        7
  •  4
  •   mghie    17 年前

    我认为,一旦大量内核(比如8+)变得司空见惯,那么我们就会看到利用并行性的应用程序的开发,而这些并行性在单线程世界中是不可行的。

    因此,除非你当前的应用程序高度占用CPU,否则我不会担心将它们并行化。如果你发现你通过多个内核拥有大量的CPU能力,那么看看在新项目中利用它的方法。

        8
  •  4
  •   Foredecker    17 年前

    here .

    Dmckee的回答在最狭义上是正确的。让我在这里用自己的话重新措辞,隐含地包括一些评论:

    不受CPU限制的操作。 短时间,比如说,少于 几百毫秒。的确, 程序更复杂,而且有缺陷。 学习如何实现细粒度 并行性是复杂而复杂的 这很难。

    就目前而言,这是真的,但我相信,对于更广泛的项目来说,答案会更丰富。事实上,在生产应用程序中使用多线程和隐式多核技术有很多原因。例如,将磁盘和网络I/O操作移出用户界面线程对用户来说是一个巨大的好处。

    这与提高计算受限操作的吞吐量无关,而与保持程序的用户界面响应性有关。注意,这里不需要图形用户界面——命令行程序、服务和基于服务器的应用程序也可以从中受益。

    我完全同意,执行一个CPU受限的操作并使其瘫痪通常是一项复杂的任务,需要了解细粒度同步、CPU缓存、CPU指令管道等知识。事实上,这可能是典型的“困难”。

    即便如此,也有充分的理由学习多线程的基础知识,从而学习多核开发。

    Intel's stuff ).但是,操作系统和库并不是魔法——我认为,对于大多数开发人员来说,学习多线程编程的基础知识是有价值的。这将让你编写更好的软件,让你的用户更满意。

        9
  •  3
  •   Rayne    17 年前

        10
  •  2
  •   Gregor Brandt    17 年前

    我已经用线程编程超过15年了。我一点也不担心

        11
  •  2
  •   Spencer Ruport    17 年前

        12
  •  2
  •   Uri    17 年前

    我认为,对于大多数程序员和应用程序来说,与标准多线程开发相比,显著的多核并没有显著的优势或潜力。大多数人都有线程来完成顺序作业,将这些线程拆分为更小的单元的可能性不大。

        13
  •  1
  •   JB King    17 年前

    嗯,因为我用ASP做web开发。Net,我可以看到多核在几个领域发挥作用:

    1) 客户端。如果有人想利用Javascript这样的东西来运行排序一长串数据,那么如何为具有四核CPU的客户端进行优化呢。胖客户会带着IE、Firefox、Safari和Chrome的新版本回来吗?

    3) 中间件/DB后端。最新的MS-SQL Server、Oracle或MySQL如何使用多核和多插槽的额外资源进行处理,例如,如果四插槽主板的每个插槽中都有四核CPU,并且上面有超线程之类的东西,那么可以同时运行32个线程,这与过去的单核CPU非常不同。

        14
  •  0
  •   Peter    17 年前

    我的工作有点不同寻常,可能比平均水平更容易并行,但无论如何,我认为这更多的是一个机会而不是问题。

    几年后,当平均值可能是四核时,将有更多的理由花一点时间在聪明的多线程代码上——我认为这对我们开发人员来说是一件好事。我们所需要的只是英特尔和AMD加快步伐,生产更多的产品。.. :-)

        15
  •  0
  •   Rev316    17 年前

    我的一位勤奋的教授告诉我们(好吧,宣扬),这是计算机科学的一个非常重要的领域。更重要的是,它要么由操作系统来解决(我注意到苹果的表现很好,微软也可能如此),要么程序员自己需要考虑并行执行(线程等)。

        16
  •  0
  •   Trey Stout    17 年前

    近期:这没什么大不了的,除非你的处理器崩溃了

        17
  •  0
  •   Joe Z    17 年前

    Dataflow programming 显示了多核问题相对简单的解决方案的一些前景。

    然而,正如维基百科所说,它需要一个相当大的范式转变,这似乎阻碍了它被编程社区轻松采用。

        18
  •  0
  •   mpen    17 年前

    我工作中的一个问题。

        19
  •  0
  •   byamabe    17 年前

        20
  •  0
  •   BubbaT    17 年前

    不。我觉得多核将在某些编程领域产生重大影响,但几乎不会影响其他领域。一段时间后,它所做的领域会吸收并封装它,炒作几乎不会触及其他领域。

    推荐文章