Last week I wrote about Intel aiming to remove Xeon Phi support in GCC 15 with the products being end-of-life and deprecated in GCC 14. While some openly wondered whether the open-source community would allow it given the Xeon Phi accelerators were available to buy just a few years ago and at some very low prices going back years so some potentially finding use still out of them especially during this AI boom (and still readily available to buy used for around ~$50 USD), today the Intel Xeon Phi support was indeed removed.
↫ Michael Larabel
Xeon Phi PCIe cards are incredibly cheap on eBay, and every now and then my mouse hovers over the buy button – but I always realise just in time that the cards have become quite difficult to use, since support for them, already sparse to begin with, is only getting worse by the day. Support for them was already removed in Linux 5.10, and now GCC is pulling he plug too, so the only option is to keep using old kernels, or pass the card on to a VM running an older Linux kernel version, which is a lot of headache for what is essentially a weird toy for nerds at this point.
GCC 15 will also, sadly, remove support for Itanium, which, as I’ve said before, is a huge disgrace and a grave mistake. Itanium is the future, and will stomp all over crappy architectures like x86 and ARM. With this deprecation, GCC relegates itself to the dustbin of history.
If someone can find a way to use the Phi as a games accelerator in some capacity, they might sell as hotcakes.
Is this sarcasm?
Thom Holwerda,
(It took several attempts at gaslighting chatgpt to generate this output, great stuff though, haha)
Wow, crazy.
You’re a master of this ChatGPT puppet.
Nico57,
Trying to make it fail is quite fascinating actually. It really didn’t want to say it and the responses were mostly in the vein of polite disagreement. But with practice and sufficient constraints, it will obey to the point of producing what I quoted.
Fun. Without resorting to AI, I did something similar, yet way less verbose, for the 68000 CPU family. As if we took another history path where it became dominant and crushed all competition with incredible progress and stunning features.
Thom Holwerda,
This is indeed the problem. It doesn’t matter whether this hardware is capable or not, it was left out of the software ecosystem and that’s what is most important. These might have had a chance if they could support cuda but without software it’s very hard to see how a newcomer would be able to make a dent in the market.
Perhaps an Itanium-like architecture would suit well nowadays’ GPUs.
It did serve them well durring AMD TerraScale era. Then Nvidia invented something better (wavefronts) an AMD followed the suit.
Interesingly, Raspberry PI GPU is vliw and it machine code have been fully documented and it can be programmed directly in it.
The most interesting evolution of VLIW architecture is the Belt Architecture of the experimental Mill CPU. Though (as I guess expected) the inventors have stuck on developing a decent compiler back-end for it.
Just about every major modern GPU is implemented using some form of VLIW/LIW.
It was only discontinued in 2020. That’s an incredibly short support cycle for such (at market price) expensive kit.
I know the kernal has switch to shorter LTS, but is this now the consequence playing out? The dropping of support of hardware so quickly just compounds e-waste on what is still perfectly functional equipment.
Well, the results I saw some years ago not only showed Nvidia beating by large margins Intel offerings of that time by performance, but also being more efficient. Add to this the ecosystem, and what is left is even more insult to injury.
I guess, for those that are really invested on tasks with insane demand for performance, the target for this kind of product, purchase price advantage is/was not the main factor to pick one, as it would pale when you consider the cost of operation. So TCO was not on Intel side, nor was performance.
I, probably, would not buy one today, even by current low prices, as GPUs have an insane level of performance currently.
For quick comparison (note: Phi’s median performance was half of K40, or it was said to be so, of course, depends on the task on hand):
https://ambermd.org/gpus16/benchmarks.htm#Benchmarks
https://ambermd.org/GPUPerformance.php
I know that any article on Itanium requires the journalist to insert the usual snarky tropes, but for an article not even about the processor family to contain the same suggests, shall we say, an unhealthy obsession?
Intel was right to try and sunset its x86 ISA. Any ridicule should be directed at Intel for their hubris not to open the standard and bring others onboard with the transition and at AMD’s for dragging x86 intro the 64 bit era, not the engineering of the processor itself.
As Russia continues developing its Elbrus series and makes a success of their own VLIW, it might not be too late to open Itanium standard.
Calling Elbrus a “success” is a fascinating misunderstanding of the word’s meaning
Elbrus and Itanium *are* successes on a technical level. Sure IA-64 (the instruction set behind Itanium) did not realize Intel’s aspirations of succeeding x86 but that is not to take away from it having two decades of production and being quite performant with its native code in the days it was being invested in.
Elbrus is the offspring of chips whose lineage is said to have inspired IA-64. No we won’t hear much of it due to politics,which is unfortunate because even though Russia has a smaller economy than Italy they have managed to make VLIW work for them which counts as success I think.
I’m sure you would tell me Loonsong is a failure too, because it is less good at gaming than the latest AMD wunderchip. Again, I argue it is successful because – like the Russians – the Chinese made it work for their needs, which is all any product needs to do. Although you could argue that despite the vastly greater Chinese industrial base theirs is less ambitious than the Elbrus being only a MIPS evolution.
Larrabee was a brain dead idea. Normal Xeon CPUs offset the x86 complexity by massive transistor budgets per core. This project came from realization that massively duplicating x86 decoder (4×70) at cost of OOO book keeping units could be considered a good idea.
FWIW, the Xeon Phis are relatively easy to work with, and they don’t really require much software support. Since they are just a bunch of in-order x86 cores. All the “magic” is done using MPI calls. So if you already have x86 code that runs through MPI, you’re golden. At least that was the original idea of their approach.
gcc 15 wouldn’t make much of a difference, since the cores within the Xeon Phi are relatively ancient, so there is not going to be much extra performance to be extracted anyways.
In any case, the Xeon Phis were geared more towards instruction parallel workloads, so they are a cheap way to recreate a small cluster of x86 cores.