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

51–60 of 76 posts

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

#51

Post by OnlyMortal »

amadio wrote: post #50
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…

It came via Bristol University. Make of that what you will.

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

#52

Post by adgjlsfhk1 »

th0ma5 wrote: post #47
adgjlsfhk1 wrote: post #42

Earlier quoted context omitted.

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.

That's exactly the point. People are changing their coding style to work around the fact that loops in the language are slow.

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

#53

Post by th0ma5 »

adgjlsfhk1 wrote: post #52
th0ma5 wrote: post #47

Earlier quoted context omitted.

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

That's exactly the point. People are changing their coding style to work around the fact that loops in the language are slow.

This existed quite a while before Julia, how is it that Julia claims this differentiation then? "We pride ourselves by not using the slow thing you're probably not actually using."

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

#54

Post by amadio »

OnlyMortal wrote: post #51
amadio wrote: post #50

Earlier quoted context omitted.

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…

It came via Bristol University. Make of that what you will.

Just to complement what I said above, here's a link to a presentation I made a couple of years ago about performance optimizations in simulation: https://indico.cern.ch/event/1052654/contributions/4521602/

We also have meetings dedicated to performance, some of which are not public, but this series from ROOT is: https://indico.cern.ch/category/14122/ If you search above, you will see many discussions about performance. The CI for ROOT also has a set of benchmarks to catch regressions, and Geant4 has two systems to track performance, a CI job checking every merge request, which I've set up myself (not publicly accessible), and a more complex system to track performance run by FNAL: https://g4cpt.fnal.gov/

These are just some examples from the projects I've worked on. There are also efforts to port stuff to GPUs and HPCs, and many other projects like event generators that are also undergoing performance work for HL-LHC. If you Google you can probably find a lot more stuff than what I already mentioned. Cheers,

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

#55

Post by eesmith »

AtlasBarfed wrote: post #23
eesmith wrote: post #13

Earlier quoted context omitted.

"Math" is such a wide topic that you certainly must qualify your statement. The standard entomologist curriculum does not require calculus, while a physics curriculum does. Both produce scientists. (For example, https://cals.cornell.edu/education/degrees-programs/entomolo... under "Major Requirements" says "One semester of college statistics or biometry", and the listed physics requirement doesn't require calculus.)…

The article basically implies that some non-professional coder will be doing assembly and basically doing the work of an optimizing compiler. I think the point of the parent is that if you are at this point already, and you're in an academic setting, you might as well real a full computer architecture textbook front to back. I would be curious to know of all the "scientific coders" what percentage of them understood…

I am a professional coder and my eyes glaze over with assembly. Still, I don't think there's that much assembly. What I saw was to show how the code is implemented, with very little about "doing assembly" outside of a simple example.

I can't judge background - I don't have a sense of who uses Julia, and I've been programming for too long, without exposure to the target audience.

Since you mentioned "academic setting", I'll point out there are also scientists-who-program in industrial settings. However, none of the ones I know about use Julia.

My belief is that most scientists-who-program aren't going to read text books from other fields. They are under pressure to produce NOW, and don't think it's worth the time to acquire an entirely new mindset. Instead, I think this sort of knowledge transfer is by jerks and fits, as someone figures out an optimization, and passes it along, with domain-specific context that makes it easier for others in the field to understand.

Which means, like you, I don't think this notebook will be all that useful, though in my case that's because I think it's too generic.

> what percentage of them understood the entire article

I don't think that's a telling metric. Only some scientific coders are interested in writing fast code (vs. fast-enough code), and only some of those use Julia.

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

#56

Post by suavesito »

th0ma5 wrote: post #49
thetwentyone wrote: post #36

Earlier quoted context omitted.

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.

And exactly that is one of the things Julia was designed for, you don't need two languages to get the performance. This allows to have even more flexibility, you can write allocation free, copy free, SIMD code from top to bottom, because it is a single language. That is not possible on other languages, because you have the high-low level language/library distinction. And if you do (JAX?), then you have made what Julia already is, a runtime compiled language, but with its own set of problems.

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

#57

Post by eesmith »

th0ma5 wrote: post #53
adgjlsfhk1 wrote: post #52

Earlier quoted context omitted.

That's exactly the point. People are changing their coding style to work around the fact that loops in the language are slow.

This existed quite a while before Julia, how is it that Julia claims this differentiation then? "We pride ourselves by not using the slow thing you're probably not actually using."

Because Julia claims to get usability and performance in one language, rather than the two Python needs (Python for the user-facing API, C/C++/Fortran/etc. for performance).

This should also help with optimization, and a larger amount of code can be optimized together, while (C)Python can only optimize up to the Python/C boundary.

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

#59

Post by th0ma5 »

eesmith wrote: post #57
th0ma5 wrote: post #53

Earlier quoted context omitted.

This existed quite a while before Julia, how is it that Julia claims this differentiation then? "We pride ourselves by not using the slow thing you're probably not actually using."

Because Julia claims to get usability and performance in one language, rather than the two Python needs (Python for the user-facing API, C/C++/Fortran/etc. for performance). This should also help with optimization, and a larger amount of code can be optimized together, while (C)Python can only optimize up to the Python/C boundary.

I can't imagine anything worse than something that is not appropriate for the abstraction... eg https://en.m.wikipedia.org/wiki/Leaky_abstraction

Again redefining these things here... if the language has tools for all of inline raw chip specific instructions, compiler optimized versions of those instructions, virtualized and then optimized instructions, a jit compiler, and then also high level interpreter operations, then how can it be in anyway an encompassing system and how can that be coherent among all levels without requiring someone to know all levels at which point, I'm going to say no thanks and stick to tools at their respective levels of abstraction where I can reason them to be coherent rather than a dynamically allocated string which is sometimes tied to only working on amd64 because someone wanted an assembler way of pattern matching for some reason.

Maybe within the scope of scientific computing this seems logical if you just restrict yourself to matrix multiplication or whatever, but I don't see how that makes a "language" and it can be coherent, composable, etc...

I've seen a ton of examples, however, over the years of "stunt driven" technological advantages that people thought would be interesting but turned out to be the wrong solution for the wrong problem, but none that claim to break the laws of physics and reason with their evangelism than Julia. Even this article starts with "you must understand the quirks" and I hope that isn't a goal for their design because they are also claiming that I shouldn't have to know the quirks so which is it.

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

#60

Post by th0ma5 »

eigenspace wrote: post #16
reachtarunhere wrote: post #14

Earlier quoted context omitted.

> My experience is a first implementation / novice programmer will write Julia code of a similar speed to python. No because of JIT compilation he would write code faster than Python by default. Now to truly rival optimized C++ code one has to do the tricks mentioned in this post like optimizing memory access, SIMD and maximizing instruction parallelism. The key point is you are better off by default and can do some…

It really depends on what you end up doing. A lot of "python" code is really just thin wrappers around fairly optimized C routines (although there's inefficiencies from the wrapper, and the optimization barriers), so if you're doing something where the bulk of the work is happening inside those routines, beginner-written julia code will end up being roughly comparable to expert-written numpy code or whatever. But yea…

> beginner-written julia code will end up being roughly comparable to expert-written numpy code or whatever

This is not possible by definition, or is a misunderstanding of where and how performance occurs. If this is possible, then it is just as easy to perform worse if the beginner steps to either side of the happy path or if their problem doesn't fit the preconceived optimizations and is therefore no longer a "language" but some kind of "library". I think Julia should be seen as a library and not a language because a language is not comparable in this way that Julia likes to handwave away as magic.

Post reply on HN