Skipping C - SPE and synthetic programming in Python

Expression and Loop Libraries for High-Performance Code Synthesis. Christopher Mueller and Andrew Lumsdaine. LCPC2006.

To simultaneously provide rapid application development and high performance, developers of scientific and multimedia applications often mix languages, using scripting languages to glue together high-performance components written in compiled languages. While this can be a useful development strategy, it distances application developers from the optimization process while adding complexity to the development tool chain. Recently, we introduced the Synthetic Programming Environment (SPE) for Python, a library for generating and executing machine instructions at run-time.

The authors didn't show much interest yet in supporting the most widespread ISAs, those for Intel processors. Instead they focus on PowerPC but also Cell. Have fun with Python and PS3 hacking.

Edit: You might also checkout the site of Christopher Mueller containing related material.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Inappropriate Attitude

I think the quip about the PS3 hacking sure sounds quite immature. Would you purchase a single desktop machine for $1000, or _two_ PS3s (each with 3.2GHz cell-processors complete with a vector unit that makes Intel's offerings pathetic in comparison) for the same price? It does not take a rocket scientist to figure THAT one out, even if rocket scientists are the intended users.

And, remember, this application is targeted to the field of science, where problems often take days, weeks, or months of computation time, depending on the level of simulation detail they're interested in. Having a processor architecture that is concurrently affordable and break-neck fast can save significant amounts of cash expenditures trying to solve problems (remember, someone has to pay the electric bills, and Intel/AMD chips consume VORACIOUS amounts of power for their performance when compared to PowerPC. Combine that with a faster performance, and the savings add up even more). Plus, PowerPCs have 16 more registers that are usable by compilers than x86-64, which gives compilers even more opportunity for optimizations.

Also, Intel only has 5% the market share of all CPUs in the world -- the rest being dominated by 68000 (yup!), PowerPC, MIPS, and Sparc. That 5% covers only desktop machines; the other 95% is all embedded machines -- such as the PS3, the CPUs in your car, etc. Ergo, Intel's are the MINORITY instruction set. And good riddance too.

I hope this comment provides some balance to what I perceive as a pompous dismissal of the efforts of the engineers. I, for one, appreciate the work.

I suspect you've misread the

I suspect you've misread the tone entirely - that wasn't a "quip" about hacking, IMO.

It's not unreasonable to express a desire for a lib that works on multiple platforms - on the other hand, I've been of the opinion that "real world" work with Cell/the PS3 is going to need platform-specific libs and code for a few years yet due not least to some of the more unusual aspects of the architecture. There're too many low-level details worth getting right, which means that they need to be exposed to users. If you look through EDSL-tinted glasses then that's as much an issue when writing a library as it is in designing a language.

Please try to restrict LtU

Please try to restrict LtU discussions to programming language issues as much as possible. Thanks.

As a quick technical note, I

As a quick technical note, I believe Cell is a PPC architecture?

Sort of

I would say that the Cell architecture is to the PowerPC as the PowerPC is to IBM's POWER architecture, except that's badly understating how different the CPU, vector unit, and bus architectures of the Cell are. But it is kind of interesting to note that the PlayStation 3 and the XBox 360 are both PowerPC-derived systems, while the Mac has moved from the PowerPC to Intel hardware.

The bus architecture's

The bus architecture's definitely responsible for a lot of the need for low-level work. I'm not saying it can't be abstracted any, but I'd sure want explicit channels for some of it!