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

How do you define "abstraction" then, I don't see how that is beneficial to obfuscate at which level things are happening.

> Leaky_abstraction

Ummm, CPython is also leaky abstraction. Parts of the C implementation, like garbage collection, id(), 'a is b' checks, the ast and dis modules, and more.

It even has the beginnings of JIT support.

The leaky abstraction thesis is that all layers leak.

Julia's argument is that if you have all of these levels anyway, do it in one language instead of two. If you don't like leaky abstractions, you should prefer a system with one less layer of abstraction.

You also reject Rust, yes? It has many of the same abilities.

And JITed Lisp implementations with user access to the JITted code?

> 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

That sounds like an argument from incredulity.

Just because you don't see how something can be true, that doesn't mean it isn't true.

> which is sometimes tied to only working on amd64 because someone wanted an assembler way of pattern matching for some reason

I believe all of the big C compiler vendors support ways to embed assembly. I use it in my code, for better support for x86-64, and a fallback for other platforms.

I also used Turbo Pascal's inline assembly in the early 1990s.

> but none that claim to break the laws of physics and reason with their evangelism than Julia

I guess you're too young to remember Lisp evangelists.

You seem to be reacting to something beyond what is in the linked-to essay. What breaks the laws of physics? Again, appealing to gut instinct isn't that good of an argument.

That's a good writeup with a lot of general knowledge on program optimization. It might get a bit dense at times with the details of x86 assembly, but I suppose it might be worth it if performance is important enough that understanding e.g. data dependencies between subsequent instructions pays off.

A minor detail I find a bit confusing, though, is explaining the potential benefits of SMT/hyperthreading with an example where threads are spending some of their time idle (or sleeping).

I don't know Julia so I don't know if sleep is implemented with busy-waiting or something there, but generally if a thread is put to sleep, the thread gets blocked from being run until the timer expires or the sleep is interrupted. The operating system doesn't schedule the blocked thread for running on the CPU in the first place, so a thread that's sleeping is not sharing a CPU core with another thread that's being executed.

So the example does not finish 8 jobs almost as fast as 4 or 1 jobs using 4 cores due to SMT; it's rather that half of the time each of the threads is not even being scheduled for running. A total of eight concurrent jobs/threads works out to approximately four of them being eligible to run at a time, matching the four physical cores available.

If there are only four concurrent jobs/threads, each sleeping half of the time, you end up not utilizing the four cores fully because on average two of the cores will be idle with no thread scheduled.

AFAIK SMT should only really be beneficial in cases of stalls due to CPU internal reasons such as cache misses or branch mispredictions, not in cases of threads being blocked for I/O (or sleeping).

The post is of course correct in that the example computation benefits from a higher number of concurrent jobs because of each thread being blocked half of the time. However, that's unrelated to SMT.

Considering how meticulous and detailed the post generally is, I think it would make sense to more clearly separate SMT from the benefits of multithreading in case of partially I/O-bound work.

Do you mind mentioning what browser it is? It works fine on Firefox, and I presume Chromium-based browsers too (since this article has gone through a few rounds and I haven't heard anyone else complain, though some of that was before it became this "notebook" version and was a static page instead). Is it one of those instances where you have Javascript disabled and the page assumes your browser is just not capable of JS instead of telling you to turn it on?

Yes it would happen in JS/python/etc as well once (2 * allOrbitFiles) > Memory. Cool fix I never think about my arrays being larger than memory haha.