Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Python-to-C++ Compiler 181

Mark Dufour writes "Shed Skin is an experimental Python-to-C++ compiler. It accepts pure, but implicitly statically typed, Python programs, and generates optimized C++ code. This means that, in combination with a C++ compiler, it allows for translation of pure Python programs into highly efficient machine language. For a set of 16 non-trivial test programs, measurements show a typical speedup of 2-40 over Psyco, about 12 on average, and 2-220 over CPython, about 45 on average. Shed Skin also outputs annotated source code."
This discussion has been archived. No new comments can be posted.

Python-to-C++ Compiler

Comments Filter:
  • Very nice, but... (Score:1, Interesting)

    by MikTheUser ( 761482 ) on Thursday June 15, 2006 @01:28PM (#15541404)
    Since Python is about the only language I know very well, I find this fascinating. But it also reminds me of the .NET development suite, where the way you write your code in any language doesn't matter, since it all become one machine code. So if you think you can do something more memory efficient in C# than in VB.NET - well, no.
    So the bottom line is, the quality will depend on the quality of the converter, and that's not so cool. Adding layers between code and machine code is not the best way IMHO.
  • Re:Static Typing? (Score:3, Interesting)

    by Surt ( 22457 ) on Thursday June 15, 2006 @01:40PM (#15541548) Homepage Journal
    Well, it's not quite as bad as it sounds. He's seemingly only really forbidding incompatible mixed types in the same variable, a usage that isn't exactly extremely common.

    A more significant roadblock, IMO, is that he can't handle mixed types in 3+-tuples, which is very common.
  • by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Thursday June 15, 2006 @01:44PM (#15541594) Homepage
    > However, as a python programmer myself, it's not yet in a usable form

    Yup. Along the same lines, Ruby has a related project by Ryan Davis, Ruby2C [rubyforge.org]. It's useful for small localized speedups, but you wouldn't want to try to write your entire app in it.
  • I'm confused... (Score:5, Interesting)

    by advocate_one ( 662832 ) on Thursday June 15, 2006 @02:02PM (#15541823)
    surely the best way to speed it up is to compile it straight to object code... c++ has to be compiled and just adds an intermediate step which will make things harder to debug...
  • by zhiwenchong ( 155773 ) on Thursday June 15, 2006 @02:05PM (#15541863)
    It's all a matter of magnitude.

    I use Psyco in my work. My app is a code generator that processes multiple models and transforms them into optimization code. Psyco reduced the time it took for process 1 model from 20 seconds to 2 seconds. It doesn't sound like much, but when you have to do it for lots of models, the speedup suddenly becomes quite substantial.
  • by b17bmbr ( 608864 ) on Thursday June 15, 2006 @02:12PM (#15541942)
    After four hours of tweaking, our expert C++ programmer was finally able to write something that beat our ten lines of Python code that took under five minutes to write. And it didn't beat it by much, whereas the first pass at a C++ version was an order of magnitude slower.

    Which is why languages like python were written in the first place. They pretty much just make the underlying C calls anyways, but do so in a way that handles buffer overflows, pointers, etc., that pretty much make C/C++ so troublesome, hazardous, and hard to learn. I like java (alot really), but nothing beats a good scirpting language, like perl or python, to handle tasks like text manipulation. Python is especially good at using libraries, such as the imaging library, which are written in C anyways. How much faster can you get calling a C library from C than from python? I honestly don't know, but I can't imagine it's that much more. But when you add in speed of development, safety, and even portability, it's powerful.

    Python's OOP is also a feature that makes it far more attractive than perl for me. Perl does OOP, but it's not as clean as python's, and I don't think it supports all the OOP features either. Doing GUI's is not the strength of any scripting language, but it depends on what you need to do. You can write a native frontend and embed python into a C or even a java application.
  • Re:Static Typing? (Score:4, Interesting)

    by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Thursday June 15, 2006 @02:40PM (#15542240) Homepage

    I love Python, but I hate the dynamic typing. It can be handy at times, but 99% of the time you make a variable to hold one kind of thing. Having the static typing would both improve performance (because the interpreter knew what you were up to) but would also eliminate bugs (because it would complain when I tried to set a double to "And now press...").

    I'd love to see Python get optional static typing.

  • by joss ( 1346 ) on Thursday June 15, 2006 @02:52PM (#15542351) Homepage
    Sorry, but without more details it would seem to me that
    your "expert" C++ guy wasn't an expert. Can you describe the
    problem a little better.. if what you say is true, I as
    a long term C++ programmer would consider switching, but
    I've looked at python, and I simply don't believe you.

    I'll grant that C++ is a nightmare for beginners with more pitfalls
    than an indiana jones movie, but once you know them, writing
    poorly performing code is unlikely.
  • Re:I'm confused... (Score:3, Interesting)

    by Dasher42 ( 514179 ) on Thursday June 15, 2006 @04:41PM (#15543393)
    I think that the best example of what you're saying would be the Java compiler in the gcc suite. That separate front-end, back-end approach of gcc is terribly helpful.

    And yet, if you're going to compile Python, I'd want the translation into source code. If it's worth rewriting in C++, it's worth tuning, especially if you can improve the usage of type-safe code.
  • by radtea ( 464814 ) on Thursday June 15, 2006 @05:00PM (#15543569)

    Python is a terrific prototyping language (and lots of other things besides.) As a C++ coder I've been using it for prototyping stuff that will eventually be integrated into a larger application and therefore MUST be translated to C++. So what I'd like to see is a tool (written in Perl, just for the fun of having a linguistic threesome) that just does a light gloss on Python syntax to get me most of the way to human-readable C++. That would be far more useful (to me) than thsi thing, which sounds more like f2c, whose output could case brain damage in humans and cancer in rats, or possibly the other way around.
  • Re:wrong comparison (Score:3, Interesting)

    by stonecypher ( 118140 ) <stonecypher@noSpam.gmail.com> on Monday June 19, 2006 @12:52PM (#15562414) Homepage Journal
    Oh, hell.

    That'll teach me to hit submit without checking the preview. I lost a big and important chunk of the reply after operator< because I forgot to write out the entity for <. Here's a repaste; yay form buffers, boo no edit button for the first five minutes of a post.

    -----------------

    That's the wrong comparison to make, because it assumes that the C++ programmer has unlimited time to make his C++ code efficient and correct.

    Well, yes and no. I actually got into this else-thread; there are a hell of a lot of programming jobs where the programmer actually does have time to make their code correct. Not everything behaves like the web; when you're writing a video game, an operating system, a database, embedded or realtime control software, or in fact many many other things, performance just isn't sacrificable.

    (And, actually, in most situations, a programmer has all the time in the world to make their software correct; the number of software houses which will willingly release software containing flaws is vanishingly small. Most released flaws are the result of bad development practice and insufficient testing methods, not short schedules.)

    In real life, programmers have time constraints, and under given time constraints, the Python program will often be faster than the C++ program.

    Yeah. If you'd take a look at the numbers, though, the vast bulk of software is actually embedded software. Embedded software can't tolerate execution delays. Behind embedded software, the next largest group is in-house software; that kind of software generally can't tolerate production delays. Those two groups are a wonderful example of the extreme divergence in needs in development - python is exactly the right thing to do for the second group, but exactly the wrong thing to do for the first.

    As far as the Python program often being faster than the C++ program, that sounds an awful lot like an expectation, rather than experience.

    In fact, even without time constraints, C++ code often ends up far less efficient than the optimum possible, simply because using the optimal algorithm or memory management strategy is so hard in C++ that programmers can't do it.

    Yeah. Now it's time for me to call bullshit. This is such a weirdly interesting myth, that algorithms and memory management in C++ are harder than they are in other languages, that I don't really know what to say.

    See, implementing algorithms and memory management in C was really, really hard - you had to, well, keep track of a pointer and an offset. (Because most people confuse the overflows that come from bad engineering practices with something that's just magically too hard to do, presumably because they've never seen anything harder, and they can't imagine a world wherein garbage collection and pointers aren't the alpha and omega of memory management. Wait'll you try COBOL, FORTRAN or machine assembly, all of which are still common languages - in fact, all moreso, if you count all assembly languages as one, than python.)

    That said, in C++ it's nowhere near that difficult. If you want garbage collection and can't be bothered to write new in the constructor and delete in the destructor, bust out a smart pointer. Get a container; it'll self allocate just fine, and ridiculously efficiently. Need something more complex, like pooling? No problem - pooling is two lines of code in operator new, or you could just use the policy class in Boost. Algorithms are in fact so fundamental to the design of C++ that there's a specific section on them in the standard, defining how they are to be implemented such that they magically and correctly attach to any correct container. They are trivially easy to implement; a naive bubble sort which is correct can be implemented in a single line of code, in a way that will work for any user defined type implementing operator< and on any ordered container.

    Exactly what memory management

"If I do not want others to quote me, I do not speak." -- Phil Wayne

Working...