Hacker News Reader

There's two ways to grow the space of things to learn: breadth and depth.

You're only thinking about new stuff adding "breadth". I think most people would agree with you that new tools rarely have new use cases, so not truly adding "breadth", but that's where we get into "depth".

When looking at long-term learning, there's a lot of "depth" and subtlety in the way the existing tools work. There also comes a point where you have a firm grasp of all implementation details, but are unhappy with the ergonomics of the existing tools to do a particular job. What was an odd use case can become more common with time. This is how new tools and terminologies are born (adding "breadth"), but you have to remember there are always less experienced devs you need to communicate with. Their understanding will be based on these newer tools. Similarly, you spend the rest of your career "catching up" with the writings of the devs more experienced than you.

Why does any of this matter? Why don't we standardize and end this cycle? Well, that would prematurely kill off innovation. AI training may be allowed to become stale, but human knowledge cannot. The goal is always to improve the existing code and the new code.

I'll give you a recent example: I've been offloading sparse experts to the CPU on a dual socket Zen system. These processors have multiple CPU dies, which connect through shared CCDs, which contain the L3 cache and the bus lines into DRAM and PCIe. (Additionally in the dual socket architecture there is a fabric which links the sockets.) And so by characterizing the physical architecture of the CPU and placing jobs accordingly, I can extract the maximum amount of performance from the system I have on hand.

Dell and some of the other hyperscalers have characterized these systems over the years in terms of maximum throughput via both the cache and the DRAM bus (and I have met or exceeded their numbers). But, nobody has actually characterized (and/or documented) the way that L3 cache eviction and retention works. Using a combination of fuzzing, patent research, and performance analysis, I have been able to characterize the operation of the system and tailor my stack accordingly.

Is this churn? Nah, this hardware is many years obsolete for mainstream deployment. Will this benefit me in my profession? Time will tell. Regardless, I had fun because I enjoy learning.

> Many people in the tech world seem to espouse a great love for "always learning", but the way in which it is said always feels funny to me. Learn about what? When people say this, do they mean that they want to always be learning the next programming language, the next web framework, the next thick-client frontend web framework, the next python packaging CLI tool (pypi, virtualenv, uv ...), the next Linux distro

For me it’s been: Learn more about unix through OpenBSD as a daily driver, learn how the usb and pci stack works in the kernel, refresh my knowledge about operating system, learn a simpler processor (avr) and interfacing, learn digital logic and computer organization, reignite my interest in electronics, refresh my knowledge about control systems, learn how to model dynamic systems, quick dive into robotics…

This is just basic curiosity over the last year. When I was younger and had more time, I explored 3D modeling, making games, pen-testing and reverse engineering, learning various software and platforms,…