"In times where compilers are smart enough to basically rewrite and change code for performance reasons it is completely inexcusable that the order of source arguments to process is still that relevant." After reading the comments on C and the difficulties the author had in the compilation process.... All I can say is Garbage in garbage out. I have worked in the HPC enviornment for a number of years using both Fortra…
Fortrash
Why the hate? One could misuse any tool, but that doesn't make the tool bad at what it does.
"In times where compilers are smart enough to basically rewrite and change code for performance reasons it is completely inexcusable that the order of source arguments to process is still that relevant." After reading the comments on C and the difficulties the author had in the compilation process.... All I can say is Garbage in garbage out. I have worked in the HPC enviornment for a number of years using both Fortra…
Fortrash Why the hate? One could misuse any tool, but that doesn't make the tool bad at what it does.
I don't disagree. Fortran is brilliant at what it does.... but I find many of its object oriented features to be very obtuse compared to C and C++. The way it uses pointers drives me insane. Building certain datastructures in fortran just takes too much time.
I kind of wish I could find a good way to make Fortran and C play nicely together. (There are some compiler dependent peculiarities that I have encountered that make it difficult.)
Fortran's intrisics and file handling capabilities make it indispensable in the work I do.... So it is really a love hate relationship.
Any HPC language evaluation that doesn't include vs FORTRAN is pointless. It's still king of computation for a reason.
Experiments aren't usually written in FORTRAN. The programmer is by far the slowest part of HPC. It often makes sense to use the language you're fastest at instead of the language that will run the fastest. It's very common for experiments to be written in languages not know for their performance (Java, Matlab, Perl, and Python for instance). For reference, here are some of the packages commonly used in experiments[1…
The list is not just skewed toward bioinformatics; a majority of them is bioinformatics software. I would not call BioPerl or HTSeq high-performance-computing software. Some of the software are written by academic programmers with all attendant baggages. I am not aware of any bioinformatics software written in Fortran, which is not popular in the bioinformatics community. But this is not to say Fortran might not be a good fit. The Broad Institute is rewriting some of its tools in C++ with help from Intel to leverage vector instructions. Who is to say if they had started with Fortran they might not have gotten vector instructions for free earlier.
Wildly offtopic- reading papers like this bring to mind for some reason, that the next evolution of CPython, the one that deals with the Python2/3 rift should be written in Rust.
Looking through the links, and methodology makes me question a lot of things, most of them regarding his choices in how he allocated memory. First and foremost, he was using the glibc malloc, which belongs in a museum, not in a running system. One of rust's big advantages in performance comes from that alone, given all the memory that's being allocated and destroyed. Which leads to the second question of how he did allocate objects. He knew he was going to allocate a number of objects, yet he didn't pre-allocate a large chunk of memory ahead of time to make it so he wouldn't have to call malloc and friends as often. I wouldn't be surprised if spending a bit of time just tuning memory didn't cut significant time from how long execution takes. I really wonder how much time was spent in the system context of all three of those; I'd be willing to bet that the final part of the examination would probably fare much different had he used the same malloc for the C program that rust and go already use.
Fortrash Why the hate? One could misuse any tool, but that doesn't make the tool bad at what it does.
I don't disagree. Fortran is brilliant at what it does.... but I find many of its object oriented features to be very obtuse compared to C and C++. The way it uses pointers drives me insane. Building certain datastructures in fortran just takes too much time. I kind of wish I could find a good way to make Fortran and C play nicely together. (There are some compiler dependent peculiarities that I have encountered that…
> I kind of wish I could find a good way to make Fortran and C play nicely together.
Fortran can call C and vice-versa, at least since Fortran 2003 there is a standard way to call C.
I don't disagree. Fortran is brilliant at what it does.... but I find many of its object oriented features to be very obtuse compared to C and C++. The way it uses pointers drives me insane. Building certain datastructures in fortran just takes too much time. I kind of wish I could find a good way to make Fortran and C play nicely together. (There are some compiler dependent peculiarities that I have encountered that…
> I kind of wish I could find a good way to make Fortran and C play nicely together. Fortran can call C and vice-versa, at least since Fortran 2003 there is a standard way to call C.
Oh yeah? I have looked and looked for it but been unable to find any reference to how to do so. Would you mind linking a resource to me?
edit: Nevermind I found a few. When I looked for this a few years ago I just kept hitting dead ends.
It's a bachelor thesis... probably doesn't aspire to be the new authority on HPC. :)
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 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.
Hey Floya, I'm writing this here hoping you'll see this comment. You're getting a lot of unjust responses in here. The commentors are reading your thesis with the eyes of a trained skeptic expecting peer reviewed, collaborative work that takes years of experience to produce. They're nitpicking flaws and mistakes we all make when we first start researching.
Your thesis is in fact really impressive and very nicely written! Your conclusions and future work section is excellent. Really very well done. Congratulations on finishing it. I hope you don't let the irrationally negative feedback here dissuade you from continuing your work, you certainly have a bright future ahead of you.
Any HPC language evaluation that doesn't include vs FORTRAN is pointless. It's still king of computation for a reason.
Experiments aren't usually written in FORTRAN. The programmer is by far the slowest part of HPC. It often makes sense to use the language you're fastest at instead of the language that will run the fastest. It's very common for experiments to be written in languages not know for their performance (Java, Matlab, Perl, and Python for instance). For reference, here are some of the packages commonly used in experiments[1…
> fftw3 C
FFTW is C code, but nobody wrote the C code. The C code is generated by code written in OCaml.