|
Release2009Q3
Details on the 2009Q3 release
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. 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. 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.