Live data from Hacker News

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

octarineparrot.com

51–60 of 65 posts

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

#51
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.

> Most of the big HPC projects today are written in C++

My experience is limited to one single field, but all weather prediction models and climate models that I know of, are in Fortran. And I would count them as big HPC projects.

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

#52

GitHub repo with all of the code: https://github.com/mrfloya/thesis-ba Most interesting part of the thesis, for me, is page 42: > In this case it was even an advantage that the Rust version was developed last since it revealed a critical error in the other implementations. Null strikes again!

He would have found the problem in Go too if he was using the comma-ok form:

    n1_idx, ok1 := g.nodeIdx[n1]
    n2_idx, ok2 := g.nodeIdx[n2]
    if !ok1 || !ok2 {
When you do not use the comma-ok form, you are specifically asking the map to return the zero value for non initialized elements (which is something fine to do in many cases).

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

#54
post #27
post #19

Earlier quoted context omitted.

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

I do not think free finite element libraries are representative of commercial software. They usually include a mix of different languages, and that includes lots of Fortran, which is used both in the core (in solvers and linear algebra libraries, for example) and at the highest level for user subroutines. I have seen people using either Fortran or C++ with Abaqus, LS-Dyna or MSC, but nobody writting C (except for some very experimental solvers).

Most users are usually fine with whatever the GUI allows and a bit of Python, but for those of us developing new models, Fortran is probably the most useful language, followed by C++.

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

#55
post #48
post #33

Earlier quoted context omitted.

Yes, because the point is being able to write (on a resume): successfully presented thesis on "Evaluation of C, Go, and Rust in the HPC environment". The advisors should have encouraged a smaller and more manageable scope with a more thorough methodology where the results would actually be worth something.

The goal is for the student to get some experience with performing their own research wherever that may lead them. This is actually a pretty impressive piece of independent work for an undergrad.

> The goal is for the student to get some experience with performing their own research wherever that may lead them.

You mean it has nothing to do with learning correct methodology or actually doing real research?

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

#56
post #39
post #11

The problem with reading this in BS thesis form is that it hasn't gone through the wringer enough. Most of the performance comparison results vs C are bogus because (to its credit, as noted), the author accidentally compiled some important support libraries for the C version without optimization and used those on the cluster. Oopsie. As briefly mentioned in the previous chapter this performance regression might have…

Hey author of the thesis here. You are correct this was definitely an oversight and I would have redone the measurements if time allowed for it. However I just want to state that the libaries were built with optimizations just not on the target platform which might not have been clear from the qoute.

Hope the HN experience hasn't felt too bruising. The use of go and rust makes it quite interesting for those of us interested in correct code, not just fast code. And most of the criticism is that you didn't write the paper the commenter would have wanted to see, or didn't write a graduate level paper. And good on you for publishing it on github.

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

#57
post #55
post #48

Earlier quoted context omitted.

The goal is for the student to get some experience with performing their own research wherever that may lead them. This is actually a pretty impressive piece of independent work for an undergrad.

> The goal is for the student to get some experience with performing their own research wherever that may lead them. You mean it has nothing to do with learning correct methodology or actually doing real research?

"Correct methodology" and "real research" are very subjective things. We often judge too harshly, and as long as the paper is not misleading, you can judge it's merits directly without resorting to non-science.

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

#58
post #55

Earlier quoted context omitted.

> The goal is for the student to get some experience with performing their own research wherever that may lead them. You mean it has nothing to do with learning correct methodology or actually doing real research?

"Correct methodology" and "real research" are very subjective things. We often judge too harshly, and as long as the paper is not misleading, you can judge it's merits directly without resorting to non-science.

> "Correct methodology" and "real research" are very subjective things.

That's exactly the attitude emblematic of the portion of academics producing worthless output.

Here is a recent reference: http://www.nature.com/news/psychology-journal-bans-p-values-...

Not a methodological problem?

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

#59
post #58

Earlier quoted context omitted.

"Correct methodology" and "real research" are very subjective things. We often judge too harshly, and as long as the paper is not misleading, you can judge it's merits directly without resorting to non-science.

> "Correct methodology" and "real research" are very subjective things. That's exactly the attitude emblematic of the portion of academics producing worthless output. Here is a recent reference: http://www.nature.com/news/psychology-journal-bans-p-values-... Not a methodological problem?

Peer review should sort out the bad science from the good. The above link is just laziness: they have correlated P values with low quality research, and have decided to use it as a crap filter in leu of better, but more expensive, peer review.

The article submitted was not peer reviewed, and could very well be bad science, but I think accusations of non-science are not very productive and do not provide feedback in how to do better.

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

#60
post #52

GitHub repo with all of the code: https://github.com/mrfloya/thesis-ba Most interesting part of the thesis, for me, is page 42: > In this case it was even an advantage that the Rust version was developed last since it revealed a critical error in the other implementations. Null strikes again!

He would have found the problem in Go too if he was using the comma-ok form: n1_idx, ok1 := g.nodeIdx[n1] n2_idx, ok2 := g.nodeIdx[n2] if !ok1 || !ok2 { When you do not use the comma-ok form, you are specifically asking the map to return the zero value for non initialized elements (which is something fine to do in many cases).

Well, you're implicitely asking for it. In Rust you have to explicitely specify your intent, i.e. not by omitting something, but rather by specifying that you want to ignore it.
Post reply on HN