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

What scientists must know about hardware to write fast code (2020)

viralinstruction.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: What scientists must know about hardware to write fast code (2020)

#41

Post by [deleted] »

mjan22640 wrote: post #9
eesmith wrote: post #5

Earlier quoted context omitted.

Congratulations. Studying one field means you know that field. This link is not meant for you. It is meant for a scientist, and most scientists do not also have an EE degree or CS degree. How much graduate level biology, oceanography, physics, geology, chemistry, meteorology, or other scientific field do you know? All of those have subfields where computational performance is important. My experience is scientists ar…

Math was always a must for a scientist, todays computer science is also a must. The study programmes should reflect that.

[deleted]

Re: What scientists must know about hardware to write fast code (2020)

#42

Post by adgjlsfhk1 »

th0ma5 wrote: post #39
newswasboring wrote: post #21

Earlier quoted context omitted.

> Even in the first page of the documentation "No need to vectorize code for performance; devectorized code is fast" is some kind of category error redefinition of how programming languages work in my opinion. Can you elaborate a bit? I don't really get what you are trying to say.

If the code can easily be vectorized then it has the potential to vectorize it incorrectly or there is some automation happening that is hidden. If they're just saying their non-vectorized operations are just as quick, then how quick could true vectorization be. Also, this is how Octave, NumPy, Matlab, R, etc work by making vectorized math operations happen with whole matrices using statements that look like simple n…

I think the problem here is that there are two very different meanings of "vectorized" at play. The first (and what the Julia docs are talking about here) is the pattern of writing "vector-operations" (i.e. rather than writing a loop, writing an expression that works across an entire array). The second meaning is using SIMD instructions (e.g. AVX2). What the julia docs are trying to say is unlike in languages like Python/R/Matlab where loops have a high overhead do to an interpreter, in Julia, loops are fast because the language is compiled. There are lots of algorithms that are easy to express in an iterative fashion that are pretty much impossible to vectorize efficiently (dataflow analyais/differential equations etc).

The docs here aren't trying to talk about SIMD instructions at all here. (although Julia/LLVM are pretty good at producing SIMD instructions from loops where possible).

Re: What scientists must know about hardware to write fast code (2020)

#43

Post by Rayhem »

scottLobster wrote: post #37
morcus wrote: post #29

In college (for a time) I was a double major in CS and Physics. I found a job as a programmer at a Physics lab, which fit my interests very well. The previous person roughly showed me the ropes for just a few days before she left to go to grad school. The PI started asking me to run some analyses on a raw dataset. Since I was so new at it, I often messed up and had to rerun the whole thing after looking at the output…

Yeah, back in college I worked with a Biochemistry grad student on a group project that involved some coding (I was Computer Engineering). To iterate over a matrix, he used three nested loops with an if-statement to switch between rows and columns. Technically it worked but wildly inefficient, and he was proud of it... To his credit once I (as nicely as possible) showed him how to do it with two nested for-loops he c…

Similar story - a PI had written some code to from (row, column) indices of the upper triangle of a matrix (made somewhat tricky by excluding the main diagonal) to a linear index. He used a for loop to start from the beginning and count up for an O(n^2) algorithm - I was able to give him an O(1) constant time formula to do the same thing for a rather dramatic speedup.

Re: What scientists must know about hardware to write fast code (2020)

#44

Post by OnlyMortal »

Having been asked to port CERN C++ code to the Mac, I can tell you that some scientists don’t know or even care about performance.

For those folks, getting the output they need is much more important than the CPU cycles - as it should be.

As a C++ programmer, I posed the question as to why they don’t hire coders to do this for them. The answer was cost which rather surprised me given the cost of the LHC.

Re: What scientists must know about hardware to write fast code (2020)

#45

Post by meow_cat »

scottLobster wrote: post #37
morcus wrote: post #29

In college (for a time) I was a double major in CS and Physics. I found a job as a programmer at a Physics lab, which fit my interests very well. The previous person roughly showed me the ropes for just a few days before she left to go to grad school. The PI started asking me to run some analyses on a raw dataset. Since I was so new at it, I often messed up and had to rerun the whole thing after looking at the output…

Yeah, back in college I worked with a Biochemistry grad student on a group project that involved some coding (I was Computer Engineering). To iterate over a matrix, he used three nested loops with an if-statement to switch between rows and columns. Technically it worked but wildly inefficient, and he was proud of it... To his credit once I (as nicely as possible) showed him how to do it with two nested for-loops he c…

During my masters thesis in a chemistry lab, I got a side task to look at a data analysis script and make it run faster. It was a "C/C++" code (i.e. procedural C-style code using C++ stdlib for convenience) that read a file line by line and then fed it to a slow processing function, then aggregated the results. It took over a day to run.

Without even looking at the processing function, which I considered some sciency science, I set up pthreads and mutexes on the result array and such to reap almost perfectly linear scaling. So far, so good.

Then I ran a profiler to see what was actually taking so long.

... Uh, why are you spending all this time copying strings back and forth?

Turns out they passed all strings by value. Sprinkling in a few const & here and there got a 1000-fold speedup or such. I felt pretty stupid for my multithreading antics after that.

Re: What scientists must know about hardware to write fast code (2020)

#46

Post by ericmcer »

morcus wrote: post #29

In college (for a time) I was a double major in CS and Physics. I found a job as a programmer at a Physics lab, which fit my interests very well. The previous person roughly showed me the ropes for just a few days before she left to go to grad school. The PI started asking me to run some analyses on a raw dataset. Since I was so new at it, I often messed up and had to rerun the whole thing after looking at the output…

Could you have achieved the same thing by just delete/free() the old arrays after copying them? I suck at manually allocating memory, have always worked in garbage collected languages where this wouldn't really be an issue.

Re: What scientists must know about hardware to write fast code (2020)

#47

Post by th0ma5 »

adgjlsfhk1 wrote: post #42
th0ma5 wrote: post #39

Earlier quoted context omitted.

If the code can easily be vectorized then it has the potential to vectorize it incorrectly or there is some automation happening that is hidden. If they're just saying their non-vectorized operations are just as quick, then how quick could true vectorization be. Also, this is how Octave, NumPy, Matlab, R, etc work by making vectorized math operations happen with whole matrices using statements that look like simple n…

I think the problem here is that there are two very different meanings of "vectorized" at play. The first (and what the Julia docs are talking about here) is the pattern of writing "vector-operations" (i.e. rather than writing a loop, writing an expression that works across an entire array). The second meaning is using SIMD instructions (e.g. AVX2). What the julia docs are trying to say is unlike in languages like Py…

But no one in science uses Python loops for example, they use NumPy / Jax / Polars etc so that is an unfair and disingenuous comparison.

Re: What scientists must know about hardware to write fast code (2020)

#48

Post by vladf »

Rayhem wrote: post #43
scottLobster wrote: post #37

Earlier quoted context omitted.

Yeah, back in college I worked with a Biochemistry grad student on a group project that involved some coding (I was Computer Engineering). To iterate over a matrix, he used three nested loops with an if-statement to switch between rows and columns. Technically it worked but wildly inefficient, and he was proud of it... To his credit once I (as nicely as possible) showed him how to do it with two nested for-loops he c…

Similar story - a PI had written some code to from (row, column) indices of the upper triangle of a matrix (made somewhat tricky by excluding the main diagonal) to a linear index. He used a for loop to start from the beginning and count up for an O(n^2) algorithm - I was able to give him an O(1) constant time formula to do the same thing for a rather dramatic speedup.

I ended up needing this so often for graph processing, and for values which might be inexact if using floating point, that I saved the formula in a blog post. https://vladfeinberg.com/2020/03/07/subset-isomorphism.html

The formula can be "oblivious" to the final size of the matrix too, which is helpful if you're doing some sparse ML training on edges (e.g., GNNs).

Re: What scientists must know about hardware to write fast code (2020)

#49

Post by th0ma5 »

thetwentyone wrote: post #36
th0ma5 wrote: post #10

Earlier quoted context omitted.

I feel the biggest misleading statements around Julia is that for true speed you can somehow ignore the lower abstractions, or that there is some kind of free lunch, but always what you gain in performance you'll spend in development time. Julia has some neat tricks, but they are not generally and universally applicable at least not like other languages. I dunno. These arguments against Julia are many, but I'm still…

There are different levels of performance to target though - a _basic_ (no SIMD, parallelization, etc) `for` loop can easily be as fast as an C++ version. More performance can be had from both languages, of course. In my experience, the Julia versions offer easier mechanisms to take the code from _basic_ fast to _advanced_ fast. For many, _basic_ fast is fast enough. And when it matters, you can go a bit deeper. A go…

The speed ups exist in other languages like data.table in R, Polars / Jax / NumPy in Python for example.

Re: What scientists must know about hardware to write fast code (2020)

#50

Post by amadio »

OnlyMortal wrote: post #44

Having been asked to port CERN C++ code to the Mac, I can tell you that some scientists don’t know or even care about performance. For those folks, getting the output they need is much more important than the CPU cycles - as it should be. As a C++ programmer, I posed the question as to why they don’t hire coders to do this for them. The answer was cost which rather surprised me given the cost of the LHC.

This is not true. Maybe a PhD student doesn't care much (or doesn't know), but we care deeply about software performance at CERN. I've worked myself on optimizations in detector simulation and data analysis software (Geant4 and ROOT) for a few years. Later in this decade, when HL-LHC comes online, the only way to be able to cope with the 10x increase in data rate from experiments and a matching increase in simulation requirements will be to optimize as much as we can the software we have, because we will not have the money to just buy 10x the hardware we have now.
Post reply on HN