The Python "Need for Speed" Sprint
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:
- Wiki with up-to-the-minute information on successes: http://wiki.python.org/moin/NeedForSpeed/Successes
- My blog with recaps of the days: http://www.tummy.com/journals/users/jafo
- Richard Jones (Sprinter) blog: http://www.mechanicalcat.net/richard/log/Python/Need_For_Speed__day_1
- Activity on python-dev mailing list: http://mail.python.org/pipermail/python-dev/2006-May/thread.html
- Flickr photos of the event: http://www.flickr.com/photos/tags/pyneedforspeed/
- EWT LLC: http://ewtcareers.com/overview.html
- CCP Games: http://www.ccpgames.com/
Posted May 27, 2006 18:05 UTC (Sat)
by arcticwolf (guest, #8341)
[Link] (3 responses)
Posted May 28, 2006 10:02 UTC (Sun)
by dmantione (guest, #4640)
[Link] (2 responses)
Posted May 28, 2006 20:34 UTC (Sun)
by arcticwolf (guest, #8341)
[Link] (1 responses)
Posted May 31, 2006 9:14 UTC (Wed)
by Taleel (subscriber, #10361)
[Link]
Posted May 28, 2006 21:32 UTC (Sun)
by jengelh (guest, #33263)
[Link] (6 responses)
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.)
Posted May 28, 2006 22:40 UTC (Sun)
by k8to (guest, #15413)
[Link] (5 responses)
That all said, I find that the speed difference quite rarely matters.
Posted May 29, 2006 2:44 UTC (Mon)
by amk (subscriber, #19)
[Link]
Posted May 29, 2006 16:45 UTC (Mon)
by scottt (guest, #5028)
[Link] (2 responses)
Posted May 29, 2006 23:10 UTC (Mon)
by k8to (guest, #15413)
[Link]
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.
Posted May 29, 2006 20:42 UTC (Mon)
by jafo (guest, #8892)
[Link]
Sean
It's Reykjavík, not Reykjavik. :)The Python "Need for Speed" Sprint
See http://en.wikipedia.org/wiki/Exonym_and_endonym The Python "Need for Speed" Sprint
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
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
The Python "Need for Speed" Sprint
real 0m0.499s
user 0m0.460s
sys 0m0.040s
real 0m1.679s
user 0m1.650s
sys 0m0.030s (both are hot runs, i.e. all used files have been cached by the kernel before)
It's well known that perl is faster than python. Python stack frames are The Python "Need for Speed" Sprint
heavier; 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.
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.
Not PCRE
A microbenchmark comparing Perl and Python:
Computer Language Shootout
Actually Perl is not always faster
Actually beginning comments with "actually" is always slightly Actually Perl is not always faster
bothersome.
Actually Perl is not always faster
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.The Python "Need for Speed" Sprint