|
Release2009Q3
Details on the 2009Q3 release
Featured Unladen Swallow 2009Q3Unladen Swallow 2009Q3 is the second release of Unladen Swallow to use LLVM for native code generation, and the first to use runtime feedback for optimization. To obtain the 2009Q3 release, run svn checkout http://unladen-swallow.googlecode.com/svn/branches/release-2009Q3-maint unladen-2009Q3 The Unladen Swallow team does not recommend wide adoption of the 2009Q3 release. This is intended as a checkpoint of our progress, a milestone on the long path to our eventual performance goals. Note that Unladen Swallow tracks LLVM trunk fairly closely, and will not build against LLVM 2.5 or 2.6. Highlights:
Lowlights:
Memory UsageIn the memory benchmarks, we compared the fastest configuration for Q3 against the fastest configuration for Q2. The Q2 configuration is the same as what was reported in Release2009Q2. The performance degradation/improvement is calculated using ((new - old) / new). Units are kilobytes. 2009Q2 vs 2009Q3 ai: slowpickle: slowunpickle: django: rietveld: GDB SupportThe Unladen Swallow team added support to gdb 7.0 that allow JIT compilers to emit DWARF debugging information so that gdb can function properly in the presence of JIT-compiled code. This interface should be sufficiently generic that any JIT compiler can take advantage of it. Example backtrace before: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aaaabdfbd10 (LWP 25476)] 0x00002aaaabe7d1a8 in ?? () (gdb) bt #0 0x00002aaaabe7d1a8 in ?? () #1 0x0000000000000003 in ?? () #2 0x0000000000000004 in ?? () #3 0x00032aaaabe7cfd0 in ?? () #4 0x00002aaaabe7d12c in ?? () #5 0x00022aaa00000003 in ?? () #6 0x00002aaaabe7d0aa in ?? () #7 0x01000002abe7cff0 in ?? () #8 0x00002aaaabe7d02c in ?? () #9 0x0100000000000001 in ?? () #10 0x00000000014388e0 in ?? () #11 0x00007fff00000001 in ?? () #12 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70, F=0x14024e0, ArgValues=@0x7fffffffe050) at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395 #13 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain (this=0x1405b70, Fn=0x14024e0, argv=@0x13f06f8, envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377 #14 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe398, envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208 And a backtrace after this patch: Program received signal SIGSEGV, Segmentation fault. 0x00002aaaabe7d1a8 in baz () (gdb) bt #0 0x00002aaaabe7d1a8 in baz () #1 0x00002aaaabe7d12c in bar () #2 0x00002aaaabe7d0aa in foo () #3 0x00002aaaabe7d02c in main () #4 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70, F=0x14024e0, ArgValues=...) at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395 #5 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain (this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377 #6 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8, envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208 So much nicer. See http://llvm.org/docs/DebuggingJITedCode.html for more details. Thanks to our intern, Reid Kleckner, for doing the heavy lifting on this feature! Benchmarks2009Q3 uses a more sophisticated system for determining which functions to compile than did 2009Q2. Accordingly, we no longer use Unladen Swallow's -j always option when benchmarking 2009Q3. Benchmarking was done on an Intel Core 2 Duo 6600 @ 2.40GHz with 4GB RAM with a 32-bit userspace. The performance degradation/improvement is calculated using ((new - old) / new). 2009Q2 vs 2009Q3 slowspitfire: ai: slowpickle: slowunpickle: django: rietveld: call_simple: $ ./perf.py -r -b call_simple --args "-j always," ../q2/python ../q3/python |
► Sign in to add a comment
Seems like nice progress! Definately an interesting project to follow as a python coder. On the other hand, one could remark about the comparisons. It's hard for memory usage to be over 100% smaller than what it's compared to, but over 100% larger works....
Awesome - keep up the good work!
Really great improvement since Q2, waiting for optimized regex in Q4. Thanks for new backtrace! =)
I'm curious if the release of the Go language by Google will impact the Unladden Swallow project, personally, I hope not. :)
#kalle.happonen yes, I thought the same. Probably they mean that Q2 uses 930% more than Q3, giving a reduction of 89%. Still, a very nice accomplishment.
#doug.farrell I doubt that either Go nor Noop will impact Unladden Swallow too much. I think they are both rather experimental, fun projects, whereas the swallow is very serious.
oh, I've totally overlooked the benchmark sections...
BTW, what does it mean "Mem max: 212344.000 -> 96884.000: 119.17% smaller" ?
"119.17% smaller" sounds like negative size :o)
psyched about your progress, keep up the great work!
cool! what is the performance relative to the mainline python 2.6 implementation?
This is great progress. Congratulations.
It is impossible to use 930% less of something without resulting in a negative amount. I think they meant that the previous version used up to 930% more memory.
Awesome!
The percentages are strangely computed. As several other readers have commented, you cannot reduce a value by more than 100%. It would be much better to determine the reduction in terms of the old version, like (new - old) / old. For the "927%" example, the result would become -0.9027 = a reduction of 90.27%.
Remember, a percentage is just a way to express a ratio. The ratio of memory use between the old and new versions as 9.0. It is quite reasonable to express that ratio as 900%.
@leon: Agreed, while you can have a ratio of 9:1 which is 900%, that ratio is comparing the numerator (old version) to the denominator (new version). Google, however, is trying to compare the new to the old.
Let's first agree that an old to new ratio of 1:2 means an increase of %100. I'm using this as an example because you can just look at the ratio and easily see that it increased by %100. We get this by (((new-old) / old) * 100) = percent_change which we can see is the correct formula. If we apply that same formula to the numbers they gave above we get -90.27%.
Looks like Google marketing got their hands on the stats above ("900% is big, that'll sound better than 90%").
The use of percentages here and the word smaller is misleading, if not inaccurate. I would recommend leaving the output in ratio form.
Are the changes in standard deviations especially important?
好牛啊
Can I start career in python. I am php developer with 5 months experience. I am from India.