观点与争锋:多重处理器计算的挑战远在技术层面之上

  • Sadek Drobi
  • 孙涛

2008 年 7 月 6 日

话题:架构DevOps语言 & 开发

多核处理器 (multi-core processors ) 和松散耦合系统(loosely coupled systems,如因特网)是多重处理器计算 (multiple processor computing) 这一新趋势的两大推动力量,Peter Van Roy 在 2008 国际计算机音乐会议 (International Computer Music Conference 2008) 上就此两种形式并行计算的相关问题发表了看法(PDF)。

对多核处理器——即集成两个或者多个处理单元的处理器,这些处理单元“共享与系统的连接,而且往往会有共同的片上缓存”——Peter Van Roy 认为其挑战在于社会学方面。数据流编程“对此类机器上的编程来说是一个简单自然并且功能强大的方法”,同时“不存在竞态条件的确定性并发 (deterministic concurrency,译注 1) 能很好挖掘并行处理器的潜力,其编程难度也与顺序执行的程序相当。”因此,目前解决问题的方法在于“对程序员进行并行编程的相关培训”以充分利用已有技术而非开发新的技术,Google 正是遵循这个思路在 MapReduce 中应用了数据流思想。

然而,Marijn Haverbeke在 Lambda the Ultimate 上对此回应时强调,即使对多核并行来说“目前已经有很多技术和相关资料文档”,“在特定的场景或者性能需求下,目前存在的一些技术还是远不够的,因为它们 [...] 在通用性、可组装性、效率方面都不足以解决所有的问题,都不够银弹。”

Peter Van Roy 接着讨论了松散耦合系统编程方面,他认为当前此方面面临的挑战比多核编程要大。此类系统可视作由“一组联网处理器”组成,分布式系统所固有的一些问题在其上都有所体现:

— 对全局信息 (global knowledge) 缺乏把握,即任何节点对系统都没有一个整体认识,只能通过发送信息的方式了解其他节点的信息;

— 部分失效 (parital failure),即某一结点脱离系统或者工作异常。

Van Roy 认为这些只是“低层次的问题”,可以通过正确的算法加以克服,这些算法包括“时钟同步、分布式快照和容错”等。

然而,松散耦合系统拥有更高层次的问题。首当其冲的便是在点对点文件共享中出现的“目标冲突”的问题,这也通常被称为“不速之客问题”(freeloader problem),解决的方法是“从设计上使单个节点的目标与整个系统的总体目标相重合”,以打消不速之客的念头。Van Roy 举了 BitTorrent 协议及其工具的例子来说明如何实现这个目标。另一个问题是突现行为 (emergent behavior) 的处理,即只有在系统作为整体时才会出现的行为,单独节点是不会出现此类行为。但是 Peter 认为,这恰恰可以当作一个发明新理论、开发新工具的契机。例如 Google 的 PageRank 算法从互联网网页集出发来搜集信息,用于评估页面的有用性、正确性和受欢迎程度,这些都是无法从单个网页中得到的。

在松散耦合系统设计上,Peter Van Roy 推荐分散式架构 (decentralized architecture)。在这种架构中“每个计算节点都是默认独立于其他的节点,它拥有完整的程序。即使节点间失去联系,单独的节点仍然可以继续工作。一旦通讯恢复,节点又可以接着利用其它节点的信息”。Peter 认为分散式架构对解决由于系统分布而带来的问题很有效,他还列举了几个应用此种架构方式构建的工具的例子。

“我们应该对‘松散耦合’系统和‘广分布式’系统 (widely distributed systems) 进行进一步区分”,Scott Johnson 在 Lambda the Ultimate 对 Van Roy 的发言评论到,这是因为“对于后者,我们必须要防范各种类型的攻击”,想当然地认为“不存在恶意攻击的实体,节点都位于单独的管理域,技术参数(带宽、延迟)都令人满意”,是错误的。他建议应该根据一系列特征对系统进行细分,例如确定式调度、拓扑特征、迁移特性、局部失效特性、全局的一致性(全局信息的把握)、带宽、延迟等等。

译注 1:所谓确定性,指程序的执行结果不受调度的影响。

英文原文:Opinion: Multiple Processor Computing Challenges go Beyond Purely Technical Issues

架构DevOps语言 & 开发