

Python to get Google-backed speedup - mv
http://techreport.com/discussions.x/16713

======
johnnybgoode
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.

~~~
briansmith
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.

~~~
johnnybgoode
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.

~~~
karanbhangui
That wasn't sarcasm; it was a rhetorical question to illustrate a point.

~~~
johnnybgoode
Thank you for adding so much to the discussion.

( _That_ was sarcasm.)

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

------
ghshephard
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
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.

~~~
stcredzero
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.

~~~
limmeau
I don't understand the "stack frames are exempt from GC" thing -- do you mean
the stack frames do not contribute reachability roots to the garbage
collection or that the stack frames themselves are not garbage-collected?

~~~
stcredzero
Nothing directly involved in the call participates in GC. In VisualWorks
Smalltalk, these calls are special. (These are only calls out through the
DLLCC facility. I believe they are marked by pragmas.) They might contribute
reachability roots, though that might be problematic. I seem to remember that
objects created in that stack frame are not garbage collected. Since these
methods are marked, the compiler can treat these calls specially. I'm pretty
sure that the objects are spawned in a different space. I think this would
mean that those stack frames can't mutate objects created before the call.
(This would make these calls functional in flavor.) They should be able to
refer to such objects, as this will only cause an exception if things go
wrong.

The only thing that happens in these methods in VisualWorks Smalltalk is
marshalling to call out to DLLs implemented in C.

------
sker
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.

~~~
johnnybgoode
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.

------
Locke1689
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
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.

------
blhack
_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...

~~~
llimllib
what do you hate about python regexes?

~~~
ghshephard
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.

~~~
llimllib
well, I don't disagree that there's a tradeoff there - the s/ and =~ syntaxes
are super neat, as opposed to the readable and consistent python style.

I can see that as a reason for _preferring_ perl's syntax, but I just don't
understand _hating_ python's regex, which is what my question was about.

------
kevbin
More LLVM can't be a bad thing.

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

------
scorpioxy
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.

------
epall
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?

------
Adlai
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.

~~~
FraaJad
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.

~~~
Adlai
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.

~~~
FraaJad
Let's say, your brain groks ruby better than python and you feel more
productive with it's "flexibility". No need to dismiss the hard work of python
developers over the last couple of years as "weaseled".

Maybe this "flexibility" you talk of is not all that cracked up to be for most
of the programmers. Python flourishes because it too is opinionated in it's
ways and a lot of people tend to agree with the set of choices made by the
language designer.

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

I __hate__ that

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

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

------
c00p3r
investing in "new visual basic"...

