insideHPC is reporting that legislators in Japan are questioning the benefit of spending 112 billion Yen (about $1.4 billion U.S. dollars) for its K supercomputer, the world’s number 1 fastest system according to the Top500 list.

I leave it to the Japanese officials to decide if the K system was a justified expense. But regardless, the fact is that supercomputers do not have to cost nearly this much. In fact, high-performance, energy efficient GPUs can be used to build world-leading systems at a fraction of the cost.

Custom processors don’t cut it for HPC

The 112 billion Yen price tag for the K computer was just the start.  Add to this about 10 billion Yen ($128 million U.S.) each year to power and maintain the mammoth system, and it’s clear that the costs will really start to add up.

The K system costs so much to build because the SPARC CPU at the heart of the machine is an expensive, custom-designed processor.  HPC history has repeatedly shown that the development cost of custom processors is just not economically viable in the high-performance computing market.

On the other hand, hybrid systems that use x86 CPUs accelerated by GPUs, ride on the economics of high-volume consumer and enterprise markets, and provide an economical way to build HPC systems.

Petaflops for a bargain

The Tsubame 2.0  supercomputer at Tokyo Institute of Technology’s Global Scientific Information and Computing Center (GSIC), is a great example of a high-performance, cost-efficient system.  It currently ranks as the #5 system on the Top500 list.

And more importantly, Tsubame 2.0 is central to enabling research and breakthroughs in Japan across a range of fields, ranging from climate research to quantum chemistry, and much more.  In fact, the Tokyo Tech team recently won the coveted Gordon Bell Prize at SC11 for its research on creating lighter, stronger metallic materials using Tsubame 2.0

And, Tsubame it didn’t cost an arm and a leg to develop.

With a modest budget of around $40 million, Tsubame has achieved 1 petaflop of performance at approximately 1.2 megawatts of power consumption, earning it the top spot as the world’s #1 most energy efficient petaflop-class supercomputer (#10 overall) on the Green500 list.

Compare Tsubame’s 1.2 megawatts with that of the 12.7 megawatt required to power the K system, and it adds up to a huge cost difference.

What’s more, once NVIDIA GPUs based on the next-generation Kepler architecture arrive, they will provide a nearly 3x increase in performance per watt over current GPUs.  So, a system the same size as K could be built for one-tenth the cost and would consume less than one-tenth the power.

Today petaflops, tomorrow exaflops

Because of their inherent performance, power efficiency and cost advantages, GPUs will continue to be the go-to technology for tomorrow’s supercomputers. And, they represent the best path for the industry to reach beyond petaflops to exascale computing by the end of this decade.  You can learn more about GPUs and the path to exascale here.

With this kind of energy efficient computing power on the horizon, new dramatic breakthroughs in science and technology that are impossible today, will finally be within reach.

What do you think?   Please share your thoughts and comments below.

  • http://www.facebook.com/people/Achwaq-Khalid/100003292470248 Achwaq Khalid

    Alright, got it, i see i see.

  • Sumit Gupta

    Coincidentally, another GPU-accelerated supercomputer was announced today in Japan at the Tsukuba university.
    This system has a peak double precision rating of 800 teraflops (0.8 petaflops) while consuming just 400 KWatt of power and takes up only 26 racks of space.      In contrast, the K computer requires 33 times more racks of servers (864 racks total) deliver 10 petaflop Linpack preformance (around 11.2 petaflop peak double precision).

  • http://www.facebook.com/prasanna.raja79 Prasanna Rathnaraja

    If the Japanese are already using  GPU-accelerated supercomputer I think there must a logic reason behind the K – built on SPARC.

  • Sumit Gupta

    Hi Prasanna

    The Japanese scientific and govt group decided to invest in the “K computer” about 8-9 years ago, well before GPUs came on the scene.   At the time, it was a bold move to leapfrog the rest of the world in supercomputing.   

    The GPU-accelerated systems at Tokyo Tech and Tsukuba University are fairly new (and new decisions).

    Sumit

  • http://www.facebook.com/prasanna.raja79 Prasanna Rathnaraja

     Now it makes more sense. Thank You

  • http://www.facebook.com/prasanna.raja79 Prasanna Rathnaraja

    Hi Sumit

    Just wanted to ask, don’t you think that it will be more efficient to build community grids rather than supercomputers.

  • Dan X

    Can they not use the heat that is made when the supercomputers use so much power to be transferred as electrical power into a secondary generator to store and be used? It seems a waste to use power to use the super computer and use power to cool the super computer too. Once they figure how to do this, they can increase the amount of R&D many times over than it is now.

    Dan.

  • Sumit Gupta

    Community grids are terrific to solve certain type of problems.  Grids are good when one problem does not need to be split across lots of servers / PCs.  Instead, each server / PC does something independently and the results are put together.

    Typically, the “best” supercomputers have a very good network connection between each server node.   This way, when an application is split across a whole bunch of servers, the communication between the servers does not become a bottleneck.

  • Sumit Gupta

    Dan

    In fact, this is a very active area.  Most new data centers that are being built are being built to reuse the heat generated by the data centers.  It increases the initial (Capital) cost of the project, but then the yearly operating cost of the facility is lower.

  • https://me.yahoo.com/a/hrV0CgkEsuTLYbdkMG5s3Exn0d64qynD#b89f9 nathanweeks

    Fujitsu uses the SPARC CPUs in their SPARC enterprise servers (as does Oracle), so these aren’t really custom-built just for HPC (although the money spent on the K computer certainly subsidized their developement) and the fact that entire K computer ran the LINPACK for 29 hours and 28 minutes without a single failure is a testament to the “enterpriseness” of the components used.

    It’s likely that Fujitsu will continue to develop these made-in-Japan CPUs in the forseable future, for the same reasons that China wants to make their own CPUs and not be completely dependent on other countries to make their CPUs (national security, etc.). Whenever they use x86, they send money overseas — think of the response here if a gov’t agency wanted to spend millions on a national supercomputer that had made-in-China CPUs.

    Nevertheless, I agree that using SPARCs by itself isn’t an economically viable solution for large-scale HPC deployments, and that any CPU technology will have to be augmented with accelerators to achieve the desired performance within a sustainable power envelope.

  • Sumit Gupta

    Nathan

    The SPARC processors (SPARC64™ VIIIfx) that Fujitsu used the K Computer are custom designed for supercomputing.  In fact, this presentation from Fujitsu shows this processor as “HPC” (slide 2).   

    Fujitsu added lots of features for supercomputing, including very wide SIMD floating point units, large register files, etc.    Most of these are not too valuable for database operations.

    The real question is what is Fujitsu’s roadmap for this HPC SPARC processor?   Is there a follow-on?

  • Anonymous

    The Nov2011 Green500 table lists peak_MFLOPS/measured_watts.  That would be a more relevant comparison than total watts — smaller systems use fewer watts.  The Green 500 MFLOPS/watt  numbers are peak numbers measured during a LINPACK run.  For other programs, MFLOPS/watt can be very different, depending on how well the computational and communication needs of the program match the hardware available.  Tsubame and K are best for different classes of programs, optimal for a different balance of compute/message.