Andrei Alexandrescu needs to read this
rikki cattermole
rikki at cattermole.co.nz
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