|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-05-26
<p>ACE我们公司也用了很久了</p>
<p>每一个任务并不一定是和一个线程对应，使用线程池或者单线程都可以，我指的是每一个任务相关的需要处理的数据的一个队列 </p> <p>当你需要解藕，并且任务之间需要相互通讯、相互同步的时候，这些队列极有可能是需要的 </p> |
| 返回顶楼 | |
|
发表时间：2007-05-26
嗯，明白你的意思了。
btw，potian有空的话，不妨谈谈在公司项目中使用Erlang的一些经验和想法吧：） |
| 返回顶楼 | |
|
发表时间：2007-05-26
ACE的跨平台特性的问题另说,ACE对在降低网络应用复杂度上做的非常有限.类似ACE_TASK这样handle call back的方式,在处理简单的应用并没有太大的问题,但是一旦通信的逻辑变的复杂起来,本来非常清晰的同步通信交互流程就要手工的拆开,靠自动状态机来维护.这还不算,因为要保持通信点上的互相同步,几乎每一个状态上发送一个消息以后不仅仅要等待feedback消息同时还要用数个timeout维护出错的情况,这就相当于把工作量提高了一倍不止.有的时候你甚至还要为了防止消息到达先后不一致产生的逻辑错乱,而给每个状态上设定一个消息标号,那些消息是你想要的,那些消息是过期的.这就相当于一个状态上再维护若干个子状态.
这是其一,其二流程的拆分取决于每个状态响应的时间,如果一个状态下操作过长你就不得不把原来一个单一的逻辑拆成两个.而且这种分拆往往不是系统设计,编码时候会遇到的问题,而是往往在最后性能调优阶段,你总是会发现某一个状态在大并发量下响应缓慢而把消息队列给撑爆,这个时候你又要在这个状态上进行切分,这个工作量就会非常之大. 当然,可以通过windows下的fiber或者linux下的ptx_switch_context来做coroutine,但是复杂度降低的仍然很有限. |
| 返回顶楼 | |
|
发表时间：2007-05-26
[quote="AvinDev"] 对于每个job自己的一个队列这种方式，我同事认为它存在线程切换开销以及锁的开销，调试也不方便。[/quote] 一般来说,每个job自己一个队列的方式用linux自己写调度是一个比较好的办法可以做到没有context_switch没有lock开销,我前一个公司是做softswitch的,他们就是这么干的.当然这其实相当于自己写了一个erlang的调度器. |
| 返回顶楼 | |
|
发表时间：2007-05-27
C++写多线程，为了减少线程数量就得大量使用异步方式，这个也很难写，算法就更难分片了，特别是要平均分配到多个CPU上，最后还要把结果汇总。erlang不知道有没有这方面的优势，估计还是免不了要自己spawn，看那个pmap的实现应该是可以方便地做任务分割再结果汇总了。
上次看程序员杂志有一篇介绍，erlang在发送消息时会把process调度到同一个线程里，不知道发完了还会不会放回去，不会造成一轮消息过后全跑到一个线程上去了吧？ |
| 返回顶楼 | |
|
发表时间：2007-05-27
[quote="qiezi"]C++写多线程，为了减少线程数量就得大量使用异步方式，这个也很难写，算法就更难分片了，特别是要平均分配到多个CPU上，最后还要把结果汇总。erlang不知道有没有这方面的优势，估计还是免不了要自己spawn，看那个pmap的实现应该是可以方便地做任务分割再结果汇总了。 上次看程序员杂志有一篇介绍，erlang在发送消息时会把process调度到同一个线程里，不知道发完了还会不会放回去，不会造成一轮消息过后全跑到一个线程上去了吧？[/quote] 这样的细节应该是应用自己来取舍和解决的。 |
| 返回顶楼 | |
|
发表时间：2007-05-28
dcaoyuan 写道： [quote="AvinDev"]比如要测试多个字符合并为一个列表，用 [$a] + [$b] + ... 的效率就比 lists:reverse([$z[$y[...[$a]...]]) 差 [/quote]
lists:flatten([$a, $b, "A String", $z]) avindev 做了测试，结果是flatten的效率比++差，看来我主观了，因为ejabbed里喜欢用flatten。连接： http://avindev.iteye.com/blog/82560 最近用Erlang多了，对list的了解也好了些，在这里更正一下有关字符合并为list的描述： 1、lists:reverse([A|Acc])效率最高，但用于合并比较多的字符不够直观； 2、lists:flatten(DeepList)应该用于展平depth > 1的list 3、对于depth = 1的list，展平应该用lists:append，效率比lists:flatten好； 4 、lists:append与++是等价的。 这些在Efficiency Guide和lists的文档中有讲。 |
| 返回顶楼 | |
|
发表时间：2007-05-28
我的习惯是，首先采用reverse，基本上不考虑flatten，只有不循环的时候才采用++
|
| 返回顶楼 | |
|
发表时间：2007-05-28
<p>ACE 这类东西，我感觉主要的价值在于拿来解决跨平台的问题，它的那几个 reactive/proactive 的框架，用起来并不舒服。</p>
<p>在处理并发 IO 这一块，我现在见过比较好的解决方案还是 windows 下面的 IO Completion Port + Fiber 的方式，可以接近做到在利用异步 IO 提高效率的同时，允许书写上层代码的程序员将 IO 视为一个同步的操作。这个已经相当理想了，主要问题还是在于 1.工作量，2.可移植性，3.无法自然扩展到多台机器构成的集群上去。</p> |
| 返回顶楼 | |
|
发表时间：2007-06-10
<p>
引用 C++线程数多了效率下降得比较厉害，每连接一线程方式比较容易编写，也能很方便地处理一些超时。erlang在4CPU上用-smp启动，只会启动4个线程，这当然是最优化的方式了。通过优化减少线程数量，C++肯定能占上风，不过我总是会有不同的需求，erlang可以用统一的风格来处理，C++就不得不费尽脑汁去实现了，往往耗费苦心所写的代码性能高不了太多，代码量开发周期肯定就上去了 </p>
<p>比较关心erlang的线程调度效率，自己管理也得保存上下文吧，估计肯定比操作系统调度效率低。 </p> <p>如果这样，在并发性能上erlang应该低于java(NIO,native thread)，那使用erlang的唯一理由就在它的天生集群支持能力了，如何实现的谁来给扫扫盲。</p> |
| 返回顶楼 | |
