PyCon DC 2004
The most entertaining talk was "Faster than C: Static Type Interface with Starkiller", by Michael Salib. That was only the fourth best title of the conference, however. The top three were "'Scripting Language' My Arse: Using Python for Voice over IP", by Anthony Baxter; "Flour and Water Make Bread", by David Ascher; and "Two Impromptus, or How Python Helped Us Design Our Kitchen", by Andrew Koenig.
The Starkiller talk was enjoyable because Mike is one of two speakers who doesn't pull any punches--he calls a spade a shovel. His justification for writing a Python-to-C++ compiler was, "For the 15% of applications where speed matters, Python is slow. Sure, you can write it in C++, but C++ sucks. That's why we're using Python." Which actually makes a lot of sense if you think about it.
He went on to explain how Python's dynamic features that we love so dearly is the reason Python is so hard to optimize. "Python has lots of runtime choice points, but thirty years of compiler optimization research depends on eliminating runtime choices." By "runtime choices" he's referring to the fact that a variable may change type, attributes may be added after startup and the like, and all this happens after a traditional optimizer would have finished and said sayonara. "But dynamic capability is good because Python kicks ass." So Starkiller follows the 80/20 rule by optimizing what it can and leaving the rest. In particular, it refuses to optimize functions that contain eval, exec or dynamic module loading. But that's okay because most users don't use them.
Once those cases are eliminated, we examine the assignment statements to determine the types:
x=3; y=x; z=y; z=4.3 # x is int. y is int. z is int or float.
The types can be traced similarly through function arguments and return values. What about polymorphic functions? Starkiller handles them the same way C++ does: by generating distinct same-name functions for all argument combinations (aka overloading). Mike offers a few benchmarks to demonstrate the speed of this approach but also cautions, "All benchmarks are lies."
If you want to play with Starkiller, you're out of luck because there's no public download yet. There actually were several talks this conference presenting software that's not yet available, either because it's not robust enough or it's waiting for legal paperwork. I didn't see that in previous conferences. A few attendees commented, "Well, it's not as useful as a talk on something that's available, but on the other hand it's good to learn about cutting-edge research as soon as possible." The conference reviewers seemed to have done their job of approving pre-alpha talks only if they covered an area that was central to Python and long on Python's wishlist. Mike had his own reason for not revealing the code. "If you kill me now, you'll never get it."
Mike offered an obligatory acknowledgment. "Who owns Starkiller? MIT! Who paid for Starkiller's development? You did! Pat yourselves on the back! Thank you, taxpayers!!!" He then begs the audience not to tell DARPA that Starkiller is a Python-to-C++ converter rather than the sun-destroying weapon they think he's building. The presentation slides have a few more zingers too; they're available under the Session Papers link on the PyConDC2004 Aftermath link in Resources.
Finally, Mike ended with an indictment of the sun. "Destroy the sun! We hatessss it! It burns! The pale yellow face mocks us, keeps us from hearing the machine. It causes global warming. It causes sunburns. DARPA says the sun is bad, it warms our enemies. It weakens our dependence on foreign oil. There's only one logical conclusion: we must destroy the sun."
Guido had one question during Q&A. He asked, "Is it difficult to have so much attitude all the time?"
(There's a discrepancy about when Guido asked that question. My notes say it was during this talk. The SubEthaEdit notes say it was during Anthony Baxter's VoIP talk, which was almost as feisty. But of course my notes are right.)
Ah yes, that VoIP talk. Voice over IP may be Python's next killer application. Internet telephony currently is growing slowly, but it has the potential to become really big when it reaches critical mass. As VoIP becomes ubiquitous, people will need a new generation of applications and phones. Stoom, which runs under Twisted, is one small step in that direction. It needs a better UI, but it proves that Python is up to the task, even though VoIP requires generating sound packets exactly 20 milliseconds apart.
By the way, the title of the VoIP paper is slightly modified from the original. It's currently "'Scripting Language' My Arse: Using Python for Voice over IP." Originally it was "'Scripting Language' My Shiny Metal Arse: Using Python for Voice over IP".
Zope 3 hasn't changed much since last year; it's just further developed. It still aims to be friendlier to application developers than Zope 2, more Pythonic, more modularized, more specific in its API use (for example, less implicit acquisition), with better documentation early and a better integration of Web-based and filesystem-based application development methods. This will make applications more portable between Zope and other environments and make individual Zope features more accessible to non-Zope applications.
The PyPy talk showed that a Python virtual machine can be written in 16,000 lines of Python. The prompt looks like this: >>>>, with one extra > for each recursive level of PyPy. PyPy is markedly slower than Python and exponentially slower recursively: the innermost interpreter interprets the code, the next interpreter interprets the interpreter interpreting the code. But the PyPy developers have faith that they eventually can make it faster than CPython.
Pyrex stands alongside ctypes as an indispensable part of the C extension writer's toolkit. Pyrex compiles ordinary Python to C, but for better optimization you can use the cdef statement to declare variables as certain C types. Expressions using those variables are compiled directly to C, bypassing Python's slow object infrastructure.
Several other talks are worth mentioning but I don't have the space. Browse the Session Papers link on PyConDC2004Aftermath site and see which topics night interest you.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
9 hours 23 min ago
- BASH script to log IPs on public web server
13 hours 50 min ago
17 hours 26 min ago
- Reply to comment | Linux Journal
17 hours 59 min ago
- All the articles you talked
20 hours 22 min ago
- All the articles you talked
20 hours 25 min ago
- All the articles you talked
20 hours 27 min ago
1 day 51 min ago
- Keeping track of IP address
1 day 2 hours ago
- Roll your own dynamic dns
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?