9 ms·

As someone who has done extensive work in image processing using custom hardware I am not really sure what he is talking about. Is this intended to suggest tha

As someone who has done extensive work in image processing using custom hardware I am not really sure what he is talking about. Is this intended to suggest that software is cheaper than hardware? Or that it has performance advantages over specialized hardware? Not sure. It's tough to beat smartly-designed specialized hardware in image processing. Some of the things I've done would require ten general purpose computers running in parallel to accomplish what I did in a single $100 chip. So, yes, less cost, higher data rate, reduced thermal load, reduced physical size, less power requirements, etc. Maybe I don't get where he is going with this?

s_tec 14y ago
Multiplying two 32-bit integers will always cost a certain amount of power. Building specialized hardware can get rid of other costs, like the cost of decoding instructions, but the fundamental cost of the multiplications will never go away. If your algorithm requires a million 32-bit multiplications, that sets a firm lower bound on how costly it is. There is no way to magically perform all those multiplications for free.
- sparky 14y ago
  Yes and no. Yes, any given multiplier topology will have some fundamental costs, but the lower bound on the energy for any particular set of multiplicands, latency requirements, and precision requirements will often be much lower than building a canonical multiplier. If you can't make assumptions about any of these (e.g., if it's a multiplier in a general-purpose core), the costs are more uniform (though unless leakage dominates, the energy will still be value-dependent, since dynamic energy is proportional to activity factor). In a domain-specific context though, you often can; these assumptions are borne out in the datapath units of nearly any DSP, GPU, or ASIC.
masterzora 14y ago
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.
radicalbyte 14y ago
No, he's saying that you can't assume that "hardware" can improve your algorithm when you're following a strategy that is fundamentally wrong. "The devil is in the details".
- deleted 14y ago
  [deleted]

s_tec 14y ago

Multiplying two 32-bit integers will always cost a certain amount of power. Building specialized hardware can get rid of other costs, like the cost of decoding instructions, but the fundamental cost of the multiplications will never go away. If your algorithm requires a million 32-bit multiplications, that sets a firm lower bound on how costly it is. There is no way to magically perform all those multiplications for free.

sparky 14y ago
Yes and no. Yes, any given multiplier topology will have some fundamental costs, but the lower bound on the energy for any particular set of multiplicands, latency requirements, and precision requirements will often be much lower than building a canonical multiplier. If you can't make assumptions about any of these (e.g., if it's a multiplier in a general-purpose core), the costs are more uniform (though unless leakage dominates, the energy will still be value-dependent, since dynamic energy is proportional to activity factor). In a domain-specific context though, you often can; these assumptions are borne out in the datapath units of nearly any DSP, GPU, or ASIC.

masterzora 14y ago

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.

radicalbyte 14y ago

No, he's saying that you can't assume that "hardware" can improve your algorithm when you're following a strategy that is fundamentally wrong. "The devil is in the details".

deleted 14y ago
[deleted]