|
锁定老帖子 主题：YARV和JIT，还有JRuby……
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-03-06
最后修改：2009-03-06
seraphim871211 写道 RednaxelaFX 写道 seraphim871211 写道 没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊 最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL 呃……你在校内上不是说得火热嘛，这都不知道。 引用 seraphim871211 写道 最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的…… 唉，作业头疼啊 |
| 返回顶楼 | |
|
发表时间：2009-03-06
最后修改：2009-03-06
ray_linn 写道 RPC? 远程方法调用？ Remote Procedure Call?
嗯肯定是说这个没错。 night_stalker 写道 RednaxelaFX 写道 ...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
... segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界…… 关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。 不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T seraphim871211 写道 呃……你在校内上不是说得火热嘛，这都不知道。
于是我知道了……呜哇，突然觉得有点不好意思了（奔 RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL |
| 返回顶楼 | |
|
发表时间：2009-03-06
RednaxelaFX 写道 ray_linn 写道 RPC? 远程方法调用？ Remote Procedure Call?
嗯肯定是说这个没错。 night_stalker 写道 RednaxelaFX 写道 ...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
... segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界…… 关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。 不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T seraphim871211 写道 呃……你在校内上不是说得火热嘛，这都不知道。
于是我知道了……呜哇，突然觉得有点不好意思了（奔 RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL 丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。 你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。 |
| 返回顶楼 | |
|
发表时间：2009-03-07
seraphim871211 写道 丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。 嗯我知道你那个是分布式的作业，之前在校内看到了。这方面在我的盲区内，没办法了（摊手 精华不精华不重要啦。倒是能召唤到些VM有爱人士就好了 T T |
| 返回顶楼 | |
|
发表时间：2009-03-07
我用2008优化编译的1.9在跑某个脚本需要的时间是1.87的两倍，没仔细去找原因了。
|
| 返回顶楼 | |
|
发表时间：2009-03-07
>g:\ruby187\bin\ruby dzhreader.rb
>Exit code: 0 Time: 19.469 这是我编译的1.87(vc2008) 1.9运行结果：45秒(vc2008) >ruby dzhreader.rb >Exit code: 0 Time: 26.467 官方自带 vc2008加上一些优化选项的确能使性能有所提高，但1.9的速度感到很困惑。 |
| 返回顶楼 | |
|
发表时间：2009-03-07
有快有慢，视情况而定。
ruby酱网站给过一系列的benchmark，总体来说是快了的。 当然benchmark不可信，但是一两个脚本的特例就更不可信了。 |
| 返回顶楼 | |
|
发表时间：2009-03-09
这个看你怎么抠概念了。
比如charles nutter一直说的jruby的'JIT',就完全不符合你说的JIT概念。jruby是混合模式，有些代码是自己直接解释AST,有些是编译成java字节码交给jvm。他所指的jit其实就是运行时编译的部分。 ruby的1.8及之前的实现，确实很业余。这点matz也承认。同样做个loop的话，ruby比其他语言慢几十上百倍。1.9改进了解释器的实现。在benchmark上轻松的上了个大台阶。 但是诸如rails这样的应用，loop快上几十倍就没大关系了，也就是几毫秒和几十毫秒的区别。同时，你的页面里也许有几个sql query,瓶颈大多在其他方面上了。我猜这是rails在1.9上目前没有大的提高的原因吧。 我也试过在jruby上跑过rails程序，和robbin说的一样，挺慢的，而且巨占资源。 |
| 返回顶楼 | |
|
发表时间：2009-03-09
没错，Charles Nutter说的“JRuby的JIT”指的是JRuby将Ruby源码编译到JVM字节码的过程，与我所说的JIT不相符。但同时JVM字节码是有机会被JVM所JIT的。所以在JRuby做了JIT、JVM也做了JIT之后，整个过程就符合我所说的JIT了。所以说很微妙。
IronRuby方面比JRuby……或许没那么微妙。现在的IronRuby如果是在默认模式，会一口气把Ruby源码都解析为Expression Tree。然后DLR会将Expression Tree编译为MSIL。接着CLR会将MSIL给JIT成本地机器指令。整个过程没任何可选部分，整体上看就等同于把Ruby源码JIT到了本地机器指令才执行。 IronRuby的以后肯定也会实现混合模式的运行方式，虽然现在还没有。DLR有默认的解释模式，这种模式下Expression Tree只用于解释而不编译到MSIL。相对来说自适应性就没了。 JRuby默认用的是混合模式的运行方式，在刚启动时采用纯解释模式，在达到一些条件之后对部分热点做“JRuby的JIT”。之所以是“部分热点”是因为多了会塞爆PermGen；JRuby得对每个“JIT”出来的类用单独的class loader来加载，以保证在达到内存使用上限时能卸载掉一些老的“JIT”出来的类。 JRuby对Ruby核心库是有特别实现的：核心库的功能是用Java实现的，运行时创建许多小的包装类来实现快速调用，这样可以用相对具体的signature来从Ruby调用底下的Java方法。用比较具体的signature可以减少通用signature中varargs数组的包装，减轻GC的负担。对一般的Java库，JRuby还是用普通的反射来做调用的。 JRuby巨占资源这点恐怕比较难改善。以后invokedynamic正式合并到JVM spec里的话可以减少对包装类的需求，那样是可以减少一些资源占用。不过JVM本身就不是省油的灯就是了，呃呵呵。 不知道Sun的Kenai后面是用怎样的机器撑着的呢？有人有了解么？用JRuby on Rails来做hosting还真是一强悍的广告…… |
| 返回顶楼 | |
|
发表时间：2009-03-09
还是维特根斯坦他老人家说得好：
问题无解，原因往往就是问题定义有问题，或者人类智能无法理解此概念。(大意..) JIT就是个暧昧的概念，"Ruby是不是JIT了"就是个有问题的问题。 |
| 返回顶楼 | |
