Interpreted programming languages usually don’t find too many friends in high performance computing. Yet Python, one of the most popular general-purpose interpreted languages, has garnered a small community of enthusiastic followers. True believers got the opportunity to hear about the language in the HPC realm in a tutorial session on Monday and a BoF session on Wednesday. Argonne National Lab’s William Scullin, who participated in both events, talked with HPCwire about the status of Python in this space and what developers might look forward to.
There is a growing feeling that merely taking the latest processor offerings from Intel, AMD or IBM will not get us to exascale in a reasonable time frame, cost budget, and power constraint. One avenue to explore is designing and building more specialized systems, aimed at the types of problems seen in HPC, or at least at the problems seen in some important subset of HPC. Of course, such a strategy loses the advantages we’ve enjoyed over the past two decades of commoditization in HPC; however, a more special purpose design may be wise, or necessary.
Most of the efforts to address the problem of shrinking transistor geometries have focused on making the devices behave more precisely. But what if instead of trying to make the transistors better, we purposefully try to make them worse. Although it sounds counter-intuitive, developing processors that are naturally error-prone is exactly what one team of researchers has set out to do.
A new, simplified language for programming in cloud environments called “Bloom” is set for release later this year. An interview with one of Bloom’s creators, Joseph Hellerstein of U.C. Berkeley, explains the practical elements.
New generation of HPC programmers embracing higher level languages.
Striking a balance between science and software engineering.
Hybridizing MPI applications with CPU cores and GP-GPUs.
Will current codes survive to the exascale era?
Simple is a goal too far, says NAG’s Andrew Jones.
Yet another organization takes a crack at multicore programming.