Unfortunately I'm not aware of any specific resources you can look into. With that in mind, the following are a number of subjects that I think you could benefit from researching as they are...
Unfortunately I'm not aware of any specific resources you can look into. With that in mind, the following are a number of subjects that I think you could benefit from researching as they are likely to be pertinent to lower-level programming considerations. This is, however, by no means an exhaustive list.
CPU Architecture
Instruction pipelining and stalls.
Temporal and spatial locality with regards to caching.
Loop optimizations such as unwinding and parallel accumulators (which an optimizing compiler may be able to take care of for you).
Performance differences between different CPU instructions.
Operating Systems
CPU scheduling and the different strategies.
CPU-bound vs. I/O-bound processing.
Context switching.
Deadlocking.
Processes, threads, and synchronization.
Different types of processes, e.g. parent vs. child, zombie, and daemon.
Paging.
Page faults.
Segmentation.
Thrashing.
Virtual memory.
You don't necessarily need to have encyclopedic knowledge of these subjects--in fact, most of what I've learned about a lot of these subjects has completely been forgotten--but having even a small amount of familiarity with them will at least allow you to understand the occasional difficult problem that arises because of some OS- or architecture-related bottleneck.
Honestly I think a good way forward would be to look up a MOOC in Operating system from a univsersity that either covers assembly programming as part of the course or as something you can follow...
Honestly I think a good way forward would be to look up a MOOC in Operating system from a univsersity that either covers assembly programming as part of the course or as something you can follow on from there (just use google - there seem to be plenty of these out ther). That would cover the basic knowledge that you can use as a platform for more specific learning afterwards.
Check out Edx, they're essentially Harvard university courses and free, or you can pay to get the certification. https://www.edx.org/course/subject/computer-science You'll probably realize what...
Check out Edx, they're essentially Harvard university courses and free, or you can pay to get the certification.
You'll probably realize what you need/want to learn more of as you dip your feet into things. What platform or applications you wish to develop will determine what language you want to learn.
I guess I'd ask, what's the end goal of learning this stuff? If you want to write an OS kernel, you can start doing that right now. Linus Torvalds wasn't some super expert when he created Linux—he...
I guess I'd ask, what's the end goal of learning this stuff? If you want to write an OS kernel, you can start doing that right now. Linus Torvalds wasn't some super expert when he created Linux—he was still a student—and he copied a lot of design decisions from Minix (here's his original announcement post).
Sorry for the late reply, I have a lot that I wanted to say about this and I have been procrastinating on writing this. First, a bit about my experience: Back in my university years, I spent 8...
Sorry for the late reply, I have a lot that I wanted to say about this and I have been procrastinating on writing this.
First, a bit about my experience: Back in my university years, I spent 8 months as an intern working on the performance of a commercial database engine. I also spent five years working on performance of the Gecko rendering engine used in the Firefox web browser (and Firefox OS, briefly). I have written two OS microkernels, one for an academic project and one as a personal project.
if I want to write small portions of my programs in assembly if the compiler is not great at certain things (and to know when the compiler can do a better job than me!)
The first thing: The golden rule of performance is to always measure first. There aren't many reasons these days to use raw assembly (with a small handful of exceptions), so in general I wouldn't recommend doing so unless you have clear data demonstrating that a particular chunk of compiled code is problematic.
The more recent winners of the Turing Award are John Hennessy and David Patterson. Their book, Computer Architecture: A Quantitative Approach, is the definitive book on the subject of computer architecture. While they also offer another book entitled Computer Organization and Design, I recommend you pick up the former. The latter is geared toward more junior undergraduate students, but honestly the former book is quite readable and goes into more depth.
Hennessy and Patterson illustrate how modern CPUs work. They definitely look at it from a RISC angle, but honestly every CPU these days is RISC. Even modern x86 processors use a translation layer to convert their CISC instructions into a RISC-like internal instruction set for execution.
I would think that after reading that book, you'd have a good enough understanding of modern processors to be able to understand a bunch of things:
Some fundamentals of measuring and quantifying performance;
How modern CPUs work, including speculative, out-of-order execution (You'd be able to understand the Spectre and Meltdown papers);
The entire memory hierarchy, from L1 cache all the way up to swap, and have an idea of the relative performance of having to fetch data from each layer;
How caches are implemented and the what/how of both cache consistency and cache coherency;
SIMD and GPUs
Some other things that I'd recommend:
Learn a real CPU's assembly language.
If you want to learn more about concurrent programming on multiprocessor machines, learn how atomic instructions work and how they're used to build more complex constructs like mutexes and semaphores. Also learn about how those primitives interact with the cache.
Learn how profilers work (eg sampling vs instrumenting), and how to use them.
Unfortunately I'm not aware of any specific resources you can look into. With that in mind, the following are a number of subjects that I think you could benefit from researching as they are likely to be pertinent to lower-level programming considerations. This is, however, by no means an exhaustive list.
CPU Architecture
Operating Systems
You don't necessarily need to have encyclopedic knowledge of these subjects--in fact, most of what I've learned about a lot of these subjects has completely been forgotten--but having even a small amount of familiarity with them will at least allow you to understand the occasional difficult problem that arises because of some OS- or architecture-related bottleneck.
No problem! I love the subject of computer science in general, so I like to help out where I can :)
Honestly I think a good way forward would be to look up a MOOC in Operating system from a univsersity that either covers assembly programming as part of the course or as something you can follow on from there (just use google - there seem to be plenty of these out ther). That would cover the basic knowledge that you can use as a platform for more specific learning afterwards.
Check out Edx, they're essentially Harvard university courses and free, or you can pay to get the certification.
https://www.edx.org/course/subject/computer-science
You'll probably realize what you need/want to learn more of as you dip your feet into things. What platform or applications you wish to develop will determine what language you want to learn.
I guess I'd ask, what's the end goal of learning this stuff? If you want to write an OS kernel, you can start doing that right now. Linus Torvalds wasn't some super expert when he created Linux—he was still a student—and he copied a lot of design decisions from Minix (here's his original announcement post).
That makes sense. Maybe working like an artist (regular practice combined with studying other art) could be something to try.
Sorry for the late reply, I have a lot that I wanted to say about this and I have been procrastinating on writing this.
First, a bit about my experience: Back in my university years, I spent 8 months as an intern working on the performance of a commercial database engine. I also spent five years working on performance of the Gecko rendering engine used in the Firefox web browser (and Firefox OS, briefly). I have written two OS microkernels, one for an academic project and one as a personal project.
The first thing: The golden rule of performance is to always measure first. There aren't many reasons these days to use raw assembly (with a small handful of exceptions), so in general I wouldn't recommend doing so unless you have clear data demonstrating that a particular chunk of compiled code is problematic.
The more recent winners of the Turing Award are John Hennessy and David Patterson. Their book, Computer Architecture: A Quantitative Approach, is the definitive book on the subject of computer architecture. While they also offer another book entitled Computer Organization and Design, I recommend you pick up the former. The latter is geared toward more junior undergraduate students, but honestly the former book is quite readable and goes into more depth.
Hennessy and Patterson illustrate how modern CPUs work. They definitely look at it from a RISC angle, but honestly every CPU these days is RISC. Even modern x86 processors use a translation layer to convert their CISC instructions into a RISC-like internal instruction set for execution.
I would think that after reading that book, you'd have a good enough understanding of modern processors to be able to understand a bunch of things:
Some other things that I'd recommend: