Dan*_*kov 9 c c++ concurrency erlang haskell
今天我正在编写Erlang编程书中的线程环练习,并搜索其他解决方案进行比较.我发现语言枪战与基准测试有着完全相同的问题.我的印象是,这是一个Erlang应该很快的领域,但事实证明C和C++再次位居榜首.我怀疑C/C++程序没有遵循"将令牌从线程传递给线程"的规则.在阅读它们之后,似乎它们都操纵了一些与Erlang代码不同的共享内存和全局变量,但我可能错了.
我的问题是:他们是在做同样的事情还是C/C++代码在概念上与Erlang代码不同(并且速度更快)？
还有一个问题:当解决方案非常相似时,为什么Haskell比Erlang更快？
C版本正在使用LWP,我认为它是一个用户空间线程库.这种"不公平"在多大程度上引起争论:我会考虑一下它是否支持真正的先发制人并发,因为你可以在线程中进行阻塞系统调用而不会阻塞所有其他线程(你可以在Haskell中这样做,你能在Erlang吗？).
Haskell的线程比Erlang稍微轻一些,因为据我所知,Erlang线程带有本地堆(在标准实现中),而Haskell线程都共享相同的堆.
最终,现代机器上的消息传递是使用某种形式的共享内存来传递消息(以及锁或原子指令).因此,所有C和C++实现实际上都在将消息传递的实现直接内联到其代码中.在C中使用快速消息传递库的类似基准测试,也是针对Haskell和Erlang的基准测试,可以在本文中找到:http://www.cs.kent.ac.uk/pubs/2009/2928/index. HTML(第5.1节)
各种方法的速度实际上取决于所涉及的并发运行时系统.Haskell在这个领域做了很多很好的工作,使得它领先于Erlang.当然,测量微基准测试的速度通常是错误的,并且遗漏了诸如代码可读性之类的重要因素.要记住的一个问题可能是:你会乐于维持枪战中的哪些解决方案？
我不认为我称之为作弊.多线程和多个进程之间的主要根本区别在于多个线程共享一个地址空间.因此,在我看来,指定多个线程(而不是多个进程)似乎默认利用共享地址空间(至少在没有一些非常具体的"传递"定义的情况下禁止这个).
它归结为:Erlang并不真正拥有线程,因为它具有异步通信的进程.这些过程在很大程度上(有意地)彼此隔离.一方面,这使得开发变得相当容易 - 特别是,一个过程只能通过特定的,明确定义的通信渠道影响另一个过程.在幕后,它使用了许多技巧(几乎可以肯定包括共享内存)来优化其流程并利用特定实现/情况下的可能性(例如在单个共享地址空间中运行的所有进程).尽管如此,不得不隐藏所有技巧,这使得它不像C版本那样有效,其中"技巧"都是明确且完全暴露的.
我会用现实的比喻来解释它们之间的区别.将线程/进程视为人.Erlang强制建立专业的工作关系,通信都记录在备忘录中.C和C++版本更像是丈夫和妻子,可能会与一个单词进行交流,这对任何人都没有任何意义,甚至只是一瞥.
后者在工作时非常有效 - 但它更容易受到微妙的误解,如果两个人打架,你可能不想在同一个房间里.对于经理来说,即使他们的最高效率不是很高,但纯粹职业关系中的人也更容易管理.