Reflections on 30 years of HPC programming • Hacker News Board

Re: Reflections on 30 years of HPC programming

#21

Post by jkh1 » Fri, Apr 17, 2026, 9:43 AM UTC

jpecar wrote: post #10

jpecar wrote: post #8

All these fancy HPC languages are all nice and dandy, but the hard reality I see on our cluster is that most of the work is done in Python, R and even Perl and awk. MPI barely reached us and people still prefer huge single machines to proper distributed computing. Yeah, bioinformatics is from another planet.

To add on this, what I see gaining traction are "workflow managers", tools that let people specify flow of data through various tools. These can figure out how to parallelize things on their own so users are not burdened with this task. So from what I see actual programming language doesn't matter as much as how the work is organized. Anything helping people simplify this task is of immediate benefit to the science.

Most of the time in bio-related fields, we need high-throughput computing not high-performance computing.

Re: Reflections on 30 years of HPC programming

#22

Post by Joel_Mckay » Fri, Apr 17, 2026, 9:53 AM UTC

Narishma wrote: post #19

j4k0bfr wrote: post #9

Earlier quoted context omitted.

I'm pretty interested in realtime computing and didn't realise C++ was considered bandwidth efficient! Coming from C, I find myself avoiding most 'new' C++ features because I can't easily figure out how they allocate without grabbing a memory profiler.

I don't think there's much difference between C and C++ (and Rust, etc...) when it comes to this.

There is unless using a llvm compiler that does naive things with code motion.

Rust is typically slowest (often negligible Also, heavily associated with coding style =3

https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

Re: Reflections on 30 years of HPC programming

#23

Post by chinabot » Fri, Apr 17, 2026, 10:00 AM UTC

There has been a very big adoption of ENGLISH as a programming language in the last year or so, and, painful as it sounds, AI is already generating machine code without compilers, so let's see where we are in 2030.

Re: Reflections on 30 years of HPC programming

#24

Post by lugu » Fri, Apr 17, 2026, 10:08 AM UTC

bruce343434 wrote: post #7

jandrewrogers wrote: post #3

I can easily explain this, having worked in this space. The new languages don’t actually solve any urgent problems. How people imagine scalable parallelism works and how it actually works doesn’t have a lot of overlap. The code is often boringly single-threaded because that is optimal for performance. The single biggest resource limit in most HPC code is memory bandwidth. If you are not addressing this then you are n…

What does it mean to be friendly to memory bandwidth, and why does C++ excel at it, over, say, Fortran or C or Rust?

Parent talks about new languages, as per the article Fortran or C doing fine. I speculate the benefit of C++ over Rust how it let programmers instruct the compiler of warranty that goes beyong the initial semantic of the language. See __restrict, __builtin_prefetch and __builtin_assume_aligned. The programming language is a space for conversations between compiler builders and hardware designers.

Re: Reflections on 30 years of HPC programming

#25

Post by RhysU » Fri, Apr 17, 2026, 10:09 AM UTC

> we have failed to broadly adopt any new compiled programming languages for HPC

The article neglects that all of C, C++, and Fortran have evolved over the last 30 years.

Also, you'll find significant advances in the HPC library ecosystem over the trailing years. Consider, for example, Trilinos (https://trilinos.github.io/index.html) or Dakota (https://dakota.sandia.gov/about-dakota/) both of which push a ton of domain-agnostic capabilities into a C++ library instead of bolting them into a bespoke language. Communities of users tend to coalesce around shared libraries not creating new languages.

Re: Reflections on 30 years of HPC programming

#26

Post by JohnWabwire » Fri, Apr 17, 2026, 10:12 AM UTC

jpecar wrote: post #10

jpecar wrote: post #8

All these fancy HPC languages are all nice and dandy, but the hard reality I see on our cluster is that most of the work is done in Python, R and even Perl and awk. MPI barely reached us and people still prefer huge single machines to proper distributed computing. Yeah, bioinformatics is from another planet.

To add on this, what I see gaining traction are "workflow managers", tools that let people specify flow of data through various tools. These can figure out how to parallelize things on their own so users are not burdened with this task. So from what I see actual programming language doesn't matter as much as how the work is organized. Anything helping people simplify this task is of immediate benefit to the science.

[dead]

Re: Reflections on 30 years of HPC programming

#27

Post by anewhnaccount2 » Fri, Apr 17, 2026, 10:29 AM UTC

crabbone wrote: post #18

As someone who worked for a while and still works in HPC, my impression from this field as compared to eg. programming in finance sector or programming for storage sector is that... HPC is so backwards and far behind, it's really amazing how it's portrayed as some sort of a champion of the field. That's not to say that new things don't happen there, it's just that I find a lot of old stuff that was shown to be bad de…

How should it be better? Most environments offer Apptainer which can import Docker containers. Plus a lot of theae languages like Julia and Chapel are pretty self contained and programmed against eg ancient libc for these very reasons.

Re: Reflections on 30 years of HPC programming

#28

Post by suuuuuuuu » Fri, Apr 17, 2026, 10:37 AM UTC

jandrewrogers wrote: post #3

I can easily explain this, having worked in this space. The new languages don’t actually solve any urgent problems. How people imagine scalable parallelism works and how it actually works doesn’t have a lot of overlap. The code is often boringly single-threaded because that is optimal for performance. The single biggest resource limit in most HPC code is memory bandwidth. If you are not addressing this then you are n…

If you think C++ is the best here, then I don't think you've actually worked in this space nor appreciated the actual problems these languages try to solve. In particular because you can't program accelerators with C++.

Memory bandwidth is often the problem, yes. Language abstractions for performance aim to, e.g., automatically manage caches (that must be handled manually in performant GPU code, for instance) with optimized memory tiling and other strategies. Kernel fusion is another nontrivial example that improves effective bandwidth.

Adding on the diversity of hardware that one needs to target (both within and among vendors), i.e., portability not just of function but of performance, makes the need for better tooling abundantly obvious. C++ isn't even an entrant in this space.

Re: Reflections on 30 years of HPC programming

#29

Post by _flux » Fri, Apr 17, 2026, 10:59 AM UTC

lugu wrote: post #24

bruce343434 wrote: post #7

Earlier quoted context omitted.

What does it mean to be friendly to memory bandwidth, and why does C++ excel at it, over, say, Fortran or C or Rust?

Parent talks about new languages, as per the article Fortran or C doing fine. I speculate the benefit of C++ over Rust how it let programmers instruct the compiler of warranty that goes beyong the initial semantic of the language. See __restrict, __builtin_prefetch and __builtin_assume_aligned. The programming language is a space for conversations between compiler builders and hardware designers.

I believe __restrict, and __builtin_prefetch/__builtin_assume are compiler extensions, not part of the C++ language as is, and different compilers implement (or don't) these differently.

The rust compiler actually has similar things, but they're not available in stable builds. I suppose there are some issues if principle why not to include them in stable. E.g: https://doc.rust-lang.org/std/intrinsics/fn.prefetch_read_da...

Maybe some time in the future good acceptable abstractions will be conceived for them.. Perhaps using just using nightly builds for HPC is not that far out, though.

Re: Reflections on 30 years of HPC programming

#30

Post by pama » Fri, Apr 17, 2026, 11:07 AM UTC

crabbone wrote: post #18

As someone who worked for a while and still works in HPC, my impression from this field as compared to eg. programming in finance sector or programming for storage sector is that... HPC is so backwards and far behind, it's really amazing how it's portrayed as some sort of a champion of the field. That's not to say that new things don't happen there, it's just that I find a lot of old stuff that was shown to be bad de…

HPCs never loved the inefficiencies of anything virtualized (VMs or any containers really), so the shell hacks of module enabled a (limited, but workable) level of reproducibility that was sufficiently composable and usable by researchers who understood the shell. I am not going to defend this tcl hack any further, but I can see how it was the path of least resistance when people tried to stay close to the raw metal of their large clusters while keeping some level of sanity. Slurm is a more defensible choice, but I agree that these tools are from a different era of compute. I grew to love and hate these tools, but they definitely represent an acquired taste, like a dorian fruit; not like an apple.

Your centos6 references made me chuckle :-)