[bananaquant]

Quite unsurprisingly, this distribution has no support for ARM: https://software.intel.com/content/www/us/en/develop/article...

I once was excited about Intel releasing their own Linux distro (Clear Linux), but it has the same problem. It looks like Intel is trying to make custom optimized versions of popular open-source projects just to get people to use their CPUs, as they lose their leadership in hardware.

[mumblemumble]

I'm not sure I see why you would expect anything different? The entire point of this framework is to provide a bunch of tools for squeezing the most you can out of SSE, which is specific to x86.

I don't know if there's an ARM-specific equivalent, but, if you want to use TensorFlow or PyTorch or whatever on ARM, they'll work quite happily with the Free Software implementations of BLAS & friends. If you code at an appropriately high level, the nice thing about these libraries is that you get to have vendor-specific optimizations without having to code against vendor-specific APIs. Which is great. I sincerely wish I had that for the vector-optimized code I was writing 20 years ago. In any case, if ARM Holdings or a licensee wants to code up their own optimized libraries that speak the same standard APIs (and assuming they haven't already), that would be awesome, too. The more the merrier. How about we all get in on the vendor-optimized libraries for standard APIs bandwagon. Who doesn't want all the vendor-specific optimizations without all the vendor lock-in?

Alternatively, if you would rather get really good and locked in to a specific vendor, you could opt instead to spam the CUDA button. That's a popular (and, as far as I'm concerned, valid, if not necessarily suited to my personal taste) option, too.

[smoldesu]

"Their" CPUs meaning x86 platforms, in this case.

Plus, who's surprised? This is how Intel makes money. The consumer segment is a plaything for them, the real high-rollers are in the server segment, where they butter them up with fancy technology and the finest digital linens. Is it dumb? A little, but it's hardly a "problem" unless you intended to ship this software on first-party hardware which, hint-hint, the license forbids in the first place.

At the end of the day, this doesn't really irk me. I can buy a compatible processor for less than $50, that's accessible enough.

[stonemetal12]

No, Their CPUs as in ones from Intel. Intel has long done a thing in their compilers where they detect the CPU model, and run less optimized code if it isn't Intel. They claim it is because they can't be sure "Other" processors have correctly implemented SSE and other extensions. So Intel Linux is going to run faster on an Intel CPU because it was compiled with ICC.

[zorgmonkey]

I don't know much about it, but Intel's clear linux does not use icc this is in their FAQ https://docs.01.org/clearlinux/latest/FAQ/index.html#does-it...

[Sanguinaire]

This is trivially easy to defeat, just so you know. If anyone reading is ever in need of optimized math library performance on AMD, just speak to your hardware/cloud vendor; they all know the tricks.

[klelatti]

Link says Core Gen 10 or Xeon so you may be out of luck on AMD or at less than $50.

I think this is more likely aimed at AMD than Arm - don't think Arm is yet a threat in this space - and whilst they're entitled to do what they want it does make me less enthused about Intel and frankly more likely to support their competitors.

[mumblemumble]

AMD has their own equivalent: https://developer.amd.com/amd-aocl/

I'm not sure it's a sin for hardware manufacturers to support their products? In the days of yore, we even expected it of them.

[klelatti]

Not a sin but it's not really just about supporting (or optimising) their products, its about doing so whilst trying to increase the lock-in beyond what is achieved on performance grounds alone.

I may be wrong but my experience is that AMD has been a bit better on this is the past e.g their OpenCL libraries supported both Intel and AMD whereas Intel's were Intel only.

[mumblemumble]

I would assume that's not entirely a fair comparison, though. Intel's 3D acceleration hardware only ever appears in Intel-manufactured chipsets, which only ever contain Intel-manufactured CPUs.

AMD, on the other hand, also supplies Radeon GPUs for use with Intel CPUs. For example, that's the setup in the computer on which I'm typing this.

So I have a hard time seeing anything nefarious there. The one is obviously a business necessity, while the other would obviously be silly. Perhaps that changes with the new Xe GPUs?

[klelatti]

Sorry, should have been clearer - Intel's CPU OpenCL drivers only supported Intel and not AMD whereas the AMD's CPU OpenCL drivers supported both - so GPUs not relevant in this case.

I can see how if you've invested a lot in software you'd like to get a competitive advantage over your nearest rival so maybe a price we have to pay.

[gnufx]

Yes. The difference is that may be "theirs", but I think it's all free software. At least the linear algebra stuff is. They supply changes for BLIS (which seem not to get included for ages). Their changes may well be relevant to Haswell, for instance. I don't remember what the difference in implementation was for Zen and Haswell, but they were roughly the same code at one time.

[vel0city]

I wonder what features are missing from a Comet Lake generation Pentium, those can be had for ~$70 these days. Other than the feature of the box says "Core" on it instead of "Pentium".

EDIT: Ah, I found it, AVX2.

[mistrial9]

the capital model for cost recovery and earnings is one thing, but in the modern times, the amount of money that flows through Intel Inc. is not the same thing. Intel played dirty for long years to crush competitors, not "make money" like they need it.. "Greed is good" - remember that ? so, no.. apologists count your quarterly dividends but you have no platform for social advocacy here IMO

[gnufx]

Clear Linux looked unconvincing to me. When I looked at their write-up, the example of what they say they do with vectorization was FFTW. That depends on hand-coded machine-specific stuff for speed, and the example was actually for the testing harness, i.e. quite irrelevant. I did actually run the patching script for amusement.

[mhh__]

Alder Lake looks seriously impressive if the rumoured performance is even close to accurate, so I wouldn't count them out just yet - that being said, they will never get a run like they did over the last 10 years again.