What is old is new again - this is the architecture of the Amiga! And before that the C=64 and the Atari 800.
FMA (3) with Haswell in 2013 https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_op...
SSE4.2 with Nehalem in 2008 https://en.wikipedia.org/wiki/Nehalem_(microarchitecture)
AES in 2008 https://en.wikipedia.org/wiki/AES_instruction_set
SHA in 2013 https://en.wikipedia.org/wiki/Intel_SHA_extensions
>even the x64 extensions were designed by AMD.
AMD (not working solo) has published the spec in 2000, AMD, Intel, VIA and a few others have a pretty different implementation of that spec, Intel's x64 extension is drastically different than AMD's implementation.
Intel has been adding new extensions with virtually every generation, just look at how many generation of virtualization support extensions we've had.
>the few projects for breaking out of their box failed (Ithanium, Larrabee).
Itanium died because the industry didn't want to take a "RISC" (;)).
Larrabee isn't dead, in fact it is very much alive it is just inside your CPU, the AVX extension set and the silicon that supports are Larrabee's vector processing units. Intel just more or less had the insight to see that Larrabee won't go anywhere really and they can shrink it and implement it into every CPU within a few years.
Larrabee was interesting but it was not here and not there, Intel went to implement the good parts of it into each of their own CPU's and for HPC/GPGPU like computing it went a different way by releasing the Xeon-Phi.
>And also: why are there no Intel chips yet who include all the nice things USB-C can offer to the market? E.g. Thunderbolt, newest DisplayPort.
This just shows your utter lack of understanding of the technology landscape. I was tempted to cynically ask you about what version of Thunderbolt you have on your non-Intel machine to see if you fall for it, but alas I don't want to spread misinformation.
USB-C doesn't bring Thunderbolt not Displayport to the market, USB-C can be mechanically compatible with those 2. Thunderbolt is Intel's proprietary technology and its upto the system integrator to decide if they want to implement it or not, don't buy cheap ass laptops get the latest thunderbolt.
As for displayport could you please tell me what is the "latest"? if it is 1.4 there isn't a single desktop GPU that "technically" supports it yet, even the GTX 1080 is only certified for 1.2 (and in theory can support 1.3/1.4 but ink on the specs isn't dry yet and the certification process is well meh). Thunderbolt 3 is the only current interface that is actually certified for DP1.3, it should probably support DP1.4 but the spec was only finalized in march this year so....
So yeah...
It was great at highly parallel benchmarks, but much slower than contemporary x86 (the P4, which wasn't that great either) for everything else.
As for the performance I don't have enough experience to pinpoint exactly all the problems, but i think it really ended up being a software issue.
Most complaints I've encountered were about the "emulation" part with the dynamic translation libraries and instruction set emulation.
Overall it seems to me like they just tried to tackle too many things, have some compatibility with X86, take on SPARC/POWERPC and do HPC, mainframes and tons of other applications at the same time.
That said after all this is still a mid 90's ISA for a very niche market with all these issues its surprising it lasted so long, I never understood why HP kept paying Intel to produce these chips in the first place.
I used to work with a group of scientists who wanted as much performance as they eke out. They had a large C codebase which had already been ported to every major architecture and it did a ton of floating point math along with a fair amount of integer work, etc. — basically the best-case scenario for IA-64. Unfortunately, even with Intel's compiler and tuning tools the performance just never panned out: the best-case scenario was that if someone wanted to divert years of staff time into tuning, IA-64 might take the performance crown but that would be an expensive gamble and probably locking ourselves into a single server vendor (HP). It was much safer to simply take that time and money and buy x86-64 boxes which were faster and available from many vendors. (The same story repeated later with Cell: neat possibilities but nowhere near enough benefit to justify the risk of locking in to a single vendor architecture with an unclear future)
Ignoring the architectural debates, Intel made two fatal implementation mistakes with IA-64: the most obvious one was never finding a deadline they couldn't miss but a less obvious problem was failing to take software, and particularly open-source software, seriously enough. IA-64 performance critically depended on using Intel's proprietary compilers. Since those were extremely expensive, almost nobody used them and thus they had compatibility issues with many large Unix or Windows codebases, and the focus was clearly on the optimizations needed to deliver good SPEC benchmark results rather than other features.
I don't know how much difference it would have made in the end but I think having a solid open-source or at least free toolchain would have made it less expensive to try the platform. It's very easy to imagine that it would have gone considerably differently had something like LLVM existed back then and Intel had simply contributed a high-quality backend, not to mention having a broad general shell server program for open-source projects to use to port and optimize.
I'm not defending IA-64 overall it had issues, but it wasn't as bad as some people claim it to be "OMG INTEL CAN'T DO X64 THEY SUCK".
Intel also took quite a long time to bring Itanium CPU's to the forefront of Intel's own technology, Itanium got DDR3 and QPI only in 2010. By the time Intel brought all the good things to Itanium it was pretty much already dead in the water and on life support, but doesn't really bare on the viability of the IA-64 as an architecture it more or less bares on the viability of the Itanium as a product line.
As far as the architecture goes, the main conclusion I draw is that VLIW was a plausible idea but failed because it overestimated the amount of instruction-level parallelism and perhaps because it assumed too much of compilers. The GPU world has massive parallelism, enormous market volume, and the toolchains are more advanced, but even there AMD went from the VLIW-style TeraScale design to a RISC-style Graphics Core Next to compete with nVidia's RISC-y Tesla. It definitely seems reasonable to ask whether VLIW is an evolutionary dead-end.
They underestimated how difficult it would be to produce competitive execution scheduling at compile-time in software.
The manager behind this decision, Rick Belluzzo, jumped ship and got a sweet job at Microsoft.
Ithanium failed, because first it was delayed several years, got very expensive and power hungry. For a while it had quite a good performance, but due to the price it gained only a little foothold in the very expensive workstation market. The final nail in the coffin was, that the Opteron really launched the x86 based server marked. With the Opteron companies would for the first time replace Sparc etc. in the middle range servers. And when Intel also offered x64 chips the risk server market started to fade.
I am not buying cheap ass laptops. But a lot of Apple laptops are held back by having to include extra chips for supporting thunder bolt, while this feature is promised for one of the next Intel cpu generations as being included into the cpu. Had the plain MacBook Thunderbolt via USB-C it would be more useful
Intel was planning to license the AMD64 ISA directly from AMD for Yamhill however that did not happen and they've ended implementing the spec on their own with their own ISA.
Intel's X86_64 ISA is actually quite different than AMD's implementation, and funny enough neither of those are actually 100% in line with the original spec. The spec was published because it was an extension of the X86 instruction set, not a replacement, the x86 instruction set is available to AMD through the cross license deal they have with Intel.
>I am not buying cheap ass laptops. But a lot of Apple laptops are held back by having to include extra chips for supporting thunder bolt, while this feature is promised for one of the next Intel cpu generations as being included into the cpu. Had the plain MacBook Thunderbolt via USB-C it would be more useful
Thunderbolt will always require additional chips (just like displayport, usb, and any other port on your computer), this is how the spec works, it was never designed to be implemented on die on the CPU. USB-C has nothing to do with Thunderbolt and vise versa, there is a mechanical compatibility standard that allows you to use the same physical port for Thunderbolt and USB via the type C connector. This isn't any different than Thunderbolt using the Mini-Display port mechanical standard. Thunderbolt has multiple mechanical standards including over a dedicated TB electrical port, a fiber optic port, DP electrical port, and USB-C electrical port.
Nothing Intel is doing is holding Apple back, the reason why Thunderbolt 3 isn't available on Apple laptops yet is because Apple is 2-3 generations behind, the mid 2015 Macbook pro is using a 4th gen haswell CPU.
http://www.eweek.com/servers/intel-begins-shipping-xeon-chip...
In parallel, though, we also saw mainframes use a similar trick. Their usage was more narrow, though.
I wouldn't call an architecture this way if it proves very difficult to extend without strongly breaking compatibility.
If it was, though, we might potentially resolve the issue if there's a standard API for various things where the implementation can be ignored (and improved w/ SW or HW). Modern example of an Amiga-like architecture might be Microsoft's DirectX techs where there's API's for networking, I/O, audio, and video. Any of those might have been accelerated with dedicated coprocessors with apps looking the same. At least one or two were in practice.
Likewise, the programming model might obviate the need for this consideration. One where they were tasks called as needed by a control code w/ optional acceleration might mean just the control code or OS interface needs to change per release or platform.