From: Roger Pack Date: 2007-11-11T15:04:37+09:00 Subject: Re: enterprise ruby Charles Oliver Nutter wrote: > Lionel Bouton wrote: >> Robert Klemme wrote the following on 09.11.2007 22:05 : >>> Personally, if I had the resources to invest into this I'd rather >>> spend them on JRuby. You get a GC with many tweaking options etc. >>> plus native threads. Does the jruby GC need much help? I was under the assumption it was 'good nuf' or something. > I think MRI is mostly a dead end at this point, unlikely to see any > major perf/scaling improvements anymore. If you're going to focus a lot > of time on tweaking and improving an implementation, I'd recommend > helping out one of the really active 1.8-compatible implementations > (JRuby being the most complete and furthest along) or a 1.9 > implementation (YARV being most complete and furthest along...but we > have some 1.9 features in JRuby too). I assume by your comments you mean 'work on the 1.9 MRI or on jruby' True. Matz has specified that he isn't looking to integrate drastic changes into the 1.8.6 trunk anytime (like changes to the GC)--to keep it stable. Bug fixes, sure, but other things, no. So why, then, you ask, would people waste time trying to optimize it? I guess I figured that the 1.9 code (like for the GC) was about the same so that patches to 1.8.6 that were useful would be good fodder for 1.9. I think this is the case, too, as Matz mentioned being interested in benchmarks for any tweaked GC's in 1.9 (i.e. 'go ahead and tweak away--it will get implemented then'). I could be wrong about the usefulness of working on 1.8.6, though. Hmm. I think I'm just afraid of working on 1.9 since bugs seem to still be rolling in. I like stability in others code so that if it exists--it's my own fault so I know where to fix it :) Now to find the time to write a real GC ... :) (i.e. re-write every useful extension that has a gc_mark function...sigh). My latest thought would be to rewrite the object allocater to use *just* malloc/free and see if it is faster. In my heart of hearts I almost think it could be :) Sometimes we optimize ourselves to death. void * new_obj(){ return malloc(sizeof(RANY)); } void * recycle(void *obj) { free(obj)); } :) Oh wait, traversing the stack and looking for heap pointers is problematic with my solution. Maybe I could overcome it by making the size of a ruby object += 4, and putting the chars 'rbrx' at its front so I know if it's a ruby heap objects--and hoping few people use that for strings or something. :) Oh wait that would introduce more bugs. One more shot down. Have a good night! -Roger -- Posted via http://www.ruby-forum.com/.