Andrei Alexandrescu needs to read this

rikki cattermole rikki at
Sun Oct 27 23:03:31 UTC 2019

On 28/10/2019 9:39 AM, drug wrote:
> 27.10.2019 23:11, Mark пишет:
>> On Wednesday, 23 October 2019 at 23:51:16 UTC, H. S. Teoh wrote:
>>> Another recent development is the occasional divergence of 
>>> performance characteristics of CPUs across members of the same 
>>> family, i.e., the same instruction on two different CPU models may 
>>> perform quite differently.  Meaning that this sort of low-level 
>>> optimization is really best left to the optimizer to optimize for the 
>>> actual target CPU, rather than to choose a fixed series of 
>>> instructions in an asm block that may perform poorly on some CPUs.  
>>> (This is also where JIT compilation can win over static compilation, 
>>> if you ship a generic binary that isn't specifically targeted for the 
>>> customer's CPU model.)
>>> T
>> Would it be reasonable to say that modern CPUs basically do JIT 
>> compilation of assembly instructions? Or at the very least, that they 
>> have a built-in "runtime" that is responsible for all that ILP magic - 
>> cache policy algorithms, MESI protocol, the branch predictor and so 
>> on. If so, you could argue that the Itanium was an attempt to avoid 
>> this "runtime" and transfer all these responsibilities to the compiler 
>> and/or programmer. Not a very successful one, apparently.
>> It is also a bit analogous to the GC vs. deterministic manual memory 
>> management debate.
> Wasn't Itanium fail be caused that AMD suggested another architecture 
> that was capable to run existing software while in case of Itanium users 
> was forced to recompile their source code? So Itanium failed just 
> because it was incompatible to x86?

Intel created Itanium.
AMD instead created AMD64 aka x86_64.

More information about the Digitalmars-d mailing list