Reflections on 30 years of HPC programming • Hacker News Board

Re: Reflections on 30 years of HPC programming

#91

Post by bch » Fri, Apr 17, 2026, 7:26 PM UTC

GuB-42 wrote: post #88

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.

C++ is like C with extra features, but you don't need to use them. If you want control over your memory, you can do pointers the C way, but you still have features like templates, namespaces, etc... Another advantage of C++ is that it can go both high and low level within the same language. Disadvantage of C++ is mostly related to portability and interop. Things like name mangling, constructors, etc... can be a probl…

> C++ is like C with extra features, but you don't need to use them

C++ certainly (literally (Cfront[0])) used to be this, but I thought modern (decade or more) conventional wisdom is to NOT think like this anymore. Curious to hear others weigh in.

[0] https://en.wikipedia.org/wiki/Cfront

Re: Reflections on 30 years of HPC programming

#92

Post by Fronzie » Fri, Apr 17, 2026, 7:41 PM UTC

iamcreasy wrote: post #90

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…

Julia language is also used for HPC according to their webpage citing performance parity with C++. Would it be correct to infer Julia also provides the same level of memory bandwidth control?

It's close, but not quite. Getting it to do 'y = ax + by' like vector operations without superfluous reads/writes is tricky.

Re: Reflections on 30 years of HPC programming

#93

Post by rirze » Fri, Apr 17, 2026, 7:51 PM UTC

ivell wrote: post #38

I think Mojo has a good chance to become suitable for HPC.

I don't understand why people are so excited for Mojo. I don't get the impression it will replace anything but computational scripting that was done previously in Python.

HPC is a different beast as far as I'm aware.

Re: Reflections on 30 years of HPC programming

#94

Post by rirze » Fri, Apr 17, 2026, 7:53 PM 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…

It's been years since I last used `slurm`. Thanks for the blast from the past.

Re: Reflections on 30 years of HPC programming

#95

Post by GuB-42 » Fri, Apr 17, 2026, 8:01 PM UTC

bch wrote: post #91

GuB-42 wrote: post #88

Earlier quoted context omitted.

C++ is like C with extra features, but you don't need to use them. If you want control over your memory, you can do pointers the C way, but you still have features like templates, namespaces, etc... Another advantage of C++ is that it can go both high and low level within the same language. Disadvantage of C++ is mostly related to portability and interop. Things like name mangling, constructors, etc... can be a probl…

> C++ is like C with extra features, but you don't need to use them C++ certainly (literally (Cfront[0])) used to be this, but I thought modern (decade or more) conventional wisdom is to NOT think like this anymore. Curious to hear others weigh in. [0] https://en.wikipedia.org/wiki/Cfront

To me, it is not "conventional wisdom", it is what a vocal group of C++ guys who look at Rust and its memory safety and don't want to be left out.

Their way is not wrong, new constructs are indeed safer, more powerful, etc... But if you are only in for the new stuff, why use C++ at all, you are probably better off with Rust or something more modern. The strength of C++ is that it can do everything, including C, there is no "right" way to use it. If you need raw pointers, use raw pointers, if you need the fancy constructs the STL provides, use them, these are all supported features of the language, don't let someone else who may be working in a completely different field tell you that you shouldn't use them.

Re: Reflections on 30 years of HPC programming

#96

Post by convolvatron » Fri, Apr 17, 2026, 8:17 PM UTC

rirze wrote: post #93

ivell wrote: post #38

I think Mojo has a good chance to become suitable for HPC.

I don't understand why people are so excited for Mojo. I don't get the impression it will replace anything but computational scripting that was done previously in Python. HPC is a different beast as far as I'm aware.

I don't think that's accurate. Mojo is explicitly compiling tensor graphs that run on accelerators. it's not like PyTorch where python is providing the chassis but not the engine.

I don't think its going to be a good general HPC language just because its targeting a specific set of AI workloads, but they have shown some examples of synthesizing code which is comparable to hand-written kernels.

but its not out of the question from first principles

Re: Reflections on 30 years of HPC programming

#97

Post by SiempreViernes » Fri, Apr 17, 2026, 8:19 PM UTC

bradcray wrote: post #83

SiempreViernes wrote: post #74

Earlier quoted context omitted.

The fact that the author is a developer of Chapel pretty neatly explains why "no new language was adopted" is valued as failure, the article itself makes little effort to argue for that value judgment.

Author here: I didn't go into more detail on this than https://chapel-lang.org/blog/posts/30years/#maybe-hpc-doesnt... because I felt like the article was long enough already and that I'd recently covered that topic in detail in this series https://chapel-lang.org/blog/series/10-myths-about-scalable-... summarized here https://chapel-lang.org/blog/posts/10myths-part8/#summary

In the "maybe we don't need it" you open up with this:

> Another explanation might be that HPC doesn’t really need new languages; that Fortran, C, and C++ are somehow optimal choices for HPC. But this is hard to take very seriously given some of the languages’ demerits

It's honestly hard to think of a less specific claim than "some of [their] demerits", this is clearly preaching to the choir territory. Later hints of substance appear, but the text is merely reminding the reader of something they are expected to already know.

Moving on, the summary for the "ten myths" series starts with:

> I wrote a series of eight blog posts entitled “Myths About Scalable Parallel Programming Languages” [...] In it, I described discouraging attitudes that our team encountered when talking about developing Chapel, and then gave my personal rebuttals to them.

So it appears to be a text about the trouble of trying to break through with a new "HPC" language, and the reader is again expected to already know the (potentially very good) technical reasons for why one would want to create a new one.

Re: Reflections on 30 years of HPC programming

#98

Post by grg0 » Fri, Apr 17, 2026, 9:23 PM 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?

I'd say it's being able to structure your data however suits your problem and your hardware, then being able to look at a profile and being able to map read/writes back to source. Both C and C++ excel at this.

The advantage of C++ over C is that, with care, you can write zero-cost abstractions over whatever mess your data ends up as, and make the API still look intuitive. C isn't as good here.

Re: Reflections on 30 years of HPC programming

#99

Post by grg0 » Fri, Apr 17, 2026, 9:27 PM UTC

j4k0bfr wrote: post #9

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…

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.

C++ comes with baggage and requires up-front training. You need to dive into every language feature and STL library, learn how compilers implement stuff, then decide what to use and what not to, and the decision often depends on context. It has a high cognitive load in my opinion for that reason. But once you do that, you get a relatively high-level language that can go as low and be as fast as C.

Re: Reflections on 30 years of HPC programming

#100

Post by nine_k » Fri, Apr 17, 2026, 9:50 PM UTC

grg0 wrote: post #98

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?

I'd say it's being able to structure your data however suits your problem and your hardware, then being able to look at a profile and being able to map read/writes back to source. Both C and C++ excel at this. The advantage of C++ over C is that, with care, you can write zero-cost abstractions over whatever mess your data ends up as, and make the API still look intuitive. C isn't as good here.

Is Fortran 90 not flexible enough in defining data layout?