IBM Builds a Computer That Plays "Jeopardy!"

From the New York Times:

For the last three years, I.B.M. scientists have been developing what they expect will be the world’s most advanced “question answering” machine, able to understand a question posed in everyday human elocution — “natural language,” as computer scientists call it — and respond with a precise, factual answer. In other words, it must do more than what search engines like Google and Bing do, which is merely point to a document where you might find the answer. It has to pluck out the correct answer itself.

That's right - the computers have taken Jeopardy and have their sights clearly set on taking over major corporations like Google and Microsoft. Let me be the first to say that I, for one, welcome our new supercomputer overlords.

Breakdown Of The Top 500 Supercomputers.

The BBC made some interesting infographics for the TOP 500 supercomputers.  I enjoy this data as I have used my share of supercomputers. (And will continue to for the foreseeable future.)

Here are the breakdowns: (Enjoy!)

1.  By Country.

2. By OS.

3.  By Processor.

4.  By Manufacturer.

93.8% Of The fastest 500 Supercomputers Run Linux

469 of the Top500 supercomputer list run Linux. Furthermore, Linux is the only operating system gaining ground on the list. Last year Linux accounted for 91.8%. Unix, Mac OSX, and Windows have all lost ground on the list.

For those of you who would like to try Linux you can download a great version here. Or you can buy a Dell preloaded. :)

Multicore Is Bad News For Supercomputers?

If you are like me, you are excited about the ability to have 4, 8, 16+ processors running in you laptop or desktop at home. However, are we sure an increase in processor number = increase in performance?

According to tests done at Sandia National Laboratories, the answer maybe no for now especially in supercomputing environments. :(

With no other way to improve the performance of processors further, chip makers have staked their future on putting more and more processor cores on the same chip. Engineers at Sandia National Laboratories, in New Mexico, have simulated future high-performance computers containing the 8-core, 16‑core, and 32-core microprocessors that chip makers say are the future of the industry. The results are distressing. Because of limited memory bandwidth and memory-management schemes that are poorly suited to supercomputers, the performance of these machines would level off or even decline with more cores. The performance is especially bad for informatics applications—data-intensive programs that are increasingly crucial to the labs’ national security function...

For informatics, more cores doesn’t mean better performance [see red line in “Trouble Ahead”], according to Sandia’s simulation. “After about 8 cores, there’s no improvement,” says James Peery, director of computation, computers, information, and mathematics at Sandia. “At 16 cores, it looks like 2.” Over the past year, the Sandia team has discussed the results widely with chip makers, supercomputer designers, and users of high-performance computers. Unless computer architects find a solution, Peery and others expect that supercomputer programmers will either turn off the extra cores or use them for something ancillary to the main problem.

At the heart of the trouble is the so-called memory wall—the growing disparity between how fast a CPU can operate on data and how fast it can get the data it needs. Although the number of cores per processor is increasing, the number of connections from the chip to the rest of the computer is not. So keeping all the cores fed with data is a problem. In informatics applications, the problem is worse, explains Richard C. Murphy, a senior member of the technical staff at Sandia, because there is no physical relationship between what a processor may be working on and where the next set of data it needs may reside. Instead of being in the cache of the core next door, the data may be on a DRAM chip in a rack 20 meters away and need to leave the chip, pass through one or more routers and optical fibers, and find its way onto the processor.

In an effort to get things back on track, this year the U.S. Department of Energy formed the Institute for Advanced Architectures and Algorithms. Located at Sandia and at Oak Ridge National Laboratory, in Tennessee, the institute’s work will be to figure out what high-performance computer architectures will be needed five to 10 years from now and help steer the industry in that direction.

“The key to solving this bottleneck is tighter, and maybe smarter, integration of memory and processors,” says Peery. For its part, Sandia is exploring the impact of stacking memory chips atop processors to improve memory bandwidth.

The results, in simulation at least, are promising [see yellow line in “Trouble Ahead].

The Future of Computing - Super or Otherwise

This week I am in the very beautiful and uncomfortably hot and humid capitol of the Lonestar state - Austin, Texas. Austin is home to the Texas Advanced Computing Center (TACC), the newest big player in the academic supercomputing world. TACC got the first "track 2" machine in the NSF's push for a petascale supercomputer. For more on the track 2 machine, known as Ranger (shown on the right), see one of my other posts here.

The essential problem is that modern supercomputers are moving into the realm of multicore processors. Ranger uses quad-core processors with 16 cores and one network connection per node. Ranger has a total of 3,840 nodes, giving it effectively 61,440 processors. For codes like ASH (used for simulating the interior of the sun) that require global communication (every processor needs to talk with every other processor at every time step), the cost of standard global communication scales as the number of processors squared when you use MPI. MPI is the current standard for communication between processors and it works by each processor sending and receiving messages from the other processors. MPI works just fine with 256 or 512 processors and there are some systems (such as the BigBen system as the Pittsburgh Supercomputing Center) where our code can effectively use up to 2048 processors. However, that N^2 scaling really starts to wipe us out at the high processors counts on systems like Ranger.

Here at TACC, I'm leaning about one possible solution to this problem - OpenMP. MPI treats every core on a system like Ranger as an independent processor with it's own independent memory. However, if you think about how your dual-core desktop system works, it's not two processors with their own memory. Instead, both of your cores share the same memory. If your cores are careful and play nicely with each other, they can share the memory without chopping it up into two pieces. For example, core 1 can load an array into memory, core 2 can add 3 to each entry, and then core 1 can divide each element of the array by the next element. This is known as a shared memory paradigm and the standard for shared memory programming in known as OpenMP. And yes Joe, the "Open" in the name does stand for open source.

On a system like Ranger, each node is a shared memory system, so instead of passing messages between processors on a node, the processors simply have access to the memory of the other processors. There is still a cost for this communication, but it is far, far less than the cost of bouncing messages around the network. The real benefit of using OpenMP, however, is that instead of our communication cost scaling as N^2, using shared memory on each node would cause (N/16)^2 scaling. That means that when we were limited to 512 processors before, we could now theoretically use 131,072 processors for the same communication cost.

The benefits of OpenMP, however, go well beyond the scientific supercomputing community. Since most desktops and laptops are now multicore shared memory systems, OpenMP is becoming the standard in consumer multi-core programming as well. So as core counts expand (Intel now has a working 256 core prototype), OpenMP will probably be the key to being able to effectively use all of those cores.

85% of Fastest 500 Computers Use Linux

Via Top500:

Operating system Family	Count	Share %	Rmax Sum (GF)	Rpeak Sum (GF)	Processor Sum
Linux	427	85.40 %	8465100	13333004	1408054
Windows	5	1.00 %	159264	211320	25472
Unix	25	5.00 %	619912	874185	73174
BSD Based	1	0.20 %	35860	40960	5120
Mixed	40	8.00 %	2391451	2941095	897127
Mac OS	2	0.40 %	28430	44816	5272
Totals	500	100%	11700016.97	17445379.70	2414219

Modern Supercomputers vs. Simeon Denis Poisson

This spring, the Texas Advanced Computing Center (TACC) brought online what they bill as the largest open access supercomputer in the world. True to form, they've named it something distinctly Texan - Ranger. Other systems at TACC go by names such as Lonestar, Maverick, and Ranch. Ranger has a whopping 504 teraflops peak performance, 125 terabytes memory and 1.7 petabytes disk space. And it doesn't stand a chance against a problem studied by an 18th century Frenchman named Simeon Denis Poisson.

Poisson's equation is quite elegant. It can be written in just one line, as you can see below.Yet this simple equation is a nightmare for the latest generation of supercomputers. Here's why.

In the 80's and 90's, advances in computer speed were all about faster processors. In about 10 years, processor speeds went from megahertz to gigahertz. To these computers, operation counts and memory size were the only things that really limited the problems that could be tackled. However, in the late 90's, we started to hit a wall in terms of how fast you could make a single processor. Performance leveled out somewhere around 2 - 3 GHz so that a 5 GHz chip really ended up doing the about the same amount of work as a 2 GHz chip and the 5 GHz processor used far more energy (and created far more waste heat). The solution to this problem was to design supercomputers that had many processors. Today, this leaves us with Ranger with 15,744 quad-core chips for a total of over 60,000 processors. To use more than one of these 60,000 cores, you have to break your problem into pieces and send these pieces to individual cores which do the work and then send the results back to the master processor. The master processor then puts the pieces back together and spits out the answer. That the computer side of the problem.

Now let's look at the other side of the problem - the math. Let's compare Poisson's equation to the wave equation, given below.
When you write the wave equation like this, it is easy to see that you get Poisson's equation in the limit that the wave speed, c, goes to infinity. Since the wave speed is the speed at which information propagates through a system, this means that when we solve Poisson's equation, we are saying that every part of our physical domain is instantaneously aware of every other part of the domain.

You've probably already figured out that when you have a computer that splits a problem into 60,000 pieces solving a problem where every piece needs to know exactly what is going on in every other piece, that leads to a lot of communication. In fact, the communication scales as the number of processors squared. What's worse is that on many new systems, there are fewer network connections than processors. On Ranger, for example, there is one network connection for every 16 processors. That's like telling a thousand people that they all need to call each other but there are only 60 telephones. Instead of getting more work done as you add processors, after some number of processors, when you add more the processors simply spend all of their time talking to other processors rather than doing any real work. So while many hands make light work, too many chefs still spoil the soup.

So how do you solve a Poisson equation on a supercomputer like Ranger? Well, right now the answer is you don't. Our code, ASH, is currently limited to using small chunks of Ranger at any given time. There are a number of promising ideas on the horizon involving multi-grid schemes. Another approach is to solve the more general wave equations which have finite wave speeds so that processors only need to know what is going on with their neighbors rather than with every other processor. Finally, there are some machines on the horizon with faster networks with fewer processors per connection. All of these things, however, are unproven and may or may not improve the situation. For now, we're stuck unable to solve a 300 year old equation.

Simeon Denis Poisson must be laughing his head off.