TOP500 Supers make boffins more prolific A comparative analysis of supercomputer ownership by US universities seems to suggest that TOP500-class iron gives institutions a quantifiable edge in physics, chemistry, civil engineering and evolutionary biology. In the kind of rational decision-making that will upset HPC sales teams, the Clemson University research is …
The paper has nothing to do with supposed "research efficiency" increases due to Top 500 supercomputers -- it's really a well-disguised stupidity test. Anyone not realizing that the paper's experimental design of "correlation must imply cause" is silly will score quite high on any Dumbotron testing device.
on the other hand, having a supercomputer to do simulations before you try something In Real Life, can save a lot of time when you are trying to finish a PhD before you die of starvation or give up out of frustration when your research experiments won't work
Have you read the paper? I haven't - $40 is more than I feel like paying for it, and since I'm not teaching this semester I don't have online access via the university library - but I'm just a little suspicious of random idiots on the Internet denouncing work they haven't read.
Universities with strong research activities in relevant areas can justify and afford supercomputers
But not all do. And this is precisely the kind of data you'd use to see whether a Top500 system is, in fact, justified.
Really, the feebleness of the comments on this story is surprising even for the Internet.
But you will probably find that programs written by chemists to solve chemical problems are more effective than those written to solve the same problem by computer scientists, because chemists understand the problem, rather than the computer scientists who may write better code, but don't understand the problem they are trying to solve.
"But you will probably find that programs written by chemists to solve chemical ...."
In science it's often the case. Trying to explain some arcane point with lots of caveats to a programmer without a serious grounding in the topic can be frustrating, and usually leads to a poor outcome. Not the programmer's fault of course just difficult to comunicate between the worlds.
Incidently whilst I agree that many scientists can be poor programmers two of the best coders I've every worked with were originally chemists.
I was writing in the present tense, so I was commenting on what I've seen, not on what should be done.
But I seriously doubt that you are correct. If you get some computer scientist on board, they will want to write in something like Python if they've just coded as part of their degree, C++, Java, or derivatives if they've been taught formal programming languages, or something obscure like Haskill or Erlang if they are working in the field of functionally correct programs.
Like it or not, writing efficient HPC code is still best done in a relatively simple language like Fortran, because you can get so close to the machine code actually being executed that if necessary you can tweak it at the assembler level to wring out the last few clock cycles in critical parts of the code. Depending on which HPC segment you're looking at, owning an HPC is normally not just about running your code fast, it's about running it as fast as you possibly can.
Don't believe any hype that for this type of programming, an IDE is ever going to generate more efficient code than something closer to the bare metal, And I don't think that you will get any Computer Scientist seriously considering Fortran as a language to work in, unless they are already involved in the HPC field.
I am involved in the field myself at the moment (as a mere system admin), and I talk to people involved in solving big problems using HPCs, and this is what I am told by people actively writing for such systems.
But I seriously doubt that you are correct.
This entire thread is idle speculation with no real evidence offered for any position. But then I suppose when you're dealing with banal generalities like "people in field X will write better code", there's no point in trying to make a real argument.
Like it or not, writing efficient HPC code is still best done in a relatively simple language like Fortran, because you can get so close to the machine code
Some actual research shows otherwise. See the June 2014 issue of CACM, for example, for a paper demonstrating how deep EDSLs can produce more-efficient code than hand-written C or Fortran for certain HPC tasks, in part because they can do higher-order optimization.
The "close to the metal" myth has been thoroughly debunked time and time again. Humans aren't good at predicting how modern systems will behave. They often make erroneous evaluations of the effects of caching, branch prediction, speculative execution, etc. There was a good piece a dozen years ago in DDJ about optimizing a hand-written assembler rendering package on x86, where at one point the author enlisted Intel's help in figuring out why a linear search consistently outperformed a binary search - CPU traces showed it was the branch-prediction effects. Or see this piece on cache effects.
Meanwhile, languages specifically designed for HPC, like Julia, often produce code that's just as efficient as anything done in Fortran. And, of course, any optimization outside the inner loops probably won't matter (by Amdahl's Law), so writing the entire application (as opposed to just the time-critical routines) in Fortran doesn't offer any performance advantage.
The main advantage of Fortran for scientific computing is the vast corpus of extant legacy code, and the community of scientific-computing programmers who know the language.
I appreciate the information, and I put my cards on the table. I am only talking generalisations here as I am not an HPC coder myself, but I do know several people doing serious work on existing HPC environments.
They obviously have time and effort invested in the existing systems and the languages that they currently use, but many times I have seen these people working at the generated machine code levels trying to sort out bit comparison errors, and convergence errors in large HPC programs.
The fact that they don't have layers of code generation and optimisation tools between the code being executed and the source language is a real benefit. These are people who care enough about the code and the specific machine they are working on to successfully manually unroll loops and other hand-hacks in order to reduce execution time.
Reading up on one of the examples you quote for efficient code generation, I find that Julia is still pretty immature for the largest problems out there. If you look at top 100 supercomputers, it is essential that you have a message passing paradigm that scales across multiple machine images.
The standard currently being used is MPI, although OpenMP and MPICH are alternatives that the likes of Cray and IBM are supporting. These are very important because of the need to be integrated with the interconnect in these systems.
I came across a recent thread (still going on) on Google Groups that is a discussion between various people associated with Julia about how to get it working with MPI and the problems they are having. This means that although Julia may be suitable for generating efficient code, it's still very immature for everything that does not use a shared memory model visible to all threads.
I found a quote from an article on ArsTechnica from just under a year ago where the team that created and is developing Julia—namely Stefan Karpinski, Viral Shah, Jeff Bezanson, and Alan Edelman said:
"Our general goal is not to be worse than 2x slower than C or Fortran"
So while you have very valid points, the consensus at the moment is that Fortran (and to a lesser extent C++) is and will remain for some time the preferred language for the largest real problems in the HPC world.
I think more information you can find on Wiki. I agree with "As the price, performance and energy efficiency of general purpose graphic processors (GPGPUs) have improved, a number of petaFLOPS supercomputers such as Tianhe-I and Nebulae have started to rely on them." Source: https://en.wikipedia.org/wiki/Supercomputer#History
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
