| |||||||||||||
garbage-collecting VMsgarbage-collecting VMsPosted Feb 27, 2007 4:19 UTC (Tue) by BrucePerens (guest, #2510)In reply to: garbage-collecting VMs by ncm Parent article: Ruby Performance (Linux Journal) There is lots of room for tuning allocation and object storage, and thus I'm not quite so willing to give up. And the interpreter's pretty good now. I've a few Rails applications in production, and I wish I had as much load as they can service with only one dispatcher. Bruce
(Log in to post comments)
garbage-collecting VMs Posted Feb 27, 2007 4:53 UTC (Tue) by ncm (subscriber, #165) [Link] I'm optimistic for a different reason: there's no need to run one's Ruby programs on a GC VM. If they turn out slow under real loads it will be easy to tell and easy to switch. It will only be unfortunate on shared servers where it may be hard to convince some users that they're unfairly hammering the rest because their CPU usage looks minimal as they thrash the bus.
garbage-collecting VMs Posted Feb 27, 2007 5:42 UTC (Tue) by BrucePerens (guest, #2510) [Link] I wasn't aware of any non-GC environments for Ruby. There are node-traversal interpreters rather than VMs, but they still GC. And I'm curious about what you think would be better. I sometimes prefer reference counting as with smart pointers in C++, and double-indirect schemes that work with compacting collectors, but the cache performance of such things is worse than GC on average. GC is only worse when the collector is running.Thanks Bruce
|
|||||||||||||