5 ms·

Power consumption is going down with each gen and is big cost driver. Also heat dissipation in data centers is costly. Gotta consider TCO in these cases.

gascan 8y ago
Semiconductors are fairly unique in this regard- power consumption has been going down so quickly for so long, it can often be both uneconomical and environmentally unfriendly to continue to operate older hardware.
- adrianN 8y ago
  I'd like to see a detailed calculation. Teaching sand how to think doesn't sound like an environmentally friendly process.
  - gascan 8y ago
    Embodied environmental impact is a difficult calculation, and nobody ever agrees on a number for any complex product like semiconductors, cars, solar panels. But, if we one day price in all the externalities, we can count on the markets to run the numbers for us. If anything, electricity production probably has more subsidies & externalities than semiconductor manufacture.
kragen 8y ago
This is almost completely wrong, because Dennard scaling ended around 2002. Power consumption in mainstream CPUs has been a few picojoules per instruction since the Pentium. Even the MSP430 is almost a pJ/insn. Modern ultra-low-power CPUs like the STM32L reach down below 0.3 pJ/insn, as did the LPC1110 a decade ago. Its more mainstream STM32F siblings are still stuck at 1.5 pJ/insn. Research CPUs using exotic logic families have been below 0.05 pJ/insn since 2000, but are too slow for mass adoption. Power reduction this millennium is almost entirely about changing architecture to GPUs and other more specialized hardware, using wider registers (with SIMD instructions at times) and being smarter about turning things off and ramping their clocks. Concurrently we've seen a huge move from languages like C and Java to languages like JS (10x the computational load of C even with JIT) and Python (200x, or 5x if your program is dominated by Numpy.) So power usage is not a big reason for not using CPUs from 5 years ago.
- bb88 8y ago
  From that argument, we should be coding everything in hand tuned assembly, because hand tuned assembly gives a 10% to 200% speedup over C. The number one slowdown I've seen in rendering web pages, were not bad algorithms or bad programming languages, but bad database queries. And if that's the case, there is a lot more optimization in the DB to be gained than rewriting your back-end to C, say.
  - pcwalton 8y ago
    > From that argument, we should be coding everything in hand tuned assembly, because hand tuned assembly gives a 10% to 200% speedup over C. Yes, all things equal, it's better to write faster CPU-bound code. In a world in which writing optimal machine code all the time was possible without sacrificing anything else important, then we would always want to do it. This is hardly a controversial conclusion. The reason we don't write faster CPU-bound code is that, in the world we live in, all things are never equal. Correctness, security, maintainability, development velocity, portability, engineering culture/trends, and so on are usually more important than raw CPU performance.
  - kragen 8y ago
    This was true in 1995, assuming you can spend unlimited time writing your code. You can almost certainly get an order of magnitude better performance with a custom backend written in a low-level language instead of a SQL database. And, I don't know if you've ever used a SQL database written in Python instead of C, but I have, and it's definitely a lot slower. But it's not true today, because today hand-tuned assembly is slow compared to what you can do on the GPU or an FPGA or a TPU. And, of course, it's not true that you should do this if you can't spend unlimited time writing your code. It's entirely reasonable to use slower languages like Python and JS if you can hack faster as a result. Since many of us are taking that entirely reasonable option, the number of CPU cycles needed to run basic applications is going up, which increases power consumption.
    - littlestymaar 8y ago
      > But it's not true today, because today hand-tuned assembly is slow compared to what you can do on the GPU or an FPGA or a TPU. That's not how thing work. GPUs/TPUs aren't magic, they don't speed everything up: they are really good is some scenario, but they are really slow in many others: the cost of loading memory to the GPU and back from it has a huge cost and it's only worth it if the GPU has enough work to do with the workload. In theory, you could write a web server that runs on the GPU (at least a majority of it, it will still need some CPU work obviously), but it would be incredibly slow, probably slower than if it was a regular web server running on a machine from the 90s. FPGA are totally different beasts, you can theoretically speed up anything with them, but 1. that requires a LOT of work, and 2. they aren't new: anything you can do with FPGA today, you could do it in 1995 already.

gascan 8y ago

Semiconductors are fairly unique in this regard- power consumption has been going down so quickly for so long, it can often be both uneconomical and environmentally unfriendly to continue to operate older hardware.

adrianN 8y ago
I'd like to see a detailed calculation. Teaching sand how to think doesn't sound like an environmentally friendly process.
- gascan 8y ago
  Embodied environmental impact is a difficult calculation, and nobody ever agrees on a number for any complex product like semiconductors, cars, solar panels. But, if we one day price in all the externalities, we can count on the markets to run the numbers for us. If anything, electricity production probably has more subsidies & externalities than semiconductor manufacture.

kragen 8y ago

This is almost completely wrong, because Dennard scaling ended around 2002. Power consumption in mainstream CPUs has been a few picojoules per instruction since the Pentium. Even the MSP430 is almost a pJ/insn. Modern ultra-low-power CPUs like the STM32L reach down below 0.3 pJ/insn, as did the LPC1110 a decade ago. Its more mainstream STM32F siblings are still stuck at 1.5 pJ/insn. Research CPUs using exotic logic families have been below 0.05 pJ/insn since 2000, but are too slow for mass adoption. Power reduction this millennium is almost entirely about changing architecture to GPUs and other more specialized hardware, using wider registers (with SIMD instructions at times) and being smarter about turning things off and ramping their clocks. Concurrently we've seen a huge move from languages like C and Java to languages like JS (10x the computational load of C even with JIT) and Python (200x, or 5x if your program is dominated by Numpy.) So power usage is not a big reason for not using CPUs from 5 years ago.

bb88 8y ago
From that argument, we should be coding everything in hand tuned assembly, because hand tuned assembly gives a 10% to 200% speedup over C. The number one slowdown I've seen in rendering web pages, were not bad algorithms or bad programming languages, but bad database queries. And if that's the case, there is a lot more optimization in the DB to be gained than rewriting your back-end to C, say.
- pcwalton 8y ago
  > From that argument, we should be coding everything in hand tuned assembly, because hand tuned assembly gives a 10% to 200% speedup over C. Yes, all things equal, it's better to write faster CPU-bound code. In a world in which writing optimal machine code all the time was possible without sacrificing anything else important, then we would always want to do it. This is hardly a controversial conclusion. The reason we don't write faster CPU-bound code is that, in the world we live in, all things are never equal. Correctness, security, maintainability, development velocity, portability, engineering culture/trends, and so on are usually more important than raw CPU performance.
- kragen 8y ago
  This was true in 1995, assuming you can spend unlimited time writing your code. You can almost certainly get an order of magnitude better performance with a custom backend written in a low-level language instead of a SQL database. And, I don't know if you've ever used a SQL database written in Python instead of C, but I have, and it's definitely a lot slower. But it's not true today, because today hand-tuned assembly is slow compared to what you can do on the GPU or an FPGA or a TPU. And, of course, it's not true that you should do this if you can't spend unlimited time writing your code. It's entirely reasonable to use slower languages like Python and JS if you can hack faster as a result. Since many of us are taking that entirely reasonable option, the number of CPU cycles needed to run basic applications is going up, which increases power consumption.
  - littlestymaar 8y ago
    > But it's not true today, because today hand-tuned assembly is slow compared to what you can do on the GPU or an FPGA or a TPU. That's not how thing work. GPUs/TPUs aren't magic, they don't speed everything up: they are really good is some scenario, but they are really slow in many others: the cost of loading memory to the GPU and back from it has a huge cost and it's only worth it if the GPU has enough work to do with the workload. In theory, you could write a web server that runs on the GPU (at least a majority of it, it will still need some CPU work obviously), but it would be incredibly slow, probably slower than if it was a regular web server running on a machine from the 90s. FPGA are totally different beasts, you can theoretically speed up anything with them, but 1. that requires a LOT of work, and 2. they aren't new: anything you can do with FPGA today, you could do it in 1995 already.