|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-05-25
[quote="qiezi"]原来如此，的确是很方便。我脑子还停留在ACE/twisted上，其它语言里都会尽量避免数据拷贝，erlang里面数据切分、拼接（比如list/binary的组成，分割）会不会影响效率呢？另外binary和list的转换是否影响效率，很多东西还不明白，甚至没看到哪个手册上明确告诉我应该用list还是binary，在学习其它语言时最有用的cookbook，erlang版本的目前也很不完整，感觉缺少指导性的东西。某些东西我能实现出来，但可能不是最优化的实现，最贴近语言风格的实现。[/quote] 脑子里根深蒂固的东西克服起来很费劲，我的erlang代码基本上都是erlang语法的c++程序 ：| |
| 返回顶楼 | |
|
发表时间：2007-05-25
[quote="pi1ot"]erlang的socket io归根到底还要去走他自己的port机制，粗浅看了看数据复制是少不了的，既然用erlang就没必要再和c++比单机性能了，也很难真正比的过。我们已经在测试并且准备使用ejabberd，和c++实现的jabber server比起来单机性能是差不少的。但是ejabberd可以很容易的组成多服务器的集群，而且处理能力基本随节点数线形增加，就凭这一点，我就对ejabberd相当有好感了，这也才是erlang真正的优势所在。 [/quote] 对，erlang的优势在于并发，而不是速度快 |
| 返回顶楼 | |
|
发表时间：2007-05-25
lukeshei 写道 三. Concurrency Programming 1. fork 原始的程式 (程式+資料) --fork(複製一份)(程式+資料) 當程式fork 後,child 繼承原來的資料,此後彼此不相關,如果要傳遞資訊,需要使用pipe sharememory 或是 unix socket 來做資料交換 2. thread 事實上在Linux 系統下，執行緒只是一個light weight process：Linux 核心是以fork() system call 來產生一個新的行程（process），而執行緒是以clone() system call 產生的。fork()和clone()的差別只是在clone()可以指定和父行程共用的資源有哪些，當所有資源都和父行程共用時就相當於一個執行緒了。因為Thread 的使用會讓子父行程共用資源,因此非常容易引發dead lock / race condition …這類的問題 关于第一条，在thread大行其道的今天，还有人用fork这种方法？ 对第二条也有疑问，难道在Linux 2.6的kernel下还是这样？ |
| 返回顶楼 | |
|
发表时间：2007-05-25
qiezi 写道 主要还是对它不熟悉，加上-smp参数启动，10进程并发性能已经和C＋＋接近了。15进程时两者性能相当，50进程时C＋＋版本性能明显比erlang低得多，主要原因大概是C＋＋版本使用的是每连接一线程。由于目前这个上传服务器并发数比较高，所以erlang可能会比C++更适合。 这个话题能否深入探讨一下，为什么C++性能反而会低? Erlang 50 process? C++每个连接生成一个new thread? |
| 返回顶楼 | |
|
发表时间：2007-05-25
[quote="bigpanda"][quote="qiezi"] 主要还是对它不熟悉，加上-smp参数启动，10进程并发性能已经和C＋＋接近了。15进程时两者性能相当，50进程时C＋＋版本性能明显比erlang低得多，主要原因大概是C＋＋版本使用的是每连接一线程。由于目前这个上传服务器并发数比较高，所以erlang可能会比C++更适合。 [/quote] 这个话题能否深入探讨一下，为什么C++性能反而会低? Erlang 50 process? C++每个连接生成一个new thread?[/quote]
50进程指的是客户端同时50进程进行连接，这时C++用了50线程，erlang当然是50个process。 C++线程数多了效率下降得比较厉害，每连接一线程方式比较容易编写，也能很方便地处理一些超时。erlang在4CPU上用-smp启动，只会启动4个线程，这当然是最优化的方式了。通过优化减少线程数量，C++肯定能占上风，不过我总是会有不同的需求，erlang可以用统一的风格来处理，C++就不得不费尽脑汁去实现了，往往耗费苦心所写的代码性能高不了太多，代码量开发周期肯定就上去了。 对erlang感兴趣的另一个地方是热代码替换，目前有的应用需求总是在变化，服务器设计得可以长时间运转，却因为业务变化不得不重启服务器，用C++ + python/lua来实现？想想我要添加一种新的协议格式或者是调用一个新的外部接口，我用CPP + python要适应这种变化可能要把协议也交全python了，就因为不能重启服务器。最后C++剩得只剩下一点骨头架子，干脆全换成python。如果是这样，为何不开始就用erlang呢？erlang最大的阻碍是用的人太少，没有人会允许我在项目中用它，除非我是老板。。。 |
| 返回顶楼 | |
|
发表时间：2007-05-25
我不认为复杂网络应用程序的性能，在并发量比较大的时候C++还能占有优势
如果系统逻辑比较简单，例如连接到服务器的客户端互相之间关系不大的时候，那么可能C++网络会有优势。但是在复杂的网络应用程序中，网络处理的速度、逻辑的复杂性、同步处理都是影响到性能的重要原因。 采用异步方式处理网络IO的程序处理复杂逻辑就非常困难，不但难以调试和扩展，而且本身就会造成性能下降。从处理并发的角度来看，消息处理可以大大提高系统的并发能力。另外，在并行能力的可伸缩性方面，Erlang更具有得天独厚的优势。 |
| 返回顶楼 | |
|
发表时间：2007-05-25
复杂网络系统也不用我们再从头造轮子，ace,ice 都是不错的选择。
|
| 返回顶楼 | |
|
发表时间：2007-05-25
[quote="potian"]我不认为复杂网络应用程序的性能，在并发量比较大的时候C++还能占有优势 如果系统逻辑比较简单，例如连接到服务器的客户端互相之间关系不大的时候，那么可能C++网络会有优势。但是在复杂的网络应用程序中，网络处理的速度、逻辑的复杂性、同步处理都是影响到性能的重要原因。 采用异步方式处理网络IO的程序处理复杂逻辑就非常困难，不但难以调试和扩展，而且本身就会造成性能下降。从处理并发的角度来看，消息处理可以大大提高系统的并发能力。另外，在并行能力的可伸缩性方面，Erlang更具有得天独厚的优势。[/quote] 不赞同。 从处理 IO 的角度，直接调用操作系统核心提供的异步 API 是效率最高的方式（如果核心的实现不是太烂的话），做这个事情是 C/C++ 的专长。另一方面，数据 IO 和对数据的逻辑处理是可以解耦的，因此我不认为复杂的逻辑是个无法解决的问题。这个地方真正的问题是两个：一是工作量，要达到同样效果，C/C++ 的实现工作量会大不少；二是 C/C++ 的实现无法自然地扩展到集群上去。 |
| 返回顶楼 | |
|
发表时间：2007-05-26
解耦当然可以做到，但是解耦需要很多工作（就算在erlang之前，我也选择了每个job自己的一个队列这种方式，就算不是这种做法，你也需要另外一种解偶的方式）。
这中间必然涉及到队列的维护和数据的拷贝，或者类似于erlang的大数据引用等等，而一旦这样做，你就需要考虑引用的计数维护（或者拷贝的算法），队列的同步维护等等一系列问题，这本来就是Erlang的强项，当然，你可以针对某一个应用进行特殊的处理，但是一般我们都会偏向于逐步抽象，形成一定积累的内部框间，我很怀疑绝大多数人能够处理得比Erlang更好。 复杂的网络应用会有很多做法，例如我们的流媒体除了支持TCP方式的“组播”外，由于客户端经常需要轮巡，也就是支持同一个连接的视频源发生变化，用process和message来构造这个模型，非常轻易地就实现了，并且效率很高 |
| 返回顶楼 | |
|
发表时间：2007-05-26
我公司有个做了十年以上通信开发的工程师，现在正在使用ACE开发一个高性能的Proxy程序，使用单线程Event Driven的方式，对于逻辑相对简单，计算密集，特别是后端没有什么阻塞调用的应用，这样的模式是非常适合的。但是对于一些更为复杂的应用来说，特别是需要使用到多线程，这时候我个人更倾向于使用Erlang这种方案。
对于每个job自己的一个队列这种方式，我同事认为它存在线程切换开销以及锁的开销，调试也不方便。 |
| 返回顶楼 | |
