4 ms·
Definitely not true about most programmers, but maybe the author meant CS educated engineers. Going through a formal CS program will give you an intimate unders
by anonporridge 3y ago
Definitely not true about most programmers, but maybe the author meant CS educated engineers. Going through a formal CS program will give you an intimate understanding of CPUs, especially when compared to the very light coverage of GPUs.
- croes 3y agoMaybe a generation thing, I remember reading Michael Abrash's Graphics Programming Black Book and learning a lot about cycle eaters in the CPU.
- usea 3y ago> Going through a formal CS program will give you an intimate understanding of CPUs I did an undergrad in CS, where I did well. I don't feel like I understand CPUs very well. Certainly not anywhere in the realm of "intimate."
- galangalalgol 3y agoAre most programmers self trained now? I can see if someone self trains for fe or even full stack with an eye on compensation, they wouldn't understand program counters and the like. But so many people seem motivated by video games to get into the industry that I'd expect them to be reading about things like the fast inverse square root or similar.
- crooked-v 3y agoA lot of game dev now happens in high-level engines, often with their own extra layer of scripting engine. Even working on the nitty-gritty of spatial logic rather than using engine-based colliders/detection would be pretty rare.
- galangalalgol 3y agoSo are we really losing knowledge or just specializing ever more down the fractal?
- c2lsZW50 3y agoI believe the answer is depends, but there were some interesting discussions today under an article which relates to this. https://news.ycombinator.com/item?id=37965142 https://news.ycombinator.com/item?id=37965142
- hombre_fatal 3y agoI think it's just that you don't need to be intimate with lower level details to deliver more value at higher levels like game and application dev. If your day to day involves "intimate knowledge with the CPU" and bumping program counters, I can rule out a lot of things that you probably aren't building, like a compelling iOS app or forum HTTP server, for example. Maybe you're doing impressive work on emulators or something though. But it's nothing to get pompous about just because other people don't share that interest. We too easily go off careening into a circlejerk.
- tester756 3y ago"Going through a formal CS program will give you an intimate understanding of CPUs and 101 other hilarious jokes you can tell yourself!"
- chpatrick 3y agoDepends on the university! In my school to pass the computer architecture course you had to read and present a recent paper on CPU design.
- PeterisP 3y agoWhich most of these students will have entirely forgotten a few years after graduation - use it or lose it.
- tantalor 3y agoThat's a lot to ask of an undergrad
- latency-guy2 3y agoMaybe a modern one for a degree mill that cares not for breadth or depth. It really shouldn't be otherwise. I'm very confident in people having the ability to read by the time they are in college. And considering that summarizing a research paper doesn't even have to be perfect, plus very little need to scrutinize the experiment itself, undergrads should be able to do that. Otherwise they don't belong in college.
- pezezin 3y agoIn my school we had to implement a toy 16-bit CPU in VHDL.
- PartiallyTyped 3y agoSame! Fun times in the labs!
- p1esk 3y agoGoing through a formal CS program will give you an intimate understanding of CPUs Please tell me you forgot the /s. I have a PhD in computer engineering from a top-20 school in US. Took a bunch of grad level classes, passed the quals (my specialty was ML accelerators). I do NOT have an “intimate understanding of CPUs”. I probably know a little bit more about CPUs than an average programmer. Which is very little. Modern CPUs are extremely complex. Almost as much of impenetrable black boxes as modern neural networks.
- gmadsen 3y agoI think the intention of the phrase, is that most cs programs include a systems course. you will learn von neumann arch, with cpu including {registers, clock, ALUs, etc}. Obviously modern CPUs have a lot more complexity, but even the basic coverage of CPUs is more coverage than GPUS.
- p1esk 3y agoEverything you learn about CPUs in your CS undergrad program is applicable to GPUs. Both are examples of von Neumann architecture, both have registers, ALUs, ISA, instruction schedulers, cache hierarchy, external DRAM, etc. The main difference is how they are being used - GPU, while a general purpose computer, is typically used as an accelerator for specific workloads, and it needs CPU to function. The distinction between the two is getting blurred as GPUs get better at executing control flows, and CPUs get more cores and wider vector operations.
- jandrewrogers 3y agoFor anyone that needs to know how a CPU works for performance engineering similar to a GPU, the details of the microarchitecture matter a lot even within the same ISA. I am not aware of any formal CS program that teaches anyone the nuanced internals of various microarchitecture designs. Everyone I know with this knowledge appears to be self-taught regardless of where they went to school. I think the descriptor “intimate” is overstating the case if you don’t know how to optimize code on different implementations of the same ISA. Most formal CS programs give you a generic understanding of CPUs, more like a survey course, not enough information to do serious optimization.
- pca006132 3y agoI am really curious about what kind of optimizations are enabled when you know the microarchitectural design of various CPUs, but without writing assembly by hand. I only know the basics such as optimizing data structure for better cache locality, add some fast paths, manual unrolling, but have no idea about how to work around things like pipeline stalls. It would be really helpful if you can point to some materials about this!
- jandrewrogers 3y agoThe basic principle is that a CPU core is a complex distributed system with varying degrees of parallelism, concurrency, and latency as all of these components communicate with each other. The design of this distributed system varies across microarchitectures as do the available features. Analyzing the optimal codegen is similar to analyzing optimal algorithm design in higher level distributed systems with a fixed hardware specification. Compilers are good at finding very local optimizations targeting specific microarchitectures. If you use godbolt and switch out the architecture flags you can see how the codegen changes. However, as with higher level code, the compiler can’t rewrite your data structures or see patterns spread across too much code. As a simple example, modern cores have 4+ concurrent ALUs with different capabilities. Some of those ALUs are usually idle if there are not enough independent instructions or independent instructions are too far away from the current instruction. You can see large performance improvements simply by reorganizing your C code so that the compiler and CPU can see more opportunities to use more ALUs in parallel. Interestingly, a lot of these code changes are trivial no-ops at the code semantics level, but they bring the ALU concurrency opportunity within view of the CPU. There is an active niche community on the Internet that studies how various instruction sequences interact with various microarchitectures. This is probably the best resource because a lot of detail is not well documented by the CPU companies themselves. It requires a fair amount of experimentation to develop an intuition for how code will run on a given CPU at this level of detail.