5 ms·
I'll never be able to say what I would have chosen to do in the moment, but at least in retrospect, Intel really buffooned their investment in ISA advances by t
by saosebastiao 10y ago
I'll never be able to say what I would have chosen to do in the moment, but at least in retrospect, Intel really buffooned their investment in ISA advances by trying to go after the high end server and mainframe market with Itanium, instead of the mobile market.
I mean, they were trying to sell incremental advances in top speed to people who were buying 20 year support contracts for IBM mainframes to run their legacy COBOL code. They obviously didn't value faster computers, they wanted stability. Having to recompile was just out of the question. And x86-64 was just the thing to get them to upgrade: they could continue running their same crufty code on the same processors that their new code could run on.
The mobile and very low power market, however, will never be taken over by x86. The architecture is just too power hungry, which means batteries need to be large and heavy and more expensive. Phone manufacturers gladly pay premiums for every incremental performance boost, as long as it doesn't consume more power. And the backwards compatibility problem doesn't exist. People throw their phones out every year or two anyway, and nobody has any legacy software they need to keep installed on their new phone. In other words, this market is ripe for ILP, predication, etc., that push off scheduling and branch prediction and other energy hungry tasks onto the compiler.
Funny how now they really want into the very low power market, but have abandoned all the ideas that could given them an edge up.
- frozenport 10y agoClaims of the instruction set being power hungry compared to ARM are unsubstantiated. I understand that certain features such virtual memory consume more power, but why does RAX consume more power?
- physguy1123 10y agoA few things: x86 is harder to decode than arm since the instructions are anywhere between 1-15 bytes while arm instructions are 4 bytes each. It has quite an effect if you want to decode more than 1 instruction per cycle. x86 has a stronger memory model than arm, which will come at an extra cost if implementing any sort of out-of-order execution. I'm not very familiar with how it affects the cache implementation. The x86 instruction set is more complicated than arm, and instructions frequently decode into multiple uops. I believe that microcode is used more extensively in x86.
- ch4ck 10y agoIn reality Intel processors are more power efficient doing something useful than devices from other vendors.
- digi_owl 10y agoI wonder how much that has to do with Intel being a node size ahead of the pack. That said, i know they have been trying to get away from the notion of TDP in recent years because they design their CPUs around the concept of "race to idle". In other words that they try to save power by getting things done ASAP and then put the CPU to sleep until there is input from the user or similar.
- physguy1123 10y agoThis isn't really meant to be a comment about Intel vs arm vendors, but features of x86 that make it harder to implement
- baq 10y agointel botched their integration, ISA is a tiny tiny part of that. ARM solutions were designed for IP integration from the start by necessity of ARM being an IP provider instead of a whole package provider, so customers were free to create their own chips that contained everything required at a few (dozen or w/e) dollars less than intel was able to offer.
- pjc50 10y agoI don't think it's the instruction set so much as the whole design approach; in practice Intel haven't been able to achieve comparable power consumption to ARM in consumer devices such as phones, even if the theoretical MIPS-per-watt is comparable. ARM also offer a selection of lower-end devices which have both lower MIPS and lower watts, especially in standby. Intel don't have anything to match. You can't buy a $1 Intel device that draws microamps in standby and comes with a selection of useful microcontroller peripherals.