Weekly Edition
Return to the Press pageRecent Features
| |||||||||||||
The Python "Need for Speed" Sprint
The "Need for Speed" Sprint for the Python programming language, being
held in Reykjavik, Iceland, is about half way done, with significant
progress being made. We started the week with the Python 2.5 alpha 2
release candidate being around 10% slower than 2.4.3, the previous stable
release. Largely, this slowdown is due to newly added features,
particularly a change in the object type of exceptions which is showing a
60% slowdown.
According to my test of the current trunk development release, we are now neck and neck (measured with pybench). Remember, this doesn't count changes in developers test branches and work yet to be done in the next 3 days. Also, this doesn't include changes that Richard Jones is doing to dramatically reduce the 60% exception slowdown. The sprint has been generously sponsored and almost entirely funded by EWT LLC (a security trading company) with excellent local support from CCP Games (makers of EVE On-line MMORPG). I believe both of these companies are looking to hire Python programmers (contact me and I can forward on inquiries). Both of these companies use Python as a strategic advantage in their business, and have decided to try an experiment: If you sponsor a sprint, bring a bunch of Python hackers together, and give them a goal, does it help your business? They are directly addressing two very important questions in Open Source Software (OSS): What can business do to fund development, and How does OSS benefit a business. Many options for funding development has been tried: consulting, licensing, development, publishing, etc... This is believed to be the first time in the Python community where companies have supported a sprint at this level, bringing developers from around the world to work on things that are important to both the companies and the community as a whole. With the rate of progress in the last few days, I believe this sprint has been a complete success. Often core Python sprints only happen twice a year, around the conferences. The most recent one, March in Texas, was 4 days long. The 6 days we have here allows for significant progress to be made. EWT LLC also announced that they will be implementing a "scientist in residence" program where selected candidates will be funded to go to EWT headquarters in Los Angeles for 3 to 6 months, allowing you to work on Open Source projects. I think it's a great idea that will allow people to work on projects they might not otherwise be able to get time to do. If you are interested in more information about the things going on related to the sprint, you may wish to follow some of these links:
(Log in to post comments)
The Python "Need for Speed" Sprint Posted May 27, 2006 18:05 UTC (Sat) by arcticwolf (guest, #8341) [Link] It's Reykjavík, not Reykjavik. :)
The Python "Need for Speed" Sprint Posted May 28, 2006 10:02 UTC (Sun) by dmantione (guest, #4640) [Link] See http://en.wikipedia.org/wiki/Exonym_and_endonym
The Python "Need for Speed" Sprint Posted May 28, 2006 20:34 UTC (Sun) by arcticwolf (guest, #8341) [Link] Rubbish. That'd apply if the name was actually different - for example, if it was called Smoking Bay or so in English. This is just laziness. ;) (Which isn't really a problem, of course, but still something that's worth pointing out.)
The Python "Need for Speed" Sprint Posted May 31, 2006 9:14 UTC (Wed) by Taleel (subscriber, #10361) [Link] English speaking folks say and write "Munich" instead of München, "Nuremberg" instead of Nürnberg, "Brunswick" instead of Braunschweig. Do we care? No. Come visit Germany! ;-)
The Python "Need for Speed" Sprint Posted May 28, 2006 21:32 UTC (Sun) by jengelh (subscriber, #33263) [Link] We started the week with the Python 2.5 alpha 2 release candidate being around 10% slower than 2.4.3, the previous stable release. Largely, this slowdown is due to newly added features, particularly a change in the object type of exceptions which is showing a 60% slowdown. That's quite heavy. Python already runs slower than Perl for a given program ("converting" a binary file to a C source file), $ time png2c.pl -C images.cpp -H images.hpp sside.png ssplash.png vsplash.png; time png2c.py -C images.cpp -H images.hpp sside.png ssplash.png vsplash.png; Either I suck at writing Python, or regexes are in fact slower. This is Python 2.4.2. (Post a comment if you want the progs.)
The Python "Need for Speed" Sprint Posted May 28, 2006 22:40 UTC (Sun) by k8to (subscriber, #15413) [Link] It's well known that perl is faster than python. Python stack frames areheavier; python variable access is heavier. It _might_ be that the regexes are slower too, and it wouldn't surprise me, but I bet they use PCRE, so I'd chalk it up to the overall language first.
That all said, I find that the speed difference quite rarely matters.
Not PCRE Posted May 29, 2006 2:44 UTC (Mon) by amk (subscriber, #19) [Link] PCRE was used in Python 1.5.2, but it doesn't support 16-bit Unicode characters (only UTF-8 encoded strings), so Python now uses its own regex engine.
Actually Perl is not always faster Posted May 29, 2006 16:45 UTC (Mon) by scottt (subscriber, #5028) [Link] A microbenchmark comparing Perl and Python: Computer Language Shootout
Actually Perl is not always faster Posted May 29, 2006 23:10 UTC (Mon) by k8to (subscriber, #15413) [Link] Actually beginning comments with "actually" is always slightlybothersome.
Actually Perl is not always faster Posted Jul 15, 2006 21:02 UTC (Sat) by Barry (guest, #39099) [Link] There's some data based on the Computer Language Shootout at the bottom of this page. On Debian : AMD Sempron, Python performed faster than Perl in 9 out of 15 benchmarks. On Gentoo : Intel® Pentium® 4, Python performed faster than Perl in 13 out of 16 benchmarks.
The Python "Need for Speed" Sprint Posted May 29, 2006 20:42 UTC (Mon) by jafo (subscriber, #8892) [Link] One of the areas that was worked on was speeding up function calls, including changes related specifically to the frames. There isn't much that can be done about reducing the frame size, but I think a small reduction was done there. However, Richard Jones spent the first day of the sprint updating a patch which used zombie frames so that repeated calls to a function would use a cached frame that was already mostly initialized.
Sean
|
|||||||||||||