4 ms·

To expand on your suggestion a little, I would suggest going even further - learn how to design your own processors and figure out how the low-level details rea

To expand on your suggestion a little, I would suggest going even further - learn how to design your own processors and figure out how the low-level details really work. With hardware description languages such as Verilog, programmers can apply a lot of their knowledge to hardware engineering. I've found that a lot of things carry over from conventional programming languages to HDLs, and that it's incredibly easy to get started. The computer engineering mindset is pretty similar to low-level programming, and really helps you understand how your code runs, even more so than assembly.

jonsen 14y ago
Completely agree. I was about to write something like that. I've designed processorlike hardware, but not touched it since the 80'es, so I'm not really confident in state of the art of hardware programming.
jules 14y ago
One surprise that you find out when you do this is that languages like C don't efficiently map to hardware at all. Hardware is inherently massively parallel, whereas C is completely serial. What modern hardware is doing to be fast is trying to recover as much fine grain parallelism from a sequential C program as possible using pipelines and out of order execution. We are now at a point where that has been mostly milked out, so explicit parallelism is necessary to gain performance, like SIMD and multiple threads. It's interesting to consider how you can exploit parallelism more easily, for example from going from a sequential instruction set and language to an inherently parallel instruction set and language. Nobody has found the ultimate answer to that yet. GPUs execute thousands of sequential threads in parallel, and while that works for problems with massive and regular parallelism, it does not work for irregular parallelism or parallelism that requires fine grain communication or short lived parallelism or not-so-massive parallelism. FPGAs do work well for those types of parallelism, but they have other problems for general purpose computing. With hardware trends, it's inevitable that we'll see more and more parallelism and eventually a paradigm shift to inherently parallel architectures. Interesting times ahead.
- PieSquared 14y ago
  The point you make is really valuable. A few days ago, I found myself explaining to someone why custom hardware and GPUs could so easily outperform processors, and I realized that most programmers have no concept of how much overhead the general nature of a processor entails. (Although, I don't think most programmers really need to know this.) For instance, let's take the problem of multiplying ten numbers. In a normal processor, you have a loop of instructions, each instruction has to go through a "fetch" state (to load it from memory), a "decode" stage, to figure out what the instruction is, an "issue" stage, to figure out which processor pipeline can best execute this instruction, an "execute" stage, to finally execute the instruction, and maybe a "commit" stage to write the outputs back to memory. (The exact number of stages and amount of parallelism depends on the microarchitecture and pipeline depth, of course). What if we wanted to just build a chip that did this? We could put ten multipliers on the chip, and then do the exact same operations in just a few clock cycles, since we would have no instruction fetch or decode, no commit, no loops, and so on. This is a contrived example, but my point is that general-purpose processors are incredibly slow compared to dedicated hardware, precisely because the extra transistors necessary to make processors general purpose also take a large portion of the computing time. I find the idea of FPGAs reconfigured per-application to be really interesting. Celoxica (http://www.celoxica.com http://www.celoxica.com) seems to do some sort of FPGA-based software acceleration for trading software, for instance. I wonder if it's possible to do something like this for a more general market...

jonsen 14y ago

Completely agree. I was about to write something like that. I've designed processorlike hardware, but not touched it since the 80'es, so I'm not really confident in state of the art of hardware programming.

jules 14y ago

One surprise that you find out when you do this is that languages like C don't efficiently map to hardware at all. Hardware is inherently massively parallel, whereas C is completely serial. What modern hardware is doing to be fast is trying to recover as much fine grain parallelism from a sequential C program as possible using pipelines and out of order execution. We are now at a point where that has been mostly milked out, so explicit parallelism is necessary to gain performance, like SIMD and multiple threads. It's interesting to consider how you can exploit parallelism more easily, for example from going from a sequential instruction set and language to an inherently parallel instruction set and language. Nobody has found the ultimate answer to that yet. GPUs execute thousands of sequential threads in parallel, and while that works for problems with massive and regular parallelism, it does not work for irregular parallelism or parallelism that requires fine grain communication or short lived parallelism or not-so-massive parallelism. FPGAs do work well for those types of parallelism, but they have other problems for general purpose computing. With hardware trends, it's inevitable that we'll see more and more parallelism and eventually a paradigm shift to inherently parallel architectures. Interesting times ahead.

PieSquared 14y ago
The point you make is really valuable. A few days ago, I found myself explaining to someone why custom hardware and GPUs could so easily outperform processors, and I realized that most programmers have no concept of how much overhead the general nature of a processor entails. (Although, I don't think most programmers really need to know this.) For instance, let's take the problem of multiplying ten numbers. In a normal processor, you have a loop of instructions, each instruction has to go through a "fetch" state (to load it from memory), a "decode" stage, to figure out what the instruction is, an "issue" stage, to figure out which processor pipeline can best execute this instruction, an "execute" stage, to finally execute the instruction, and maybe a "commit" stage to write the outputs back to memory. (The exact number of stages and amount of parallelism depends on the microarchitecture and pipeline depth, of course). What if we wanted to just build a chip that did this? We could put ten multipliers on the chip, and then do the exact same operations in just a few clock cycles, since we would have no instruction fetch or decode, no commit, no loops, and so on. This is a contrived example, but my point is that general-purpose processors are incredibly slow compared to dedicated hardware, precisely because the extra transistors necessary to make processors general purpose also take a large portion of the computing time. I find the idea of FPGAs reconfigured per-application to be really interesting. Celoxica (http://www.celoxica.com http://www.celoxica.com) seems to do some sort of FPGA-based software acceleration for trading software, for instance. I wonder if it's possible to do something like this for a more general market...