Intel's architects haven't been playing golf all of these years while waiting for TMG to fix themselves, and AMD's architects have many dimensions they can improve the Zen design in seeing as its the first in a long series.
Last edited:
Intel's architects haven't been playing golf all of these years while waiting for TMG to fix themselves, and AMD's architects have many dimensions they can improve the Zen design in seeing as its the first in a long series.Really? I don't expect much if anything...
I was thinking you were saying that 7nm and 10nm would bring a lot of improvements as processes. This is what I doubt.Intel's architects haven't been playing golf all of these years while waiting for TMG to fix themselves, and AMD's architects have many dimensions they can improve the Zen design in seeing as its the first in a long series.
It is very likely that these CPU's are purpose built for a specific TDP and performance level. Much of processor design is finding the sweet spot between complexity (IPC) and clockspeed for a given node.
I expect 7nm and 10nm x86 CPU's to be a significant jump far beyond what we're used to. That's if Intel can manufacture 10nm eventually .
TSMC and GloFo 7nm are definitely better than their 16/14 processes in performance and efficiency, not just density. Intel is in a weirder spot in that they're having trouble beating their 14++, but need to start moving forward with density.I was thinking you were saying that 7nm and 10nm would bring a lot of improvements as processes. This is what I doubt.
As far as uarch improvements go, I can guarantee others are not standing still either.
What is your defintion for design and architecture? If you start changing the core by lengthening pipelines or adding caches, that's an architecture in my eyes. And in that sense architectures are in fact made for specific targets. If by architecture you mean x86 or ARM then in that case you're correct.Design is indeed optimized for a certain power and performance level, architecture however is not. I hope you understand the difference.
On the grounds of what exactly?You ignoring the x86-penalty. x86/x64 architectures can not possibly come close to the efficiency, which is possible with ARMv8.
What is your defintion for design and architecture? If you start changing the core by lengthening pipelines or adding caches, that's an architecture in my eyes
On the grounds of what exactly?
You do realize that x86 designs' uncore takes more power than entire phone SoC's to handle the relatively massive amounts of memory, I/O, and scalability they can handle?
The x86 penalty is extremely overstated, especially the whole RISC/CISC comparison. These days it's basically a bit of extra die space for the uOp cache
Fair points all around, but in the end that only matters if the penalties are at all noticeable relative to the costs of where your power budget goes to these days, chiefly data movement. I haven't seen any evidence to suggest this.Indeed, architecture is loosely reflected at RTL level, while design is reflected at gate level/cell level.
In my example from above we are using the very same architecture, with different design (e.g. different cell mix, drivers, netlist) in conjunction with low power memories for caches etc.
The achievable frequency range is at least factor 2 between ultra low power (at or below nominal voltage) and high performance (at overdrive voltage) for the very same architecture.
I do not agree that it is overstated, it is understated based on your comments. Its not just the uOp cache itself, its the fact that there is a uOP cache at all with large miss penalty (e.g. pre-decode miss). Its the fact that with variable instruction length you cannot start decoding before knowing the length of previous instruction. Its the fact, that there are few 3 operand instructions ,which requires additional moves (either register to register or register to memory), it the fact that you only have 16 registers which increases the amount of memory accesses, its the fact that memory references are hard to prove independent and cannot be subject to register renaming while ooo scheduling, its the fact that return address is stored on stack instead of registers, its the fact that far calls uses segment descriptors to access GDT or LDT....i could go on and on. Most of these "features" were much less of a problem in the 20th century but today they limit both efficiency and setting upper boundary for realistically achievable IPC.
Fair points all around, but in the end that only matters if the penalties are at all noticeable relative to the costs of where your power budget goes to these days, chiefly data movement. I haven't seen any evidence to suggest this.
We shall wait and see I guess.
Of course if you're not doing any useful computation then that would be the least power used. But when you are actually doing something, where is the most energy being used? Feeding your execution units or actually doing said execution?The theory that data movement takes most power is not necessarily sound. The irony is, that power simulations on system level show that its not the code with many cache misses and thus requiring dram access take most power, but code who has the most cache hits. Background is, that code with many cache misses does less work per time (or has lower IPC) and core internal units are clock gated while waiting on memory access. Interestingly ALU operations taking much less power than a load or store even on a wide ALU like NEON*. So worst case power could be achieved with code which only consisted of loads in conjunction with L1$ hits. With an ooo pipeline things look slightly different, for worst case power you need to mix in independent ALU operations such that load/store unit stays saturated. I bet when writing synthetic code with above rules you get something which putting Prime95 to shame with respect to power usage
In summary i would be careful when claiming where most of the power ist lost - because it depends on quite a few factors.
*This could be different for AVX512 units, but i do not have any data for this case.
RISC vs CISC is over for quite some time now, internally X86 are RISC machines and ARM makes RISC purists cry with plenty of CISC like instructions.
You might have noticed that RISC vs. CISC is nowhere to be found in my argumentation - and then you go on arguing about other irrelevant factors plus some "magic", which magically has no costs and some nonsense about non-impacting low number of architectural registers - because there is register renaming...
The same could be asked from you since you said that having 16 GPR is fineP.S. Please put forward the real world codes and/or academic research where 16GPRs backed by spills to XMM registers are highly limiting factor.
Indeed, architecture is loosely reflected at RTL level, while design is reflected at gate level/cell level.
In my example from above we are using the very same architecture, with different design (e.g. different cell mix, drivers, netlist) in conjunction with low power memories for caches etc.
The achievable frequency range is at least factor 2 between ultra low power (at or below nominal voltage) and high performance (at overdrive voltage) for the very same architecture.
I do not agree that it is overstated, it is understated based on your comments. Its not just the uOp cache itself, its the fact that there is a uOP cache at all with large miss penalty (e.g. pre-decode miss). Its the fact that with variable instruction length you cannot start decoding before knowing the length of previous instruction. Its the fact, that there are few 3 operand instructions ,which requires additional moves (either register to register or register to memory), it the fact that you only have 16 registers which increases the amount of memory accesses, its the fact that memory references are hard to prove independent and cannot be subject to register renaming while ooo scheduling, its the fact that return address is stored on stack instead of registers, its the fact that far calls uses segment descriptors to access GDT or LDT....i could go on and on. Most of these "features" were much less of a problem in the 20th century but today they limit both efficiency and setting upper boundary for realistically achievable IPC.
16 registers is just fine, and was increased to 32 registers with AVX512 where it matters the most -> in vector processing, and cause of register rename i highly doubt it is relevant much in general code. We are long past 4-6 GPR days of x86.
RISC vs CISC is over for quite some time now, internally X86 are RISC machines and ARM makes RISC purists cry with plenty of CISC like instructions.
X86 instruction decode of course remains problematic and decoders burn power, but realistically uOP caches, loop buffers and other magic are there to ease the burden. On ARM side of things there is also plenty of "bundling" of OPs going after decode and it can be argued that because RISC like instructions are simpler you end up more instructions to express same things ( like load A address to register R1, add R1,R2 and store result to B address ), so there are trade offs everywhere. But it is very deep question, different ISAs, different instruction density both in counts and bytes.
On topic of what is limiting what, there is an interesting option in Linux perf, that one can use to get top down view of limits and their percentages:
perf stat -a --topdown your_app_start_command
WIth recent perf you can see output for your workload.
Roland Quandt: A12 and A12X called Vortex, with part numbers T8020 and T8027 respectively.
https://wccftech.com/apple-a12-part-number-cpu-codename/
http://m.mydrivers.com/newsview/578273.html?ref=
Those claimed part numbers seem odd to me. And where is A11X?
That’s a good point, I forgot that A10X only came out last June, just a few months before A11. That makes sense then.Looks like the a11x might be skipped this time. This would bring the phone and tablet schedules more in sync.
Ie a9x was released shortly after a9, while there was a relatively big delay between a10 and a10x (9 months)
That’s a good point, I forgot that A10X only came out last June, just a few months before A11. That makes sense then.
A12X it is. That would also make for a pretty decent MacBook.
I was thinking a new 12” or 13” (or both) non-Pro MacBook in late summer or in fall, running A12X. I find it very difficult to do anything productive on an iPad, despite what Tim Cook says.A refresh of iPad Pros with the A12X at WWDC next week would be something, seems like that would be too early though for TSMC 7nm.
Last year they released the A10X on 10nm in June too.A refresh of iPad Pros with the A12X at WWDC next week would be something, seems like that would be too early though for TSMC 7nm.
A refresh of iPad Pros with the A12X at WWDC next week would be something, seems like that would be too early though for TSMC 7nm.
Keller is there to establish a standardized SoC design method and interconnect. As it is they're spending a LOT of resources and take way too much time for every single design. Basically he's heading the creation of Intel's version of the Infinity Fabric.That's why Jim Keller is called by Intel... they need to save X86 and he saved AMD. Time to do the same to Intel.
And maybe later is VIA. 3 competitors are always better than only 2.