Years ago, IBM and Freescale had the faith to build a community through POWER and, while not a homerun, that ecosystem still exists today (and I was able to benefit by selling hundreds of thousands/millions of devices powered by PPC/POWER).
Every time I’ve tried to get excited about an Intel product line and build on it - Larrabee, Phi, Itanium - I’ve gotten massively burned. I just can’t trust them.
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.
Xilinx’ Artix-7/Kintex-7 are much more powerful FPGAs and the support for those is getting to be pretty good (DDR3 support is steadily maturing)
It would be nice to see a vendor actually officially supporting these efforts. Maybe one day.
(Not to mention various open source FPGAs - actual chips - being developped)
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?
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).
Gross profit before operating expenses hardly means anything
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.
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.
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.
I think this is https://clearlinux.org/
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.
What makes me sad is not that Intel isn’t a good company - it is. It is that Intel could be an even greater company if it could just get out of its own way.
Personally, I don’t view Microsoft as a consumer company, and Xbox should have been jettisoned after the 360.
Was it the purchase that was the waste, or the subsequent management that wasted the potential?
Anyway, bringing Intel back into the picture; things would be a lot different if Intel hadn't canceled x86 phone chips around the same time Microsoft was hyping Continuum, the converged phone/desktop feature of Windows Mobile 10. If that was launched on x86 phones with win32 apps, it would have been really interesting. And, if they had that ready to go, maybe there would have been internal excitememt about WM10 and it wouldn't have been such a poor showing. Then again, maybe ending their massive QA program wasn't great for quality, either. I still miss windows phone, but there's no going back.
This skepticism could reasonably be extended to x86 as well, given Intel's handling of AVX-512.
The inconsistent support for various subsets of AVX-512, on different processors, makes it hard to predict whether some future processor will have the particular instructions that matter to your software.
If you look at AVX-512's chart on Wikipedia[0], but reorder it into (the discontinued) Xeon Phi, server, and consumer tiers, it's a nice chart showing increasing support as time goes on. For example, -ER, -PF, -4FMAPS, and -4VNNIW weren't really "removed" after Xeon Phi because the server and consumer lines never had them. That chart is just horrible because it tries to show a timeline without clarifying the differences in tiers.
[0]: https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
Vectorization is a niche but GPU programming isn't (shader programming is very popular).
I don't think that's correct.
The compilers I work with do a pretty decent job of auto-vectorizing the inner-most loops of an algorithm, especially if they know the loop bounds at compile-time.