Exactly the same experience here. At encouragement of intel contacts, we went into Intel (ex-Altera) FPGA last year, with the oneAPI push and programming the FPGA cards with SYCL being free.
The cards are now discontinued (but still sold), the drivers don't work on any distro more recent than 2018 - even though the oneAPI toolkit itself requires a more recent OS; the only non-discontinued replacements require software ecosystem license purchase, it's impossible to download the older (working) versions of the toolkit, and the contacts stopped talking to us once we actually bought the cards.
Add to that the constant show-stopping compiler bugs and toolkit issues that made it feel like we were the only people actively using it, I think we've learned to run far, far away now.
I have been burnt by the sockit board. I move away from wanting to learn fpga after all the bushit. All fgpa vendors are similar as far as I'm concerned.
Open source FPGA toolchains begin to appear, mostly on the low-end for now. And because all FPGA vendors are doing such a terrible job for tooling, Yosys and friends are likely the future.
Treat them as purely hardware vendors and go open source tooling. The tooling is infinitely superior from a ux point of view. There are still quite a bit of missing features but it is getting there.
We've heard positive opinions of the Xilinx boards and tooling. At least, not having everything about the HLS tooling either changed or syntax deprecated every three months.
Well that's because Intel has nothing but beancounters milking it for bonuses and stock options running it. This is not news to anyone who watches Intel for the last couple decades.
Things like this require vision, patience, investment, outreach. Things that Intel is all horrible at. They are a monopoly that wants to sit in their executive suites and ship out N+1 Moore's Law chip. Engineers? Keep them in the other buildings, and avoid them as much as possible.
Intel made, what 10 billion in PROFITS last year? With a "B". And times have been semi-lean the last few years. We are talking about a monopoly that could have invested 50 billion dollars (current dollar adjusted) in the overall OSS and alternate computing platform over the last 40 years.
Intel should have:
- a production linux distribution highlighting their hardware features with wide support for x86. This should have happened 25 years ago. Keep Microsoft's feet to the flame. Sure, charge money for it, who cares if it doesn't sell. It keeps Microsoft actively utilizing your hardware, which Intel has always had a problem with.
- Hell, at this point, they should be funding ReactOS, whatever Beos got open sourced as, one/some of the BSDs, OpenSolaris. Redox. All of it. They should be very very interested in getting as many x86 machines and x86 peripherals running anywhere they can. The writing is on the wall with the M1/M2 -- Microsoft will go ARM hardcore if Qualcomm or AMD crank out a M1/M2 competitor that is superior to x86. Intel is being stupid if they aren't covering their bases with OSS OSes.
- get off your asses and get x86 on a mobile device and embedded. This is related to support of other operating systems. x86 can run in so many embedded and mobile, but because Intel didn't have the OS support flexibility, it hamstrings moving x86 and their silicon into non-Windows non-PC areas.
- one thing (I guess) that Intel does well software-wise is their compilers. Why are these expensive? Why do they cost anything at all? This is related to OS support and lots of computing platforms besides PCs. If the compilers and tools were free, there was good support of OSs in lots of different computing platforms, Intel would have good diversification.
- a competitive discrete graphics card. You're telling me AMD and NVidia can do this, but you can't? Seriously? It's not silicon, I highly doubt that. What it probably is ... Intel just doesn't like talking to software people, and games software? You don't need the best, but you can certainly do better than the IGP afterthoughts they do provide.
- why exactly does Samsung have dominance in SSDs? Like, didn't Intel invent them?
Intel might be a lost cause on the mobile phone market. You know why they missed that so bad?
#1 reason: they didn't have sufficient outreach in Linux, if they did, they'd probably have been the preferred architecture of the devs
#2 reason: of course related to that, they didn't have support in non-PC computing platforms. If they supported more semi-embedded (even if pure embedded wasn't a good match for x86), then they'd have been ready for the emerging devices that became the smartphone.
You know what? So much of what I just explained applies to AMD too, although they probably are more willing to support non-x86/ARM/RISC-V. AMD now has a billion or two a year to do OS outreach and better compiler tools and all that. And with OS outreach, you can make sure the code generated isn't Intel-optimized, like Intel loves to do. Your OS support, Your drivers can be AMD optimized.
I get AMD has been severely revenue constrained for about a decade when they sat on their asses when Intel was being dumb with Netburst, but AMD is somewhat back on top. Will AMD sit on their hands again?
> Intel made, what 10 billion in PROFITS last year? With a "B". And times have been semi-lean the last few years.
There are multiple measures of profit, but none of them are $10B.
Per the 10-K for 2022, Intel's operating income was $2.3B and their net income was $8B. Net Income was higher than Operating Income because Intel had gains in equity holdings, interest payments, and favorable tax treatment. Put another way, 3/4 of the year's bottom line profitability was not from building and selling things.
It should also be noted that almost all of their profits were in Q1. Q2 and Q4 actually had negative income (both operational and net). A big part of that is due to aggressive investments in advancing their fab capabilities (which is a multiyear process that wont deliver much outside the lab until 2024/25).
Intel could simply invest in sublinear deep learning.
CPU have a significant advantage over GPUs that they have more main memory. The larger your model is, and the smaller the memory of each individual compute node is, the more time is spent moving data around.
You might object that dense machine learning is mostly compute bound on CPUs but that isn't true. You can use sparse learning algorithms with sublinear complexity. In fact, the papers often show something extremely counter intuitive. The performance is memory bound at low thread counts and is compute bound at high thread counts!
I don't know the details but I suspect that when you have sparse data, your cores spend a significant amount of the time chasing pointers and this means as you add more cores, more and more of the pointers you are chasing have already been loaded into the cache by a different core.
One problem with this strategy is that Intel has super linear pricing on their high core count CPUs. The 24 core CPUs might be cheaper than an Nvidia GPU but the 40 core CPUs cost 1x to 3x as much as Nvidia GPUs depending on whether you want a single, dual or quad socket setup and in this case you obviously always want to go quad socket so intel may not be cost effective unless you want to train models that need TBs of RAM.
Intel's new ARC cards are a clear step in that direction. Their leadership also seems to be targeting a fully Vulkan / post OpenGL + post DirectX world. It's why the drivers are so big, the hardware only supports the modern methods and anything reliant on the old process requires a compatibility layer.
They didn't fail embedded for lack of trying. Their offering needed WAY too much silicon and power to provide the same computing power as a smaller ARM chip. This may be fundamental to x86 - there's so much cruft in the instruction set that you need a huge chunk of silicon to decode it.
> x86 - there's so much cruft in the instruction set that you need a huge chunk of silicon to decode it.
This is largely a myth. The actual power overhead of the x86 decoder compared to the entire chip is something like 4%, and keep in mind that ARM has a decoder too! I'm not sure what the power requirement of that is, but it has got to be at least 1-2%.
Put it another way: if you just look at the logic layout of a modern chip, the 4-8 cores take up a fraction of the total area, and then most of that is the AVX vector units and the cache! The decoders are tiny in terms of area, and chips generally speaking use power roughly proportional to area.
People think of Apple's M1 chips as demonstrating ARM's superiority, but in fact that just demonstrates the superiority of TSMC's bleeding-edge process.
Current-gen AMD Zen 4 processor cores are faster than M1, and are more power efficient, it's just that they're optimised for desktop PCs instead of laptops.
Of course, the ARM architecture does have a few benefits. Chief amongst them is the relaxed memory consistency model, which reduces the overheads of instruction retirement (the "back-end" of processors). This benefit scales with the number of processor cores, but that hasn't seemed to have to stopped both Intel and AMD planning for CPU with over 256 hardware threads anyway in the near future.
You are definitely not thinking with embedded in mind. Everything you said applied perfectly to server chips, but not to the embedded world. The Silicon and power budgets are MUCH tighter and allocated very differently in embedded chips than in server CPUs.
Most of the area on those chips isn't cache, or even memory. It's actually mostly peripherals, with significant area spent on the core itself. And there's a lot less Silicon total - a 7x7 mm die (50 square mm) is a huge embedded chip. Silicon spent on cores, even a tiny bit, is functionality your chip doesn't have.
The cards are now discontinued (but still sold), the drivers don't work on any distro more recent than 2018 - even though the oneAPI toolkit itself requires a more recent OS; the only non-discontinued replacements require software ecosystem license purchase, it's impossible to download the older (working) versions of the toolkit, and the contacts stopped talking to us once we actually bought the cards.
Add to that the constant show-stopping compiler bugs and toolkit issues that made it feel like we were the only people actively using it, I think we've learned to run far, far away now.