From: "M. Edward (Ed) Borasky" Date: 2006-11-27T23:31:06+09:00 Subject: Re: Two Advanced Ruby Performance Questions Sunny Hirai wrote: > To M. Edward > > Thanks for the info. In terms of VM, basically I'm looking for something > that is significantly faster than Ruby is right now. Ultimately it would > have been nice to start clean on Ruby 2.0 semantics and its upcoming VM > but I don't have much confidence on timelines here, especially to a > stable build. I'd prefer jRuby because it would allow us to hook into > Java easier which a lot of reference implementations for integration are > done in; however, I'm worried about difference between it and the > reference implementation. > From what I've seen posted on the list, plus my own profiling of the Ruby interpreter, there's probably at least a 30 percent performance improvement easily available in the current interpreter. And I think jRuby will be better than that on the average because it jas the JIT compiler and knows a lot (or can be taught a lot) about the x86-64 architecture. I *hope* you're using the x86-architecture. :) From what I heard in Denver at RubyConf 2006, there is little risk of jRuby diverging in syntax and semantics from the current Ruby 1.8.5. > I do have to disagree a little with your "one last comment" however. I > find it necessary to learn everything I need to know about a language to > scale. I find it uncomfortable when I don't know what is happening under > the hood because things can take me by surprise. > [snip] > I like knowing this type of stuff so I know what happened when things go > wrong and to prevent it from happening in the first place. > Now *you're* preaching to the choir. :) I do that sort of thing (performance engineering) for a living (on the Linux platform). though. > Thanks also for the information on Mongrel. This project sounds > interesting. I am disappointed to learn that Rails is not thread safe. I > am still hoping that ActiveRecord will work well in a multi-threaded > environment however. The approach of multiple instances of mongrel and > multiple ruby interpreters is a good workaround. That said, I think I'd > have to rewrite ActiveRecord anyways as it relies on config files to set > datasources and such. Our application will probably need to set > datasources at run time so that we can split a table across multiple db > servers and let it know, at run-time, which server the data resides on. > You definitely should spend some time with Zed Shaw (Mongrel's inventor). He's done some things that most of us thought were impossible in pure Ruby. And he's -- well -- "zealous" about performance and scalability. :) -- M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P) http://borasky-research.blogspot.com/ If God had meant for carrots to be eaten cooked, He would have given rabbits fire.