Unladen Swallow can now compile all Python code to native code using LLVM(code.google.com)
code.google.com
Unladen Swallow can now compile all Python code to native code using LLVM
http://code.google.com/p/unladen-swallow/wiki/Release2009Q2
6 comments
This is secondhand information, but apparently at the PyCon VM Summit this year the Unladen Swallow guys mentioned that they were already faster than Psyco for Youtube's workload.
Tismer is working on a new version of psyco; so I'll be interested to see how that comes out. That being said, psyco is only good for certain workloads (math heavy, for example). Unladen's goals are more "real workload" oriented, so don't expect targeted math speedups.
I Love Python and would use it more if it were easier to build stand-alone, compiled native apps from it (I used Python many years before the phrase 'Web 2.0' came about). I use pyinstaller right now and have use py2exe in the past to build native, end-client distributal code, but now I just use C++ for those cases.
Unfortunately I don't know how much this will help. I think LLVM will add like 7mb to any python exe distribution.
7mb doesn't seem too bad in this age of fast net and big hard drives as compared to the inconvenience of what other method you get Python running on an end-user system.
I used to agree, but then I went to central eastern Africa (Burundi). 7mb takes a long time to download on a 3kbps connection. I'm not so sure now. There's a long tail of people with slow connections & small hard drives. I guess this issue is whether or not you care about supporting them.
A huge percentage of the Python code out there is server-side stuff. So, if you only have a 3kbit connection at your disposal, you're probably not going to have much luck deploying your application either.
For server-side, no.
And it seemed like the discussion was about distrubuting client-side apps written in Python using Unladen Swallow.
And it seemed like the discussion was about distrubuting client-side apps written in Python using Unladen Swallow.
Shouldn't there be max along with min and avg? Std dev is higher in many cases. Could there be an issue where max (worst case) has worse performance in Unladen Swallow?
I don't know if this is the case here, but often in benchmarking, "min" is the real answer of how fast something is going, and any time on top of that is some kind of overhead that you weren't trying to measure — some other process was taking up CPU time, you had to page in part of libc, crap like that. "avg" serves to tell you whether that overhead was reasonably small, or whether you need to run your tests again (on a quieter machine, say) to get a smaller "min".
This depends on the assumption that what you're measuring is actually a deterministic process. There are cases where it's not; as an example, the Self papers have all kinds of moaning about the measurement imprecision caused by physically-mapped direct-mapped caches without OS page coloring, but with more than one page of cache, on old SPARCs. For any particular logical→physical mapping, your measurements would be reproducible, but when it changed (if you got paged out and back in, or if you restarted the virtual machine in a new process) you would get different results.
This depends on the assumption that what you're measuring is actually a deterministic process. There are cases where it's not; as an example, the Self papers have all kinds of moaning about the measurement imprecision caused by physically-mapped direct-mapped caches without OS page coloring, but with more than one page of cache, on old SPARCs. For any particular logical→physical mapping, your measurements would be reproducible, but when it changed (if you got paged out and back in, or if you restarted the virtual machine in a new process) you would get different results.
I'm very happy the unladen-swallow team is making progress like this. Collin and Jeffery have done a fantastic job.
It's impressive that they were able to beat 2009Q1 even by using LLVM naively. Looks like their first few releases are the software analog of Intel's tick-tock strategy (http://en.wikipedia.org/wiki/Intel_Tick-Tock), and it looks like we're in for a hell of a 'tock' in 3 months. Keep up the good work guys!
I agree. I think that unladen-swallow has the potential to be a groundbreaking project not only for Python, but for all dynamic languages.
Great to see they are making progress, sucks about the memory. I'm really looking forward to the day this gets merged back into the core python distribution.
Looks like some good performance increases. Seems to have a memory hit. That will be looked at next release.
As it stands, I'm already very excited about this.