6 ms·
Python to get Google-backed speedup
- Locke1689 17y agoThis 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 17y agoMore 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.
- deleted 17y ago[deleted]
- kevbin 17y agoMore LLVM can't be a bad thing.
- ghshephard 17y agoMy 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 17y agoThe 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 17y agoI'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 17y agoI 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 17y agoNothing 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.
- silentbicycle 17y agoHave 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.
- nc 17y agoTbh 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 17y agoYou 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/ http://code.google.com/p/pycsp/
- euccastro 17y agoStackless is inspired in that paradigm too.
- fauigerzigerk 17y agoYes 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.
- nc 17y agoThat's interesting, which scenarios do you consider it unsuitable for?
- fauigerzigerk 17y agoThe scenario I deal with most of the time is a large, read-mostly, in memory custom data structure that is accessed by multiple clients. More and more data fits into memory nowadays so that's going to be a very common scenario for many data analysis tasks in the future.
- bayareaguy 17y agoFor people who already know all about Python, LLVM, etc the http://code.google.com/p/unladen-swallow/wiki/ProjectPlan http://code.google.com/p/unladen-swallow/wiki/ProjectPlan page is more informative.
- blhack 17y agoOn 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 17y agowhat do you hate about python regexes?
- ghshephard 17y agoIt'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 17y agowell, 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.
- deleted 17y ago[deleted]
- blhack 17y agoIt 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/</>/
- johnnybgoode 17y agoThis 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.
- llimllib 17y agowhy ask this question on an article about python possibly moving to LLVM? Rubinius and MacRuby target LLVM as well, for example.
- ori_b 17y agoLLVM 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.
- briansmith 17y agoWhy 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 17y agoEdit: 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.
- sker 17y agoI 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 17y agoI 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.
- Adlai 17y agoI'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 17y agoI resent the suggestion that python has weaseled its way into anything. It rather slithers, wouldn't you say?
- FraaJad 17y agoWeasled? 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 17y agoI 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 17y agoLet'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 17y agoPython would be perfect if it wasn't for the underscores that plague its syntax. I __hate__ that
- scorpioxy 17y agoSo 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 17y agoI hope they would incorporate the Stackless Python branch into this one as well.
- c00p3r 17y agoinvesting in "new visual basic"...
- epall 17y agoZope? 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?