4 ms·
> extraordinary processing speed options that are orders or magnitude faster than any other laptop If ARM-based chips can be "orders of magnitude" faster than
by jeswin 6y ago
> extraordinary processing speed options that are orders or magnitude faster than any other laptop
If ARM-based chips can be "orders of magnitude" faster than x86, they'll already be dominating datacenters. The performance improvement in sustained compute (within a power envelope) will be incremental rather than the giant leap you're hoping for.
x86 CPUs do not execute their CISC instructions natively; they get decoded to simpler instructions. But the decoder consumes only around 5% of the power budget, so it's not like x86 is spending significant amounts of energy because of the legacy instruction set. Now, due to a decade of high-stakes innovation in the mobile market, ARM solutions will do significantly better in idle power consumption (which was essential for phones).
So, I'll expect way better standby and well managed low-power states/transitions. But a minor increase in full throttle power.
- klelatti 6y agoThat's interesting - do you have a source for 5% of the power budget spent on decoding?
- jeswin 6y agoSorry, I can't recall where I read the 5% number, but here's a study which investigates the impact: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool... They put it at somewhere between 3-10%.
- klelatti 6y agoThanks - and of course ARMv8 decoding will have some cost. I seem to recall that x64 has greater code density too so some offset there.
- thechao 6y agoI haven’t been at Intel in ~8 years, but your description of the implementation of x86 is nothing like the processors I worked on. Admittedly, I never worked on the Xeons; but I would be surprised if decode were 12 watts on those platforms. My guess is that’s off by an easy 2 orders of magnitude.
- jeswin 6y agoMy information is second-hand (I am a software guy); so feel free to correct me here for the benefit of other readers. But here's a study which arrives at a number between 3-10%: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...
- thechao 6y agoYep, looks about right. That benchmark is designed to maximize the decoder cost of the CPU, while effectively idling the rest of the CPU. On some of the architectures I worked on, with the thermals turned off, you could decap the part with decode. But you could also do that by jamming the x87 unit, issuing L0 prefetch, etc. The same is true on the ARM parts I work on. In practice, though, user code doesn’t do this. I’d be interested to see this when the larger L$ are lit—they stop at L2. Also, mops aren’t “RISC”; they’re mops. The only part of the x86 parts I worked in that used a decode ISA was the network & DMA, which desugared down to x86i.
- CodeWriter23 6y ago> If ARM-based chips can be "orders of magnitude" faster than x86, they'll already be dominating datacenters. Raw compute performance is the wrong metric for measuring data center worthiness. The correct metric is performance per dollar. ARM in the DC currently suffers a lack of ARM-specific code optimizers and has to play catch-up in this regard. Amazon recently focused a squad of engineers on adding ARM 64 optimization to the Zend Optimizer in PHP 7.4 to an incremental effect, but then as some cruft is removed on the PHP 8 roadmap, that gain is around 15% in raw performance. Combine that with 20% lower pricing for comparable Graviton2 EC2 instances, and you’ve got a significant cost motivation to migrate to the ARM platform. https://aws.amazon.com/blogs/compute/improving-performance-of-php-for-arm64-and-impact-on-amazon-ec2-m6g-instances/ https://aws.amazon.com/blogs/compute/improving-performance-o... Expect AWS to dedicate engineering resource to similarly bring projects like Python, V8, LLVM, etc. into the ARM-future.
- sjwright 6y agoNote that in performance per dollar, the dollars include cost of the parts, fractional cost of rack space, watts consumed directly and watts consumed indirectly for cooling. There’s also the fixed engineering costs for the life cycle of new hardware and for customers performing migration (where relevant).