英特尔刚刚推出了一款新的48核CPU。对于我们程序员来说,这种向多核的迁移意味着什么?[闭门]

会完全分开在什么地方呢 存储在本地二级缓存中。

编程必须专注于编写耦合度非常低的模块,这些模块将公开其功能并将其作为服务提供。随着编译器意识到可扩展处理器体系结构,他们将“知道”将这些模块分配给各自的处理器,并有可能在处理器之间实现模块冗余——在各自的处理器上运行同一模块的多个副本,且此类副本的数量动态变化,以扩展到每个模块具有的每个时间单位的请求数。

因此,基本上,负载平衡也将成为桌面的一个选项,特别是对于必须由大量进程同时频繁调用的核心操作系统功能而言——拥有内核的冗余副本将确保更多进程在同一时间完成更多工作,而无需等待操作系统。

这意味着我们都应该学习Erlang或其他为并发设计的函数式语言。

通过使用互斥体和其他技术手动协调多个线程的创建和交互来实现并发编程,这与试图用一种本机不支持OO的语言进行OO设计一样麻烦且容易出错。不可变数据和函数式编程风格自然适合并发(许多专门为并发设计的函数式语言就是明证)。我怀疑,随着处理器性能通过并行性的提高而扩展,开发人员将越来越多地关注函数式语言,以利用这种处理能力,直到最终函数式语言占据主导地位。

赫伯·萨特发表了几篇文章 articles on effective concurrency .

作为介绍,你可以阅读他的优秀文章 "A Fundamental Turn Toward Concurrency in Software"

理想的情况是它对90%的程序员来说毫无意义。

有几个建议,比如平行线扩展, Microsoft Axum 或 Erlang

这句话听起来像是在说拉拉比?在这种体系结构上,您不能忽略多核,因为处理核更简单,运行编译器此时生成的代码也会更慢,特别是因为它们按顺序执行指令(这样可以节省芯片大小并产生更简单的核)。

一般来说,多核对于服务器来说是非常好的,典型的服务器代码无需修改即可扩展。

在桌面上,大多数单线程代码对于当前的几代人来说都很好。如果程序的计算成本很高,那么开发人员就可以很容易地将工作转移到多个核心上。

但是,我认为,许多核心系统不适合桌面使用。当应用程序将为此进行优化时,将引入一种新的延迟,总的来说,这可能会在应用程序中引入明显的UI延迟。对于用户来说,它可能会感觉反应不快,这反过来会被认为是“慢”!造成这种情况的原因是,当开发人员将工作负载分割成更小的数据包,并将它们排在工作队列中,然后发送信号开始处理它们时,会有更多的调度工作。

该IMHO甚至适用于基于消息传递的代码(erlang&co.)——尽管延迟比锁&基于信号的代码,但他们也总结。

我们将需要做许多小任务,解决小问题,但它们是相互联系在一起的。听起来很奇怪

大的单片顺序码将越来越被轻视。

不管怎样,多年来我一直在听这个“哦,没有几十个核心”。作为一个行业,我们在使单线程顺序代码正确工作方面有足够的困难。当Firefox崩溃或IE无法正确渲染时,您会意识到添加更多内核对这种情况毫无帮助。在工作中,我有一个4核的盒子,它的内核已经超过了我的任何软件所能使用的。除非你是一个游戏玩家,或者做HPC或者云主机,否则你可能在很多时候都不会受到CPU的限制,如果有的话。

这是一份关于实验设计的新闻稿。这就像法拉利吹嘘新的10升18缸发动机:听起来很酷,它可能会在街上卖更多的法拉利,但99.999%的人实际上不必担心以130英里/小时的速度驾驶。

但相当多的人是游戏玩家,世界上大部分的处理能力都位于大型机上,处理事务、数据库,是的,还有云主机。。。HPC超级计算机也使用并行处理器集群构建,用于大规模并行计算。

我真的希望我能提供关于它对程序员意味着什么的见解,但我仍然需要掌握Java中的多线程,我唯一能说的是,对于48个内核手动执行它将是一件令人头痛的事情。如果编译器足够聪明,递归算法可以有效地使用它。不太清楚Java,但上次我在Python中尝试递归算法时,它只在一个内核上运行。