| |||||||||||||
garbage-collecting VMsgarbage-collecting VMsPosted Feb 28, 2007 1:38 UTC (Wed) by drag (subscriber, #31333)In reply to: garbage-collecting VMs by flewellyn Parent article: Ruby Performance (Linux Journal)
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."
(Log in to post comments)
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
|
|||||||||||||