The dangers of a monoculture for the future of HPC

Print Friendly, PDF & Email

Joe Landman pointed to this presentation (PDF) by Paul Lu at U of Alberta on the emerging monocultures in HPC (x86, InfiniBand, Linux) and the risks posed by the elimination of diversity. It’s an interesting, easy read that will provoke thought.

Paul describes the current line of procurement reasoning that optimizes each purchase separate of all others and emphasizes price/performance above all else as knowing “the price of everything, but the value of nothing.” I could NOT agree with this more. He goes on (slide 37) to recommend that we take concrete steps (as in, on purpose) in procurements to ensure diversity in our community

  • But, if the cluster was, say, 10% smaller, will people actually notice?
  • So, leave room (and budget) as investment in diversity
    • For example, SMPs
      • Great for many applications now. They will get used
      • Develop expertise for multi/manycores in foreseeable future
    • For example, different OSes
      • Linux is great, but it is being pulled in many directions
      • Other code bases should not be abandoned

This is dead on. To this list I would add that we need to shave off a slice of funding for cycles and use it to fund more effective (eg, user interfaces) and more efficient (eg, programming models and computational support systems) mechanisms for delivering HPC services to users.


  1. CPU diversity is essential. But we still are focusing on the easiest thing to attack. More compute power! How many cycles do we throw away everyday because we aren’t investing enough in basic compiler development, code optimization or the biggest issue data movement. How much productivity and cpu cycles are loss in the current applications software companies licensing methodology?