Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on 30 years of HPC programming

chapel-lang.org

Post reply on HN
Print view View original

41–50 of 129 posts

Re: Reflections on 30 years of HPC programming

#41

Post by pklausler »

Honestly, if a language can't succeed in HPC alongside (or against) Fortran with its glacial rate of buggy evolution and poor track record of portability, and C++ with its never-ending attempts at parallelism, then it's not what HPC needs.

(What HPC does need, IMNSHO, is to disband or disregard WG5/J3, get people who know what they're doing to fix the features they've botched or neglected for thirty years, and then have new procurements include RFCs that demand the fixed portable Fortran from system integrators rather than the ISO "standard".)

Re: Reflections on 30 years of HPC programming

#42

Post by Joeboy »

kmaitreys wrote: post #39
formerly_proven wrote: post #37

Earlier quoted context omitted.

Idiomatic/natural rust tends to be a lot heavier on allocations and also physically moving objects around than the other two.

Can you elaborate on this? Slightly concerned because I have written (and planning to write more) Rust HPC code

Maybe not what they meant, but Rust sometimes makes it tempting to just copy things rather than fighting the borrow checker. Whereas in C++ you're free to just pass pointers around and not worry about it until / unless your code crashes or gets exploited.

Speaking authoritatively from my position as an incompetent C++ / Rust dev.

Re: Reflections on 30 years of HPC programming

#43

Post by zozbot234 »

kmaitreys wrote: post #39
formerly_proven wrote: post #37

Earlier quoted context omitted.

Idiomatic/natural rust tends to be a lot heavier on allocations and also physically moving objects around than the other two.

Can you elaborate on this? Slightly concerned because I have written (and planning to write more) Rust HPC code

Stable Rust doesn't have a local allocator construct yet, you can only change the global allocator or use a separate crate to provide a local equivalent.

Re: Reflections on 30 years of HPC programming

#44

Post by zozbot234 »

jltsiren wrote: post #14
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.

Bioinformatics is an outlier within HPC. It's less about numerical computing and more about processing string data with weird algorithms and data structures that are rarely used anywhere else. Distributed computing never really took off in bioinformatics, because most tasks are conveniently small. For example, a human genome is small enough that you can run most tasks involving a single genome on an average cost-effe…

Bioinformatics is also seeing huge gains from rewriting the slow Python code into highly parallel Rust (way less fiddly than C++ for the typical academic dev).

Re: Reflections on 30 years of HPC programming

#45

Post by zozbot234 »

pama wrote: post #30
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…

Containers are an OS sandboxing/namespacing primitive, they don't involve any overhead on their own. The overhead is dependent on what's inside the container besides a single deployed binary.

Re: Reflections on 30 years of HPC programming

#46

Post by [deleted] »

pjmlp wrote: post #36
RhysU wrote: post #25

> 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…

The authors are aware, as the Chapel compiler makes use of LLVM.

[deleted]

Re: Reflections on 30 years of HPC programming

#47

Post by RhysU »

pjmlp wrote: post #36
RhysU wrote: post #25

> 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…

The authors are aware, as the Chapel compiler makes use of LLVM.

The author's framing "we have failed" suggests otherwise.

This section, https://chapel-lang.org/blog/posts/30years/#ok-then-why, does not mention libraries at all.

Re: Reflections on 30 years of HPC programming

#48

Post by j4k0bfr »

Joel_Mckay wrote: post #12
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.

> realtime computing Even with HDL defined accelerators, that statement may not mean what people assume. =3 https://en.wikipedia.org/wiki/Latency_(engineering) https://en.wikipedia.org/wiki/Clock_domain_crossing https://en.wikipedia.org/wiki/Metastability_(electronics) https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev... https://www.youtube.com/watch?v=G2y8Sx4B2Sk

I'm talking almost exactly about this haha. Flight software representation!! Although I have no experience programming FPGAs, I hope to gain some soon. They seem like the ultimate solution to my IO woes.

Re: Reflections on 30 years of HPC programming

#49

Post by Joel_Mckay »

j4k0bfr wrote: post #48
Joel_Mckay wrote: post #12

Earlier quoted context omitted.

> realtime computing Even with HDL defined accelerators, that statement may not mean what people assume. =3 https://en.wikipedia.org/wiki/Latency_(engineering) https://en.wikipedia.org/wiki/Clock_domain_crossing https://en.wikipedia.org/wiki/Metastability_(electronics) https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev... https://www.youtube.com/watch?v=G2y8Sx4B2Sk

I'm talking almost exactly about this haha. Flight software representation!! Although I have no experience programming FPGAs, I hope to gain some soon. They seem like the ultimate solution to my IO woes.

A bit legacy these days, but I liked the old Zynq 7020 dual core ARM with reasonable LUT counts.

https://www.youtube.com/watch?v=FujoiUMhRdQ

https://github.com/Spyros-2501/Z-turn-Board-V2-Diary

https://www.youtube.com/@TheDevelopmentChannel/playlists

https://myirtech.com/list.asp?id=708

The Debian Linux example includes how to interface hardware ports.

Almost always better to go with a simpler mcu if one can get away with it. Best of luck =3

Re: Reflections on 30 years of HPC programming

#50

Post by jacquesm »

Joel_Mckay wrote: post #20
jacquesm wrote: post #16

Earlier quoted context omitted.

That will never happen. The overhead is massive.

People did try to create an OTP in HDL at one point. And Erlang has already run many telecom infrastructures for decades. Surprising given how fragile the multi-host implementation has proven. Erlang/Elixir are neat languages, and right next to Julia for fun. =3

Yes, it's absolutely amazing. But I'm intimately familiar with how the Erlang VM works and it would seem to me to be a very bad match for HPC on the number crunching side, though it likely would do quite well on the orchestration side but that would require the people writing the rest of the code to change their way of working completely. And given how much of that is still F77 I highly doubt they would be willing to make that investment without the promise of some massive gain.
Post reply on HN