|
锁定老贴子 主题：ErLang语法提要
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
时间：2007-05-31
Erlang的Process类似于Active Object.很多内部的基础设施,写出来还是会像OO行为.
不过Erlang 某些idiom的确很有趣.比如说你可以把OO中的对象本身当作消息，在Process之间传来传去.也就是消息本身可以带状态，带方法,类似于一种Agent.这些Agent在不同的Process游走，然后不同的Process根据需要可以任意的装配你需要的功能. |
| 返回顶楼 | |
|
时间：2007-06-10
cookoo 写道 dcaoyuan 写道 是这意思。我的开源证券分析软件是百分百Java，包括实时指标运算和图形不比一些C++/Delphi的商业软件慢。里面随时产生很多很多的小对象，比如Ticks和Path2D，有些可以不管，有些我用了对象缓存。据说Java现在的垃圾回收性能甚至好过对象缓存了，不过我现在懒得去试了。 Joel前段作了一些实际交易，效果似乎不太理想，他在交易策略方面看来还是个新手，用的是传统技术分析的方法。俺现在用的是神经网络和支持向量机，对计算性能要求挺高的，Java基本上能满足我的需求，当然，现在的算法，即使用C也同样不可能再上个档次，看今后几百个核的CPU能否帮我，当然，那时我就要好把Erlang和Java比一比了。 这方面我还真有些发言权哟。 并行计算不是Erlang所长，除非计算密集部分用C写。 个股预测技术多如牛毛，大部分都是80年代流行的技术，预测命中率都差强人意，相对于宏观经济趋势来说个股趋势的预测要困难得多。现在的对冲基金都倾向于预测或创造未来驱动价格的特定事件，或者利用衍生工具及时捕捉细小的市场机会而不管未来趋势如何。对个人投资者来说可行交易理念+portfolio的构造和调整才是关键所在。 实际上有些算法从根本上来说是无法并行计算的。好在对于交易系统，我们可以对不同的策略用不同的进程来计算，这样象Erlang这种可以充分利用多核CPU的语言就可以弥补计算性能的不足。比如神经网络集群或者神经网络＋遗传算法，蚁群算法等这些先天可以并行并相互通信的算法，Erlang也许特别适合。等我手头的项目差不多，我会做一些测试，比较Java, Erlang在多核的情况下性能提升的情况，第一个例子可能会是神经网络集群， 对于交易系统中算法、神经网络的应用，我当然不会去走别人已经走过的不通的路，工具还是那个工具，但对市场本质的认识决定了使用工具的效果。 |
| 返回顶楼 | |
|
时间：2007-07-27
引用 大写字母开头的名字（比如Address），表示一个变量，包括参数、局部变量等；小写字母开头的单词（比如ok），表示一个常量，叫做atom（原子的意思），包括常量名、函数名、模块名等。 怎么这么反常呢？呵呵 |
| 返回顶楼 | |
|
时间：2007-08-01
Trustno1 写道 hyf 写道 GC是不是真的能像你说的那么强，我没有数据仅仅是猜测，如果是使用c++，小型值对象一般都在栈中不会有分配和释放。
多次看到这里有人说JIT的优化能力能针对特定的CPU，甚至产生比C++更高效的二进制码。 想请教，他的优化能去到什么程度，能识别出你的程序逻辑并产生对应的SSE指令来？ 第一有GC的语言也是可以在栈中优化小值对象，比如Java的基本数据类型，做的更强的比如D,这只是语言实现上的区别，并不涉及到JIT. 第二,JIT优化与GC也没有关系. 第三,现代的JIT能比静态compiler产生更高效的代码主要集中于Polymorphic Inline Caches和type feed back两个方面.这两个技术能在语言运行时做runtime profiling.数据收集够了后，虚拟机就可以把最常用的函数调用内联到系统里，把常用函数的调用翻译成一个JMP, 跳到最有可能的函数实现那里，然后再来一个CMP，看是不是跳对了地方。只有当CMP失败的时候，系统才执行通常的动态分配.也就是说,在这两个技术面前,C++大老门在<Inside the C++ Object Model>里面绞尽脑汁鼓的各种vtalbe palcement & optimization,inline optimization技巧实际都变成了鸡肋.不过这两个技术还真称不上现代link里面的paper都是91,94年的老文,只是有赖于工业界这几年对JIT大量的投入他们的理论才逐步实现，到目前为止我看到的数据是java的method call Overhead要比c++快10倍左右. http://kano.net/javabench/data C++中的inline连JMP和CMP都没有了，直接把代码在本地展开，难道不会更快吗？ 而且Profiling本身也要消耗性能。 上面链接的文章中有链接文章说上述的比较结果完全是应为该C++程序本身没有优化。 http://bruscy.multicon.pl/pages/przemek/java_not_really_faster_than_cpp.html 在该文作者手工优化后，C++在所有测试中胜出。 |
| 返回顶楼 | |
|
时间：2007-08-01
netpcc 写道 C++中的inline连JMP和CMP都没有了，直接把代码在本地展开，难道不会更快吗？ 而且Profiling本身也要消耗性能。 上面链接的文章中有链接文章说上述的比较结果完全是应为该C++程序本身没有优化。 http://bruscy.multicon.pl/pages/przemek/java_not_really_faster_than_cpp.html 在该文作者手工优化后，C++在所有测试中胜出。 methcall.cpp OK. So what this test actually does is it calls two methods 1 000 000 000 times each. Java uses references to access objects, so I've changed C++ code to use references too. 用.的时候，实际上不是虚函数调用，没有运行时查找编译完之后就定址了.inline优化永远是编译期的,virtual 函数是无法inline优化.而Java的可以virtual method call 优化成 inline call,这一点C++ compiler永远做不了.也就是说除非你永远不用->,否则virutal函数肯定比java慢. I also inverted the loop direction, since comparison against 0 is faster - normally I would leave it as it was, but since this was the only benchmark in which Java Server came close to C++, I had to do something ;-) . Oh, and inverting the loop direction has no effect whatsoever on Java, so I left the code as it was. If you look at the results, you will notice that only the poor Java Client VM actually tried to invoke the methods - both Java Server and GCC inlined the methods, which resulted in a much better performance. 这段的意思是说即便你人肉优化了所有的->操作符,速度也就是和人家的VM优化差不多.有啥意义呢? |
| 返回顶楼 | |
