4 ms·

DJB is spot-on for the pipeline documentation. This can help many apps and workflows, ranging from the one he describes ( tiny tightly optimized cryptography co

by jph 12y ago

DJB is spot-on for the pipeline documentation. This can help many apps and workflows, ranging from the one he describes ( tiny tightly optimized cryptography code) all the way up to the entire JDK, JavaScript V8, Erlang, Beam and similar large VMs.

dragontamer 12y ago
Except modern architectures don't have "pipelines"... at least not like ARM's pipelines are done. Modern Architectures have decoders to translate the assembly into micro-ops which are then stored into a cache (beyond the L1 cache) and then computed. Heck, the entire concept of Intel's "Hyperthreading" kills any pipeline determinism you would hope to achieve. Consider your typical ARM read-modify stall: add r1, r2 / add r1, r3. A stall needs to be inserted into the pipeline because r1's value will change. In contrast, the typical Out-of-Order (OoO) x86 computer (Steamroller, Ivy Bridge, and Bay Trail) will attempt to look at future instructions to execute during the pipeline stall. In the case of Hyperthreaded CPUs (Intel i7, i3, older Atoms), Intel will grab instructions from _another thread_ to execute while the stall is undergoing. And worse yet, as Intel and AMD upgrade their systems, sometimes there are massive architectural differences which cause regressions in some code. The infamous AMD Bulldozer (2011 chip) regressed in FPU and Vectorized code for instance, while AMD tried to up the core count and improve integer performance. If you really want to step into this arena, just use Agner Fog's optimization manual. http://www.agner.org/optimize/instruction_tables.pdf http://www.agner.org/optimize/instruction_tables.pdf But... it isn't as simple as ARM because x86 CPUs are far more complicated. Out-of-order processors just kill any determinism you have.... let alone hyperthreading or the other tricks these bigger CPUs do.
- lgg 12y ago
  Out of order processors do not "kill" determinism. If you can guarantee your initial state is the same you will get the same result in the same number of cycles repeatably. The fact that time it takes is non-obvious does not make it non-deterministic. Now hyperthreading does introduce real non-determinism from the standpoint of a single threaded calculation because it doesn't control the other thread using processor resources, but hyper threading introduces that sort of non-determinism even on in order processors.
  - sigterm 12y ago
    How does a practical program guarantee the initial state of the CPU?
  - hrjet 12y ago
    > Out of order processors do not "kill" determinism. It may be deterministic at the micro-architecture level, but it is non-deterministic at the architecture level. And then there are many other things in the mix: speculative execution, instruction tracing, etc.
    - lgg 12y ago
      Well sure, different implementations behave differently. It still has nothing to do with being OoOE... A 486 and an original Atom are both in order implementations the i386 architecture (though both also implement other extensions), but knowing how code runs on one tells me nothing about the other, and if I just have an ISA reference the i386 without additional documentation or hardware to test on I won't be able to predict how code I write performs on either of them.
brigade 12y ago
Intel actually provides better documentation on its CPU pipelines than ARM does, especially for anything more advanced than the Cortex-A9. Then with Cortex-A5 and A7 you don't even get instruction timings. Cortex-A15 you get nothing official, even though there's quite a few hidden gotcha's that are critical for performance (Did you know that the NEON pipelines are 64-bit wide? Or that there's only 1 VFP pipeline whereas there's two symmetric NEON pipelines? That's some of the barest of basics, yet nowhere does ARM publicly document this info.) Intel you get execution port categories (though you have to infer exactly which instructions fall into which categories), official timings (again inferring precise µop counts), and all sorts of details as to the inner workings of pipelines (random example: there's an entire section about how store forwarding works in Nehalem in the optimization manual, which is quite beyond the detail you'd see in any official ARM manual.) And that's not counting Agner Fog and the details Intel feeds tech journalists.
- userbinator 12y ago
  I think one of the reasons ARM doesn't really want to provide instruction timings is because it sells IP cores, not hardware. Others who integrate ARM cores may make changes to the design that mean their instruction timings will be different, whereas Intel designs and manufacturers the CPUs themselves.
  - brigade 12y ago
    In software terms, that's more difficult than adding support for new HTML extensions given java byte code for a web browser. No one makes modifications that could affect instruction timings (which is a very fundamental aspect of a core), and I very much doubt such modifications are even allowed in the license you buy the cores under, even with a separate architectural license (which is for ground-up designs). Even NVIDIA who bragged about their A9 and A15 core revisions only gave feedback to ARM and had to have them actually implement the changes, and none of those changes affected instruction timing.
  - wolf550e 12y ago
    Different ARMv7 designs have different timings, but I think Cortex A15 is always the same, though running at different frequencies and voltages and consuming different amounts of power.

by jph 12y ago

dragontamer 12y ago

Except modern architectures don't have "pipelines"... at least not like ARM's pipelines are done. Modern Architectures have decoders to translate the assembly into micro-ops which are then stored into a cache (beyond the L1 cache) and then computed. Heck, the entire concept of Intel's "Hyperthreading" kills any pipeline determinism you would hope to achieve. Consider your typical ARM read-modify stall: add r1, r2 / add r1, r3. A stall needs to be inserted into the pipeline because r1's value will change. In contrast, the typical Out-of-Order (OoO) x86 computer (Steamroller, Ivy Bridge, and Bay Trail) will attempt to look at future instructions to execute during the pipeline stall. In the case of Hyperthreaded CPUs (Intel i7, i3, older Atoms), Intel will grab instructions from _another thread_ to execute while the stall is undergoing. And worse yet, as Intel and AMD upgrade their systems, sometimes there are massive architectural differences which cause regressions in some code. The infamous AMD Bulldozer (2011 chip) regressed in FPU and Vectorized code for instance, while AMD tried to up the core count and improve integer performance. If you really want to step into this arena, just use Agner Fog's optimization manual. http://www.agner.org/optimize/instruction_tables.pdf http://www.agner.org/optimize/instruction_tables.pdf But... it isn't as simple as ARM because x86 CPUs are far more complicated. Out-of-order processors just kill any determinism you have.... let alone hyperthreading or the other tricks these bigger CPUs do.

lgg 12y ago
Out of order processors do not "kill" determinism. If you can guarantee your initial state is the same you will get the same result in the same number of cycles repeatably. The fact that time it takes is non-obvious does not make it non-deterministic. Now hyperthreading does introduce real non-determinism from the standpoint of a single threaded calculation because it doesn't control the other thread using processor resources, but hyper threading introduces that sort of non-determinism even on in order processors.
- sigterm 12y ago
  How does a practical program guarantee the initial state of the CPU?
- hrjet 12y ago
  > Out of order processors do not "kill" determinism. It may be deterministic at the micro-architecture level, but it is non-deterministic at the architecture level. And then there are many other things in the mix: speculative execution, instruction tracing, etc.
  - lgg 12y ago
    Well sure, different implementations behave differently. It still has nothing to do with being OoOE... A 486 and an original Atom are both in order implementations the i386 architecture (though both also implement other extensions), but knowing how code runs on one tells me nothing about the other, and if I just have an ISA reference the i386 without additional documentation or hardware to test on I won't be able to predict how code I write performs on either of them.

brigade 12y ago

Intel actually provides better documentation on its CPU pipelines than ARM does, especially for anything more advanced than the Cortex-A9. Then with Cortex-A5 and A7 you don't even get instruction timings. Cortex-A15 you get nothing official, even though there's quite a few hidden gotcha's that are critical for performance (Did you know that the NEON pipelines are 64-bit wide? Or that there's only 1 VFP pipeline whereas there's two symmetric NEON pipelines? That's some of the barest of basics, yet nowhere does ARM publicly document this info.) Intel you get execution port categories (though you have to infer exactly which instructions fall into which categories), official timings (again inferring precise µop counts), and all sorts of details as to the inner workings of pipelines (random example: there's an entire section about how store forwarding works in Nehalem in the optimization manual, which is quite beyond the detail you'd see in any official ARM manual.) And that's not counting Agner Fog and the details Intel feeds tech journalists.

userbinator 12y ago
I think one of the reasons ARM doesn't really want to provide instruction timings is because it sells IP cores, not hardware. Others who integrate ARM cores may make changes to the design that mean their instruction timings will be different, whereas Intel designs and manufacturers the CPUs themselves.
- brigade 12y ago
  In software terms, that's more difficult than adding support for new HTML extensions given java byte code for a web browser. No one makes modifications that could affect instruction timings (which is a very fundamental aspect of a core), and I very much doubt such modifications are even allowed in the license you buy the cores under, even with a separate architectural license (which is for ground-up designs). Even NVIDIA who bragged about their A9 and A15 core revisions only gave feedback to ARM and had to have them actually implement the changes, and none of those changes affected instruction timing.
- wolf550e 12y ago
  Different ARMv7 designs have different timings, but I think Cortex A15 is always the same, though running at different frequencies and voltages and consuming different amounts of power.