| |||||||||||||
garbage-collecting VMsgarbage-collecting VMsPosted Feb 27, 2007 9:04 UTC (Tue) by flewellyn (subscriber, #5047)In reply to: garbage-collecting VMs by ncm Parent article: Ruby Performance (Linux Journal)
We can expect implementations based on garbage-collecting VMs to do badly where locality matters. That's not necessarily true. It's going to depend on the type of GC. A good compacting or copying collector, an ephemeral collector, and other strategies can help enormously with locality issues, especially with long-lived objects (and with a copying or ephemeral collector, short-lived objects don't matter anyway). Collectors can be tuned to improve locality over hand-allocated memory, in fact. So let's not be spreading old misconceptions about GC now, okay? It's the 21st century, we've had the technique for fifty years, and it's been well proven by now. :-)
(Log in to post comments)
garbage-collecting VMs Posted Feb 27, 2007 19:29 UTC (Tue) by ncm (subscriber, #165) [Link] People have been saying that for decades. Somehow, fifty years down the road, programs that depend on GC and address real-world problems still exhibit abysmal memory-usage patterns, and often abysmal performance, despite stellar benchmark numbers. "Strategies that can help" evidently do not help enough, or are hard enough to apply that they aren't. GC programs have always made bad neighbors, and there is no evidence of progress there. Meanwhile, the machines are not getting faster any more, and are ever more dependent on good cache behavior.
How many more decades will it be before it's OK to say that the GC experiment has failed?
garbage-collecting VMs Posted Feb 27, 2007 20:29 UTC (Tue) by flewellyn (subscriber, #5047) [Link] Actually, people have been saying "Eww, GC = slow" for decades, despite huge amounts of research and development into making GCs faster and more robust.
I will freely admit that there's probably workloads in which GC can cause problems, but let's not be relegating the whole concept to the bit bucket just because it doesn't work in all cases.
Perhaps what we really need is some kind of "happy medium" system, in which a programmer COULD manage memory manually if necessary, but can otherwise leave it up to a GC. I'm not sure what such a system would look like, but it would be interesting to see.
garbage-collecting VMs Posted Feb 28, 2007 1:38 UTC (Wed) by drag (subscriber, #31333) [Link] Maybe something like Pyrex?
As you probably know python is a slow language. However it is used in lots of places that demand very high performance from programs.
How you deal with this, as I am told, is that you write the program you want to do in python. Use it and profile it. If it doesn't give acceptable performance then find the portiosn of the code that are slow and them figure out optimizations for it.
If you optimize as much as you can in python and it's still slow then you take your now-highly optimized python code and translate it to a C which you then compile and import into your python program as a module.
The key to making it all work is to write the program using generic code and _then_ identify bottlenecks (instead of speculating ahead of time), then refactor the code until it's no longer possible to get better performance _then_ rewrite it in a lower level language. That way you end up with a working program first (abiet slow) and then spend your time as wisely as possible to make it fast after some more realworld-ish experiance and testing.
Thats the theory anyways. How well it works out is my guess.
Well one of the major downsides to this approach is that although writing Python programs is easy, writing python extensions in C is not.
It requires a significant portion of boiler plate code and can be tricky to make things 'python-ish'.
So that is why Pyrex is invented. You can take straight python code (with some caveats), compile it with pyrex and get compiled python. Not realy that much faster, but the key is that you can then mix and match C code with python code... Allow them to intermingle in that python module your making freely and without all the boilerplate cruft.
Often times you can end up with superior results then trying to write in pure C or import a C/C++ library using bindings and such.
The some it up as: "Pyrex is Python with C data types."
garbage-collecting VMs Posted Feb 28, 2007 2:29 UTC (Wed) by flewellyn (subscriber, #5047) [Link] Well, that's kind of a separate issue from memory management, though.
You can use a GC with a compiled language: Lisps have had it for years, and have been compiled
Thanks for the tip, though. I do write a fair amount of Python code.
garbage-collecting VMs Posted Feb 28, 2007 4:27 UTC (Wed) by drag (subscriber, #31333) [Link] I wasn't realy thinking about compiled vs interpreted.
But I figured it you wrote in something like pyrex you could use C-like code to do memory management manually and then use python-like when you don't feel like it.
garbage-collecting VMs Posted Feb 28, 2007 5:31 UTC (Wed) by jdell (guest, #25923) [Link] You can do the same thing in Ruby with RubyInline. Very elegant:http://www.zenspider.com/ZSS/Products/RubyInline/
garbage-collecting VMs Posted Feb 28, 2007 6:11 UTC (Wed) by drag (subscriber, #31333) [Link] ya there is a pyinline also, if your curious.http://pyinline.sourceforge.net/
On that pyrex page I linked to they mentioned it. They say that it's nice, but it only converts basic types and you can't use it to make new python types. Maybe RubyInline is better.
Both of them are based off of the Perl inline concept, of course.
garbage-collecting VMs Posted Feb 28, 2007 18:24 UTC (Wed) by jdell (guest, #25923) [Link] Yes, you are absolutely correct. It seems to me that WRT to Python and Ruby, if it is interesting and worth doing, it has already been done in Perl :-)
RubyInline only auto-converts basic types - From their webpage: Automatic conversion between ruby and C basic types: char, unsigned, unsigned int, char *, int, long, unsigned long
garbage-collecting VMs Posted Feb 28, 2007 7:53 UTC (Wed) by ldo (subscriber, #40946) [Link] Actually, people have been saying "Eww, GC = slow" for decades, despite huge amounts of research and development into making GCs faster and more robust. The problem is, even while the software continues to improve the locality of reference of garbage collectors, the hardware continues to increase the cost of violating locality of reference. CPU speeds continue to increase much faster than RAM speeds. Which is why you have L1 and L2 caches (and sometimes even L3 ones) to bridge the gap. As the gap widens, so does the cost of crossing it. It's been about half a century since the concepts of machine-independent languages and garbage collection were invented; the first one is pretty much universally taken for granted these days, the second one is not. This even though processor speeds have improved by something like five orders of magnitude over that time; everybody now accepts that you should write your code in machine-independent languages (even for something as machine-dependent as the Linux kernel!), but garbage collection is still too expensive for many uses, and will probably remain that way forever.
|
|||||||||||||