English | 中文 | Русский | Français

2,595 Posts served

8,341 Conversations started

Supercomputing '07: Computer Environment and Evolution

By Arch Robison (Intel) (19 posts) on November 17, 2007 at 8:50 pm

I'm back from Supercomputing '07. Gone is the heyday of wacky hyper-dimensional topologies and strange new architectures like the Connection Machine. Clusters built from commodity parts have become the ubiquitous denizens of the High Performance Computing (HPC) ecological niche. The Precambrian explosion seems to be over.

The environment directs evolution. It was good to walk around the exhibits and be reminded of how different the HPC environment is from desktop parallelism, and how TBB differs somewhat in its focus compared to classic HPC.

• HPC applications run on million dollar machines. In this environment, owners are willing to do a lot of code rewriting, and use labor-intensive techniques like message-passing to get good speedup on thousands of cores. In a former life, I had fun doing that on a 256 node hypercube. TBB in contrast, targets desktop machines, where programmer time is premium. TBB perhaps gives up a little performance short of optimal so you don't have to write message-passing.
• The high machine costs cause some strange cross-breeding. E.g., Los Alamos' latest big machine "Roadrunner" marries AMD Opterons to IBM Cell processors. (Seems more like a platypus than a bird to me.) Desktop software is typically expected to run on many desktops; it's authors have neither time nor money to port it to odd de jour architectures.
• HPC codes seem to focus on crunching large regular data sets. Exemplars are finite-element codes and fluid solvers. Desktop software involves a lot more than marching an army in a straight line. For example, my standard example of an application that I would like to speed up is program compilation. Sure, you can get some speedup with parallel make, but why not parallelize the guts of the compiler? Likewise a parallel linker would be really useful.
• HPC codes run on dedicated machines, unperturbed by other stuff running on them like web browsers, spreadsheets, and video. In such a pristine environment, the HPC programmers can orchestrate things in detail. The desktop, in contrast, is a less controlled environment where many programs vie for processor resources. So TBB focuses on techniques that enable automatic load balancing even if the machine is perturbed.
• The Fortran dinosaur roams freely in HPC land. Something like TBB is not practical with C or Fortran, because TBB depends upon compile-time polymorphism.

Though the supercomputers seemed dully alike, there was a corner with "disruptive technologies". Any of these could radically change the environment, and thus future evolution of computers. Four of them were based on using different physics than traditional computers:

• Nantero is working on technology for building non-volatile memories out of nanotubes. If it pans out, it could enable radically faster and denser non-volatile memories than what we get with flash. Of course it's the newcomer versus well tuned established processes. (Anyone remember how gallium arsenide was going to take over?)
• D-Wave is working on quantum computing. They are not trying to build a universal computer, but rather an accelerator for certain NP-complete problems like integer linear programming and 3SAT.
• IBM Research was showing off an optical circuit board, with one optical layer printed with a transparent polymer. That could radically improve memory bandwidth.
• Luxtera is making silicon photonics cheaper. They were demonstrating 40 Gigabit/sec cables. The ends had electrical connections, but the cable itself was optical.

It will be interesting to see which of these technologies survive and how they mutate, and which ones disrupt the ecosystem.

Categories: Parallel Programming, Threading Building Blocks

Comments (9)

November 18, 2007 2:50 AM PST UX-admin

"The Fortran dinosaur roams freely in HPC land." As well as he should, for as long as Fortran programs and Fortran compilers produce the fastest binary code. I wish we learned Fortran at the university instead of Java. I wish there were more people in the IT industry which knew Fortran.

November 18, 2007 12:08 PM PST Arch Robison (Intel)

When I was working on KAI C++, our vision was to make C++ as fast as Fortran. We, in conjunction with some smart metaprogrammers, were closing in. See http://www.oonumerics.org/blitz/benchmarks . Alas, after Intel acquired KAI, no company continued to pursue this vision. In principle, C++ with the C99 keyword <code>restrict</code> enables about the same degree of optimization as Fortran, albeit there are still some problems because of the lack of true multidimensional arrays in C++.

November 20, 2007 12:31 AM PST Xavier Warin

I'm a dinosaur (former fortran developper) using MPI for my soft. In fact i use both TTB and MPI. I was a KAI C++ user, and i developp everything using blitz. I don't think the industry is ready to developp chips with hundred of cores inside. So the best solution for the next years is MPI AND multi thread (i moved from boost::thread to tbb this summer) Question : can we use TBB with xls compiler ?

November 20, 2007 10:42 AM PST Arch Robison (Intel)

You mean the spreadsheet compiler at http://www.exceltranslator.com ? That's an intriguing thought, but I have not tried it.

November 20, 2007 10:44 PM PST Xavier Warin

Sorry i wanted to mean xlc (IBM c++ compiler). Our soft run on Blue Gene machine. But i didn't know about this spreadsheet compiler. I will ask people who do a lot of excel to test it.

November 21, 2007 2:17 PM PST Arch Robison (Intel)

Urs von Matt contributed a TBB patch for AIX that deals with the weak memory consistency model on the Power architecture. See http://softwarecommunity.intel.com/isn/Community/en-US/forum..... 41979.aspx . Those changes will be integrated into the next developer release. Because the patch was for AIX, I do not know whether it is relevent to Blue Gene or not. What OS does Blue Gene run?

November 22, 2007 2:41 AM PST Xavier Warin

It is a modified (i think) Linux OS.

November 26, 2007 2:47 PM PST Arch Robison (Intel)

I read up on Blue Gene at http://www.supercomp.org/sc2002/paperpdfs/pap.pap207.pdf . It's a distributed memory architecture, and even on a given node, the two cores are not cache coherent. So TBB won't work for it. Sounds like MPI is the only practical way to go for Blue Gene. When we first designed TBB, we discusded whether to support distributed memory architectures or not. The consensus was to not support distributed memory, because of the much higher burden on the programmer. E.g., having to marshal complex data structures. That high burden is appropriate for programming multi-million dollar HPC machines, but not for the kind of desktop machines that we are targeting with TBB. Have fun programming it - I kind of miss programming the monster machines.

November 23, 2008 2:23 AM PST shachris23 Total Points: 435 Status Points: 0 Green Belt

Hi Arch and Xavier.. Speaking of Blitz++, dont you guys think that it's a perfect (or almost perfect) array/matrix container that the C++ community could offer? I've gone through so many opensource array/matrix containers out there (Boost's multi-array, STL's valarray, SPUC/TNT, VSIPL++, StlSoft's pod_vector and fixed_array123d) that I think in terms of performance, intuitive ease-of-usage, and documentation, Blitz++ is probably the best we can get right now. It would be really nice if Intel picks up/investigates/supports such library like Blitz++ so that the C++ community could finally have the de facto standard for array/matrix container (finally!). C-style array has its merit in terms of performance...but I think parallelism and compiler optimization combined probably offset the maintenance, readability, AND extensibility cost we have to pay for using C-style array Just my thought though...(btw, I'm not from Blitz++!)

Trackbacks (0)

Leave a comment