Python to get Google-backed speedup

http://techreport.com/discussions.x/16713

by mv • 17 years ago

158 69 17 years ago

Locke1689• 17 years ago

This is truly very exciting, but the more I see of parallel language development, the more I want to focus on languages like Haskell, which have no side effects and therefore have some substantial implicit parallelization effect. Don't get me wrong, I love Python (and C) but I wouldn't be surprised if we were all using a Haskell derivative in 5 years instead.

pieceofpeace• 17 years ago

More and more languages are acquiring functional-programming features, so, may be we will see a hybrid of Python & Haskell.

  languages like Haskell, which have no side effects

Haskell does have side-effects. Most programs have side-effects. Functional languages like Haskell are designed to separate side-effects and pure functions. It gives the interpreter/compiler the ability to parallelize the pure function.

kevbin• 17 years ago

More LLVM can't be a bad thing.

ghshephard2• 17 years ago

My favorite line (buried a few hundred lines deep) --IN 2009 Q3 and Beyond:

"In addition, we intend to remove the GIL and fix the state of multithreading in Python."

thorax• 17 years ago

The GIL has really frustrated me for multiple years. When you're embedding Python into an application, it's really difficult to take advantage of the best multi-core options Python has because those options are all multi-process tricks.

At Pycon last year, when I reminded Guido about the difficulty for embedded apps (that can't fork 200MB processes every time a thread is needed), he shrugged and recommended Jython or IronPython usage.

It's great to see that we'll have this problem solved in a few years. (I assume it will take that long to be production-worthy.)

I'm sure this LLVM integration and change will pretty much break/invalidate all of the embedding API, but to me it'd be worth the rewrite.

stcredzero2• 17 years ago

I'd like to see an optimization involving threads and GC. Some Smalltalk VMs only spawn real threads when there is a system call involved. However, the stack frames involved in the calls are momentarily exempt from GC. This means that the GC never has to wait for threads to synchronize to proceed with operations. But the language gets all of the benefits of real threads.

silentbicycle• 17 years ago

Have you looked at Lua? It's pretty similar to Python (with a bit more Scheme influence), but is very deliberately designed for embedding. Also, all state is contained in the Lua_state pointer, so you can concurrently run several Lua VMs when it suits you to. You don't need to wait years for Python to work its concurrency issues out.

nc2• 17 years ago

Tbh what is really needed is optimized message passing ala the actor model. It is a leap forward and avoids a lot of problems that threads face (subtle concurrency bugs).

ralph• 17 years ago

You mean CSP-style, like Alef and Limbo from Bell Labs? Have you come across PyCSP? It has multiple backends, including greenlets which are nice and lightweight. http://code.google.com/p/pycsp/

fauigerzigerk2• 17 years ago

Yes it does avoid many problems, but it's unsuitable for other important scenarios. We need both. Message passing should be a design choice, not an excuse for a limitation in some language runtime.

bayareaguy• 17 years ago

For people who already know all about Python, LLVM, etc the http://code.google.com/p/unladen-swallow/wiki/ProjectPlan page is more informative.

blhack2• 17 years ago

On UNIX/Linux it is also viewed by many as a modern replacement for Perl

I still have a LOT of perl in use simply because of my hatred of python's regular expressions and I suspect that I'm not the only one...

llimllib4• 17 years ago

what do you hate about python regexes?

ghshephard2• 17 years ago

It's difficult to explain what it is, precisely, about python RegExes that make them awkward, and perhaps if I had never encountered the syntatic regex sugar that is perl, I would have never noticed. But, as a total python advocate and frequent writer of python scripts - I still find my brain hitting wait-states that don't occur in perl when I need to pattern match. I can live with that because of the 50+ things that make python so much better (for me) than Perl (Hash of Array / Array of Hash at the top of the list) - but it's sad that I still don't regex in Python as fluidly as perl.

I think the first hint that Python wasn't developed with RegEx users in mind would be that in the 700 Page "Learning Python, 3rd Edition" - Regular expressions aren't even mentioned in the Index.

blhack2• 17 years ago

It probably has a lot to do with my lack of programming knowledge (I've never taken any formal programming classes [err...I took java in college but never actually went to the scheduled class because it was a lot of covering what these cRaZy things called variables were])...

A replacement on python looks like this...

foo = re.compile("<") bar = foo.replace(">", bar)

this works, but it just feels less awkward to me than

$bar = s/</>/

DannoHung• 17 years ago

I dunno man, my way of thinking is that if you're not screen scraping, regexes shouldn't show up all that much and if they're not showing up that often, Python's way of doing it isn't so bad.

Not much of a condolence if you're screen scraping, but still.

johnnybgoode10• 17 years ago

This is a serious question. Can someone explain to me why higher-level languages like Python, Ruby, and JavaScript can't share a fast VM? It doesn't have to be the JVM or .NET, but why is everybody duplicating so much work? I know the Perl guys were moving in this direction, but nobody else seems to be onboard. Even within Google, they have v8 for JavaScript already.

llimllib4• 17 years ago

why ask this question on an article about python possibly moving to LLVM? Rubinius and MacRuby target LLVM as well, for example.

ori_b4• 17 years ago

LLVM isn't so much a VM for those languages to use directly as a portable assembly toolkit.

It's too low level to do compile to directly. It'd occupy a place in the stack somewhere near assembly, but with an optimizer in place. It's more of a VM toolkit than a VM itself.

briansmith2• 17 years ago

Why not just write a program that can convert any program written in one language to any of the others? It is basically the same problem and about the same level of difficulty.

johnnybgoode10• 17 years ago

Edit: Were you being sarcastic? I don't think it's exactly the same, because being able to compile many languages down to a single language is easier than also having to go in the other direction.

Original comment: Yeah, that would be one solution, but I think the shared VM helps so you can easily access libraries written in different languages. I remember why (of Ruby fame) trying to run Ruby code on Google App Engine back when it was Python-only. He discovered that Ruby bytecode is nearly identical to Python bytecode. Like me, he didn't understand why Python and Ruby still need to be on separate runtimes.

ori_b4• 17 years ago

How much of the source level semantics do you want to preserve? If you don't care about many of them then it's not too hard to do (although quite pointless). Just compile to an array of bytes, and a turing machine emulator or equivalent, in your target language of choice, and you've converted.

The hard part comes when you want to preserve source-level semantics and provide a natural-feeling translation so that a human can understand, read, and write the source.

However, with a VM you don't have that problem. With a VM, a lossy, one-way transform is sufficient. You can easily throw away information as you compile, since you're not targeting humans consumption for the output. You can replace, say, overloaded functions with mangled names. You can turn multiple dispatch into decision trees of conditional statements. And so on. With a VM, you would want to keep enough high-level detail to efficiently JIT stuff, and it's a bit of a challenge to decide what detail is sufficiently useful to include, but it's not insurmountable.

ori_b4• 17 years ago

Look up the "Parrot" VM. That seems to be their goal.

johnnybgoode10• 17 years ago

I know the Perl guys were moving in this direction, but nobody else seems to be onboard.

That's what I meant. As far as I know, nobody else is taking it seriously as a primary VM for their language.

kingsley_20• 17 years ago

Isnt that the JVM? don't know about fast though, but fast enough for me.

etal2• 17 years ago

It's usually one or more of:

1. Using a simple prototype VM seemed easier during initial development

2. When the language was developed, no suitable common VM existed

3. The language developers thought they could do it better for their specific case, i.e. the point of the implementation is to showcase new VM strategies

Remember that a language and an interpreter are separate things, and usually an author who wants to try an idea for one has to find some suitable stand-in for the other in order to get started.

johnnybgoode10• 17 years ago

Thanks. Your #1 and #2 seem to be very common.

It looks like we're at a point now where many dynamic languages are attempting to transition to a more advanced VM. This includes Perl, Python, Ruby, and some implementations of JavaScript. I assume they all want to take advantage of the latest VM techniques, and they're all making major changes anyway, so again I just wonder why they don't seriously consider collaborating now.

pronoiac2• 17 years ago

I've heard there was an attempt to pursue this a few years ago, but there were very serious fundamental incompatibilities, with examples given that went way over my head.

johnnybgoode10• 17 years ago

Interesting, do you remember anything else, like which languages were involved?

tlrobinson• 17 years ago

V8 goes down to machine code, not bytecode, btw.

sker• 17 years ago

I think the most important point here is not the speedup itself, but the fact that Google is officially backing Python. That'd give Big Corps confidence when adopting the technology.

johnnybgoode10• 17 years ago

I think hiring Guido and making Python one of the few allowed languages at Google already counts as officially backing the language. But yes, this does seem to be another step in that direction.

Adlai2• 17 years ago

I'm disappointed that Ruby isn't getting this type of attention. I think that Ruby strikes a good balance by allowing highly readable code like Python, but tolerating denser syntax for when you don't feel like talking to a 3-year-old.

However, it is good that Google is putting it's weight behind this project, because anybody who uses anything built on Python (which has weaseled its way into virtually everything nowadays) is going to experience a performance boost.

jjames• 17 years ago

I resent the suggestion that python has weaseled its way into anything. It rather slithers, wouldn't you say?

FraaJad2• 17 years ago

Weasled?

A programming language is what it's developers and users make of it. Python people have worked very very hard in the last 2 years to be ahead when everybody and their uncle were going ga-ga over Rails.

Adlai2• 17 years ago

I actually don't have that much experience with Rails. I prefer Ruby over Python because of its flexibility -- Ruby doesn't force you to approach problems in a specific way just because the language designer decided that was the only way to do it.

TweedHeads• 17 years ago

Python would be perfect if it wasn't for the underscores that plague its syntax.

I __hate__ that

cloudhead• 17 years ago

My dislike of underscores is part of what made me chose ruby over python, when moving from php.

euccastro2• 17 years ago

Underscores are there to mark 'magic' stuff. That's a good reason for the slight ugliness.

scorpioxy• 17 years ago

So once the port to LLVM is done, how would that compare to say something like Jython?

I always thought(not based on actual experience) that running Jython or IronPython would give you all the mentioned benefits.

yason• 17 years ago

I hope they would incorporate the Stackless Python branch into this one as well.

c00p3r• 17 years ago

investing in "new visual basic"...

epall• 17 years ago

Zope? The most popular web framework? Cool! I had no idea it was still in use that much. Can anybody shed light on who uses it these days?

Python to get Google-backed speedup

Related Stories