3 ms·
Compiler engineers need to read assembly. I don't think too many people write lots of it by hand, unless they're extending packages like LAPACK of BLAS. Softwa
by timClicks 7y ago
Compiler engineers need to read assembly. I don't think too many people write lots of it by hand, unless they're extending packages like LAPACK of BLAS.
Software has probably been free-riding on hardware, but hardware has also not been keeping up with hardware. The big difficulty is the latency between memory and the processor.
Rust is closer than Go. Go isn't designed to make optimal code. It's there to make good enough code. And it does so very quickly.
In terms of resources, I really like Crafting Interpreters. Would love for you to take a glance at my book (Rust in Action, Manning), if you want to learn about other systems topics outside of compiler design.
- viraptor 7y agoGo also schedules N:M, which means it's not trivial to ensure that your code keeps running on the same CPU... which may be important for hardware.
- majewsky 7y agoWhy do people keep repeating this myth, when thread pinning is literally a one-liner? > LockOSThread wires the calling goroutine to its current operating system thread. The calling goroutine will always execute in that thread, and no other goroutine will execute in it, until the calling goroutine has made as many calls to UnlockOSThread as to LockOSThread. [...] A goroutine should call LockOSThread before calling OS services or non-Go library functions that depend on per-thread state. Source: https://golang.org/pkg/runtime/#LockOSThread https://golang.org/pkg/runtime/#LockOSThread
- viraptor 7y agoIt's usually enough, but not always. For example namespaces and new threads don't handle this well, even if you do LockOSThread https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix https://www.weave.works/blog/linux-namespaces-and-go-don-t-m...
- rantanplan 7y agoThat has been fixed quite a while ago, in Go 1.10