6 ms·

It is tough to pull a coherent thesis from this piece but it seems to be close to "be aware of the costs involved because, although specialised hardware can be

It is tough to pull a coherent thesis from this piece but it seems to be close to "be aware of the costs involved because, although specialised hardware can be useful in many situations, it is not a magic wand you can wave." The way it opens he seems to imply that he is used to people excusing slow/inefficient ideas by handwaving that doing it in hardware will be fast without doing any real critical evaluation on what gains hardware can actually bring. The fact that some systems can see real gains from specialised hardware does not serve as a counterargument if this is in fact his thesis.

_delirium 14y ago
You can get a bit better idea where he's coming from from his previous series (linked in the post) responding to people arguing that high-level languages would be faster if hardware were designed for them. In his view the Lisp-machine idea of HLL-specialized hardware design rarely pans out vs. just RISC with an optimizing compiler. This piece seems to be applying the same critique to algorithms more generally, that "we'll just do it in hardware" isn't a magic win, because it's not always an issue of impedance mismatches with the hardware that can be simply fixed by choosing different hardware. The places he suggests you can get a win seem sensible: 1) cases where the cost of dispatching instructions and handling intermediate results dominates, in which case a CISC-ish specialized instruction implemented in silicon may be a win over stringing together simpler operations; and 2) cases where you can get extra parallelization in hardware that isn't available through general-purpose instructions (e.g. doesn't map on nicely to SSE-style instructions).
- rbanffy 14y ago
  Lisp machines belong to a past so distant I don't think their are relevant for exploring the possibilities of contemporary hardware. The design constraints moved - clock is in the gigahertz range, memory is orders of magnitude slower and we have to deal with multiple levels of cache between them. And that's just the start. In fact, the concept of "doing it in hardware" (be it specialized logic or dedicated generic processors) is alive and well (and bearing fruit) on every mainframe manufactured. The fact we all use similar x86 boxes designed to be compatible with MS-DOS is a tragedy.
  - smashing 14y ago
    I don't know if tragedy is the right word for this. We live in an era where the marketplace has more of an effect on the trends in computing than academia. Nothing tragic about that.
    - rbanffy 14y ago
      It really is. It took years after the Amiga for the average PC to have preemptive multitasking. The same story repeats with 64-bit machines and multi-processors. In the latter case, it took so long for the average PC to have more than one CPU/thread most current software (and programming languages) simply isn't designed for it and cannot take advantage of those extra compute engines. Even if it were, most programmers never learned how to write software this way. The PC standard set us back at least a decade, most probably two.
      - deleted 14y ago
        [deleted]
      - yuhong 14y ago
        "It took years after the Amiga for the average PC to have preemptive multitasking. " Partly thanks to the MS OS/2 2.0 fiasco, also resulting it taking ten years after Intel released the 80386 before 32-bit programming became popular. Needless to say, the x64 transition went much better.
        dkersten 14y ago
        And AMD forced Intels hand on the move to 64bit.
        rbanffy 14y ago
        Intel had already moved on. All AMD did was to make Intel put the x86 back into the 64 bit picture. I'd prefer a clean break.
- cwzwarich 14y ago
  The ancient style of HLL-specialized hardware no longer makes sense, but that doesn't mean that there aren't other improvements that make sense. For example, support for read and write barriers (especially read barriers) would dramatically improve garbage collection.
  - _delirium 14y ago
    That's plausible, although I'm somewhat skeptical why it wouldn't have shown up in someone's hardware if it truly worked out to be worth the cost, since there is a lot of enterprise software built on the JVM and .NET that would benefit from garbage collection speedups, and which is being run by companies willing to pay for those speedups. Fwiw, Yosef K.'s own follow-up to his "HLL CPU challenge" did acknowledge several proposals he received as plausible candidates: http://www.yosefk.com/blog/high-level-cpu-follow-up.html http://www.yosefk.com/blog/high-level-cpu-follow-up.html
    - cwzwarich 14y ago
      It did show up in somebody's hardware. Azul made (and is still making) hardware for Java that does this. They also release an x86 JVM that is able to fake it a bit by using HW virtualization support and double mapping pages.
- Spooky23 14y ago
  So I guess the premise is that you have two extremes: minimal instruction set (RISC) and complex (a CPU designed to run Python, for example). IMO, as is often the case, the answer lies in the middle. Look at the tremendous impact that adding AES acceleration features to x86 processors has on applications that require encryption.
  - _delirium 14y ago
    That seems to be what he's arguing, actually; that you can get hardware speedups if you carefully target very specific things that a parsimonious addition of hardware features can enable.
  - beagle3 14y ago
    Never noticed that tremendous impact - in fact, one of the reasons rijndael became AES was because it was already very fast on contemporary 32 bit computers. What impact did you observe?

_delirium 14y ago

You can get a bit better idea where he's coming from from his previous series (linked in the post) responding to people arguing that high-level languages would be faster if hardware were designed for them. In his view the Lisp-machine idea of HLL-specialized hardware design rarely pans out vs. just RISC with an optimizing compiler. This piece seems to be applying the same critique to algorithms more generally, that "we'll just do it in hardware" isn't a magic win, because it's not always an issue of impedance mismatches with the hardware that can be simply fixed by choosing different hardware. The places he suggests you can get a win seem sensible: 1) cases where the cost of dispatching instructions and handling intermediate results dominates, in which case a CISC-ish specialized instruction implemented in silicon may be a win over stringing together simpler operations; and 2) cases where you can get extra parallelization in hardware that isn't available through general-purpose instructions (e.g. doesn't map on nicely to SSE-style instructions).

rbanffy 14y ago
Lisp machines belong to a past so distant I don't think their are relevant for exploring the possibilities of contemporary hardware. The design constraints moved - clock is in the gigahertz range, memory is orders of magnitude slower and we have to deal with multiple levels of cache between them. And that's just the start. In fact, the concept of "doing it in hardware" (be it specialized logic or dedicated generic processors) is alive and well (and bearing fruit) on every mainframe manufactured. The fact we all use similar x86 boxes designed to be compatible with MS-DOS is a tragedy.
- smashing 14y ago
  I don't know if tragedy is the right word for this. We live in an era where the marketplace has more of an effect on the trends in computing than academia. Nothing tragic about that.
  - rbanffy 14y ago
    It really is. It took years after the Amiga for the average PC to have preemptive multitasking. The same story repeats with 64-bit machines and multi-processors. In the latter case, it took so long for the average PC to have more than one CPU/thread most current software (and programming languages) simply isn't designed for it and cannot take advantage of those extra compute engines. Even if it were, most programmers never learned how to write software this way. The PC standard set us back at least a decade, most probably two.
    - deleted 14y ago
      [deleted]
    - yuhong 14y ago
      "It took years after the Amiga for the average PC to have preemptive multitasking. " Partly thanks to the MS OS/2 2.0 fiasco, also resulting it taking ten years after Intel released the 80386 before 32-bit programming became popular. Needless to say, the x64 transition went much better.
      - dkersten 14y ago
        And AMD forced Intels hand on the move to 64bit.
        rbanffy 14y ago
        Intel had already moved on. All AMD did was to make Intel put the x86 back into the 64 bit picture. I'd prefer a clean break.
cwzwarich 14y ago
The ancient style of HLL-specialized hardware no longer makes sense, but that doesn't mean that there aren't other improvements that make sense. For example, support for read and write barriers (especially read barriers) would dramatically improve garbage collection.
- _delirium 14y ago
  That's plausible, although I'm somewhat skeptical why it wouldn't have shown up in someone's hardware if it truly worked out to be worth the cost, since there is a lot of enterprise software built on the JVM and .NET that would benefit from garbage collection speedups, and which is being run by companies willing to pay for those speedups. Fwiw, Yosef K.'s own follow-up to his "HLL CPU challenge" did acknowledge several proposals he received as plausible candidates: http://www.yosefk.com/blog/high-level-cpu-follow-up.html http://www.yosefk.com/blog/high-level-cpu-follow-up.html
  - cwzwarich 14y ago
    It did show up in somebody's hardware. Azul made (and is still making) hardware for Java that does this. They also release an x86 JVM that is able to fake it a bit by using HW virtualization support and double mapping pages.
Spooky23 14y ago
So I guess the premise is that you have two extremes: minimal instruction set (RISC) and complex (a CPU designed to run Python, for example). IMO, as is often the case, the answer lies in the middle. Look at the tremendous impact that adding AES acceleration features to x86 processors has on applications that require encryption.
- _delirium 14y ago
  That seems to be what he's arguing, actually; that you can get hardware speedups if you carefully target very specific things that a parsimonious addition of hardware features can enable.
- beagle3 14y ago
  Never noticed that tremendous impact - in fact, one of the reasons rijndael became AES was because it was already very fast on contemporary 32 bit computers. What impact did you observe?