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

Evaluation of C, Go, and Rust in the HPC environment [pdf]

octarineparrot.com

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#21

Post by steveklabnik »

madez wrote: post #20
steveklabnik wrote: post #13

Earlier quoted context omitted.

> Would love to hear from a Rust contributor why that is and what's being scheduled to be done about it. I haven't spent time with the code yet, so I can't comment. It shouldn't be the runtime, though, as our runtime is about as big as C or C++'s. My first thought would be that Vec's growth factor may be poor in this instance, but without reading the code, who knows. > Rust is... ?? Rust statically links everything b…

I read more than once that rust has no runtime. Could you please clarify whether it has a runime, and if it does, what it consists of?

So, basically _every_ non-assembly programming language has a runtime. Even C and C++. But not all runtimes are created equal. Languages like C, C++, and Rust have a very minimal, no setup required runtime. Other, higher level languages often have something significantly more heavy. People will sometimes say "no runtime" to mean the class of languages which have very small runtimes.

Rust's runtime is here: https://github.com/rust-lang/rust/tree/master/src/rt and https://github.com/rust-lang/rust/tree/master/src/libstd/rt

As you can see, it's very, very small. It mostly handles things like unwinding, at_exit handlers, and the like.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#23

Post by dibanez »

Well, Go and Rust can do better threading on this problem than a not-really-optimized C code with OpenMP. Thats a start. Message passing has to be shown next, and then one can decide whether the installation and runtime of Go/Rust/Python/Julia on something like an IBM Blue Gene/Q with its custom compute node OS is easier than a link flag.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#24

Post by physguy1123 »

buster wrote: post #19
drwells wrote: post #17

My biggest criticism of this work is that it does not consider C++. Most of the big HPC projects today are written in C++, not C, and to the best of my knowledge this transition happened in the 90s.

Not Fortran?

There is still a lot of Fortran being written, but a lot of it is on legacy projects (scientific codes have a habit of lasting a long time). While there are some cool things like coarray Fortran and some groups require that everything be done in Fortran, C++ is a favorite for new projects afaik.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#25

Post by steveklabnik »

pnathan wrote: post #16
steveklabnik wrote: post #13

Earlier quoted context omitted.

> Would love to hear from a Rust contributor why that is and what's being scheduled to be done about it. I haven't spent time with the code yet, so I can't comment. It shouldn't be the runtime, though, as our runtime is about as big as C or C++'s. My first thought would be that Vec's growth factor may be poor in this instance, but without reading the code, who knows. > Rust is... ?? Rust statically links everything b…

Oh, cool! Thanks for the information!

No problem. Doing a valgrind run on the sample, let's see how it goes.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#26

Post by hurin »

pnathan wrote: post #15
bsdetector wrote: post #10

The author has a "lack of equal experience in the three evaluated languages", especially C, but is comparing them for development time and SLOC based on a sample size of one developer and one very small program. He rewrites a distributed program as a threaded one, because Rust and Go didn't have a distributed computing library, but says Go and Rust have "similar performance" in HPC. He says he was surprised at the C…

pretty sure all programs were multithreaded. I do agree that the advisor should have pushed back lots harder on the methods; it's a weak paper, even as an experience report.

> I do agree that the advisor should have pushed back lots harder on the methods; it's a weak paper, even as an experience report.

I agree - this seems to be mostly the advisors fault, by the looks of it it's not that the student didn't put a lot of work into it but methodological problems are what advisors are supposed to be there to address; I saw a lot of this back in college, at least with technical papers it's easy to tell what's wrong, with the humanities it's just a complete disaster.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#27

Post by drwells »

buster wrote: post #19
drwells wrote: post #17

My biggest criticism of this work is that it does not consider C++. Most of the big HPC projects today are written in C++, not C, and to the best of my knowledge this transition happened in the 90s.

Not Fortran?

I have not done a census of the various libraries around, but all of the free finite element libraries in common use (deal.II, libmesh, and FEnICs come to mind first) are written in C++. I suspect Fluent and Abaqus are written in C (maybe Fortran?) but they are a bit older.

Trilinos is another C++ example, while PETSc and HYPRE are written in C.

My tentative conclusion from this is that newer projects tend to use C++ and slightly older projects use C.

Yes, there are things like ODEPACK, QUADPACK, and FFTPACK, but those are not under development anymore (as far as I know). The only widely used Fortran library still under development I can think of is LAPACK.

I did not count the occasional 'bespoke' code. There are still some Fortran applications in development for particular purposes (like MOM), but those are harder to survey.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#28

Post by istvan__ »

bsdetector wrote: post #10

The author has a "lack of equal experience in the three evaluated languages", especially C, but is comparing them for development time and SLOC based on a sample size of one developer and one very small program. He rewrites a distributed program as a threaded one, because Rust and Go didn't have a distributed computing library, but says Go and Rust have "similar performance" in HPC. He says he was surprised at the C…

I agree with your assessment only thing I did not understand is the Erlang integration with other languages. I am not sure if he is saying that NIFs are bad or he is saying there are is not support for other languages. I think non of these are true...

http://www.erlang.org/doc/tutorial/introduction.html http://www.erlang.org/doc/tutorial/nif.html#id64792

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#29

Post by chrisseaton »

physguy1123 wrote: post #24
buster wrote: post #19

Earlier quoted context omitted.

Not Fortran?

There is still a lot of Fortran being written, but a lot of it is on legacy projects (scientific codes have a habit of lasting a long time). While there are some cool things like coarray Fortran and some groups require that everything be done in Fortran, C++ is a favorite for new projects afaik.

Why do scientists call programs 'codes'? It's something that seems to be particularly common in HPC, and quite rare elsewhere.

Re: Evaluation of C, Go, and Rust in the HPC environment [pdf]

#30

Post by Dewie3 »

bsdetector wrote: post #10

The author has a "lack of equal experience in the three evaluated languages", especially C, but is comparing them for development time and SLOC based on a sample size of one developer and one very small program. He rewrites a distributed program as a threaded one, because Rust and Go didn't have a distributed computing library, but says Go and Rust have "similar performance" in HPC. He says he was surprised at the C…

It's a bachelor thesis... probably doesn't aspire to be the new authority on HPC. :)
Post reply on HN