Live data from Hacker News

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

viralinstruction.com

31–40 of 76 posts

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

#31

Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.

The site simply told me I was using the wrong browser. How great of an environment can it be if it can render webpages for everyone.

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

#32

This subject is taught in undergrad computer architecture courses along with machine coding. As an EE, I learned it in grad school.

Well, apparently I offended a lot of people by merely providing a piece of information about computer architecture curriculum. I apologize for commenting.

With no context about your emotional state, it came off as a bit brusque, and I think most people read comments like that in a snarky, condescending tone.

If you had prepended the comment with something like "I love this topic!" to show enthusiasm or approval, you probably would have gotten a much different response.

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

#33
post #25
post #15

Earlier quoted context omitted.

This was the premise of Lisp Machines, unfortunely the industry took another path.

Was it? I thought even in the lisp machine days, lisp was kind of garbage collected, so that was always the bottleneck. I remember a quote that was like “Lisp programmers know the value of everything and the cost of nothing” in reference to that.

Yes, and?

GC was a kernel service, and there were low level primitives, including Assembly level Lisp forms.

Parenthesis all the way down to microcode.

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

#34

Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.

The site simply told me I was using the wrong browser. How great of an environment can it be if it can render webpages for everyone.

Your comment must be more about the environment of the web browser you are using?

The site is a staticly published version of a Pluto notebook, which uses modern web features to enable interactivity, reactivity, code syntax highlighting, etc. etc. Tradeoffs to enable those features but requires enabling your browser features. The underlying file that the notebook is based on is just a basic `.jl` file, so you could happily run the notebook from a Julia instance instead of the browser-based notebook environment.

Julia itself will be happy to run however you'd like it to of course.

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

#35

Earlier quoted context omitted.

The site simply told me I was using the wrong browser. How great of an environment can it be if it can render webpages for everyone.

Your comment must be more about the environment of the web browser you are using? The site is a staticly published version of a Pluto notebook, which uses modern web features to enable interactivity, reactivity, code syntax highlighting, etc. etc. Tradeoffs to enable those features but requires enabling your browser features. The underlying file that the notebook is based on is just a basic `.jl` file, so you could h…

I'm sure that is true but I'm just expressing my experience knowing nothing about Julia or Pluto.

I thought I was visiting a website.

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

#36
post #10

Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.

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 good example: there was recently a thread on the Julia discourse comparing Julia and Mojo. Julia used no external libraries (compared to 7 with Mojo) implemented a simpler, faster, and cleaner version of the Mojo code that was used to showcase how fast Mojo was: https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc.... Then further still, folks were able to optimize for even more speed with various abstractions that let Julia take more advantage of the hardware.

That's the promise I think Julia makes and delivers on - you can write incredibly "fast" code simply and cleanly. Yes, you can have a higher standard of "fast" which requires a bit more advanced knowledge but I'd argue that Julia still offers the cleanest/simplest way to take advantage of those micro-optimizaitons.

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

#37
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 clearly felt stupid and conceded the point. He was otherwise a very smart guy and good to work with, but goes to show how we can take our training for granted. Even freshman-level stuff goes over the heads of PhDs, and I'm sure the same would be true if I were to drop into a biochem lab.

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

#38

This subject is taught in undergrad computer architecture courses along with machine coding. As an EE, I learned it in grad school.

While I could certainly put most of this together from my undergrad CS education, I would not say this "subject [was] taught" to me during undergrad. Instead, as with much of undergrad, you get pieces of it along the way - but collecting it together and writing for a somewhat-lay audience has a lot of value. This is also more up to date than my under grad education from ~14 years ago! It has clear explanations for things like Hyperthreading, which existed at the time I was in undergrad, but hadn't really made its way into the curriculum yet.

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

#39
post #11

Earlier quoted context omitted.

I agree with this sentiment, like the majority of CS people are telling statisticians that a lot of Julia remains a kind of snake oil or otherwise mystical thinking, it is very unfortunate. 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.

> 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 non-vector operations. Further, usually when people are having these kinds of issues it's because they started with a non-parallelizable concept of their problem in our trying to redo it... And no amount of magic is going to fix a bad concept of the problem space.

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

#40
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…

I don't think that's right. Well, you're right that some enthusiasts of Julia are too quick to say "fast as C, easy as Python" without appending an asterisk to that statement. You can't get really fast performance without paying any attention to the hardware. Performance is on a spectrum, and usually a tradeoff against readability and conciseness. I think it IS true that Julia excels in that it gives, by far, the bes…

To me, that's the big hand wavy thing is that that thing where if you just do the straightforward obvious thing it's fast, most real world problems aren't straightforward and obvious and therefore turn into something more complex. And now you've got a big can of worms because it was quick in the unspecial case. But now you have no real easy way to get to your special case working correctly without learning more and spending more time just like any other language or switching to a lower level.
Post reply on HN