Excuse my ignorance but what is AVX-512 even supposed to improve? I’ve been hearing about this instruction set since around 2015 and I have yet to hear or see any significant use case for these instructions.
Intel completely disables AVX-512 on Alder Lake after all
271–280 of 317 posts
Re: Intel completely disables AVX-512 on Alder Lake after all
#272Earlier quoted context omitted.
"pretending we can have 512 billion bits of perfect memory sitting around that will never go wrong, because Intel fuse it off on desktop chips" I think computers are now so important to our life, we need to start regulating them like we do cars. Start seriously slapping companies that deliberately or negligently release equipment with obsolete kernels and security holes, mandate ECC like we mandate ABS, mandate part…
My main worry with this sort of thing, is that if we start mandating legal liability, and security becomes a compliance line-item, then companies are going to start locking down everything they ship so they have a legal defense in court. The argument's going to be, "if we are liable for shipping insecure desktops then you shouldn't be allowed to install Linux onto them and then sue us when you get hacked". Think abou…
Just add a physical seal on the product like other dumb electronics do.
Re: Intel completely disables AVX-512 on Alder Lake after all
#273Earlier quoted context omitted.
> I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise. It absolutely wasn't. Look into it. In every case, the blob ends up running on the RAM controller CPU and supposedly finishes running and is done. The whole point of the exercise was obfuscating the process which is used to get to that point such that it avoided the main CPU physically moving the bits of t…
> great, now they either don't know how their own phone Who's "they"? This is an unofficial community wiki.
If it's a random community member then this is just further evidence that the way Librem presented things and what they did confused people into thinking it actually had a practical purpose, when it was purely a way to rules-lawyer their way into getting RYF.
Re: Intel completely disables AVX-512 on Alder Lake after all
#274Excuse my ignorance but what is AVX-512 even supposed to improve? I’ve been hearing about this instruction set since around 2015 and I have yet to hear or see any significant use case for these instructions.
Some crypto miners use it instead of dedicated Asics, its intense cpu processing but at the expense of everything else running through the cpu, its a cludge but Intel have said they are looking at dedicated crypto mining cpu's to maybe get in on the inflated GPU price tags people currently see. I read somewhere Nvidia have even added some features which prevents their GPU's from being used for mining.
AVX-512 is possibly a go-to place for stealth crypto mining for some hackers in server farms.
Re: Intel completely disables AVX-512 on Alder Lake after all
#275Earlier quoted context omitted.
With DDR5 you can have (a form of) ECC on all current 12th-generation Core CPUs. That is, if you were able to find DDR5 DIMMs on the market, which you currently cannot.
Not really: internal ECC in DDR5 is an implementation detail that is neither exposed on the bus nor giving you the real reliability and monitoring capability that real ECC terminated in the memory controller did. It is only there because the error rate would be absolutely horrific without, so you need internal ECC to get to basically the same point you were without ECC on DDR4.
I expect in-chip ECC should still be a significant improvement for RAM reliability (any ECC is going to be better than none, even if your memory array is significantly worse; I've had my share of RAM with weak bits that would absolutely be fixed with that), but it's not going to help with bus errors and isn't nearly as transparent to system software as end to end ECC is.
Re: Intel completely disables AVX-512 on Alder Lake after all
#276Earlier quoted context omitted.
Thing is, you probably wouldn't use most of the AVX-512 instructions even provided. Some of them are ridiculously niche to the point I'd be really curious how anyone has actually used them.
Like which?
Picking one at random from the Intel Intrinsics Guide[0]:
_mm_maskz_dpbusds_epi32 (avx-512 mnemonic "vpdpbusds"):
> Multiply groups of 4 adjacent pairs of unsigned 8-bit integers in a with corresponding signed 8-bit integers in b, producing 4 intermediate signed 16-bit results. Sum these 4 results with the corresponding 32-bit integer in src using signed saturation, and store the packed 32-bit results in dst using zeromask k (elements are zeroed out when the corresponding mask bit is not set).
They are so insanely specific sometimes that I really struggle to know what prompted their inclusion in the first place.
[0] https://www.intel.com/content/www/us/en/docs/intrinsics-guid...
Re: Intel completely disables AVX-512 on Alder Lake after all
#277Earlier quoted context omitted.
Lets compare it to all the other options, shall we? Perfect is the enemy of good, and your uncompromising way of doing things (including not loading microcode 'because it is closed source') is, to put it simple: harmful. And unusual, as well (its not a dealbreaker for many people). The laptop is modular and repairable, just like a Fairphone is modular and repairable. Its a great step forward and, while not perfect an…
...I'm more curious why firmware is even closed source. Seems to me, just releasing the assembler, documentation and a datasheet should be basic courtesy. Then again everything I think that way about is apparently a mortal sin in the business world.
So, the thing is that, in proprietary software development, a lot of stuff is licensed and copied around, because the engineers need to get their jobs done on time. Legal makes sure that everyone actually is working with properly-licensed code (usually), but the definition of "properly-licensed" is going to be in the very narrow definition of "what do we need to license in order to ship the product".
Most of us here think of copyright in the way Disney or Nintendo thinks of copyright: we own the thing, and you don't get to touch the thing. However, to actually get 100% ownership over a copyrighted work, you actually have to make 100% of the work. If you're just buying what you need to make the thing work, then your ownership over the resulting software is going to be thin. After all, the people who sold you the software are going to want to be able to sell it to other people, and in order for that to work, those other people need to not have the software. Which means that all those licenses are going to have provisions on further redistribution so that they still have their copyright monopoly.
If you want to release source, then you have to go back to everyone you bought software from and renegotiate licenses on a far more expensive basis. Because you're asking them to take all the money they will ever make on that software all in one go. For similar reasons, things like licensed music tracks in games are far cheaper if the license is for a limited time, because then the record label can ask for more money later on. The irony of proprietary software development is that it can actually be just as collaborative as Free; but only if every participant regularly pays back into the system.
In contrast, the Free Software world tends to have some of the strictest copyright hygiene in any software industry. You have to, because the whole point is to more or less waive copyright interest in the code - and to do that, you need to have Disney-level ownership over everything. We can thus look at copyright as a sort of deliberate cultural poisoning that puts software developers and artists into the position of having to demand troll tolls everywhere.
Re: Intel completely disables AVX-512 on Alder Lake after all
#278Earlier quoted context omitted.
Like which?
Picking one at random from the Intel Intrinsics Guide[0]: _mm_maskz_dpbusds_epi32 (avx-512 mnemonic "vpdpbusds"): > Multiply groups of 4 adjacent pairs of unsigned 8-bit integers in a with corresponding signed 8-bit integers in b, producing 4 intermediate signed 16-bit results. Sum these 4 results with the corresponding 32-bit integer in src using signed saturation, and store the packed 32-bit results in dst using ze…
That's one of the more useful ones!
It's effectively a low-precision 4-component dot product feeding into an accumulator, which means it is a building block for larger dot products. Large dot products are very useful both in signal processing for FIR filters, as well as machine learning algorithms. The masking is just a bonus available on most AVX-512 operations and lets you do branchless if conditions.
The majority of vectorized routines I've written have used a multiply-add building block like this, including image resizing, audio resampling and low/high pass filtering, and audio/video compression.
Re: Intel completely disables AVX-512 on Alder Lake after all
#279Earlier quoted context omitted.
> Today, only benchmarks and HPC workloads make use of it. From what I've heard, there's also a PS3 emulator that benefits greatly from it and its users are quite annoyed by this [0]. According to the sources, users would need to disable E-cores and preferably HT as well to get the best results, though. Pretty niche and not helpful in general (since disabling up to 50% of the cores/threads doesn't seem great for othe…
> According to the sources, users would need to disable E-cores I don't know the specificis of these CPUs, but it seems likely that _a sane design_ could allow heterogeneous CPU features within a single machine. For example, let's assume two CPU feature sets, E and P. E is a proper subset of P. Further, an E core will issue an "illegal instruction" exception when it encounters an instruction that is undefined on E an…
Actually, iirc the Apple M1 has that x86 memory model thing on P cores only. And macOS must then only schedule x86 processes on those.
Re: Intel completely disables AVX-512 on Alder Lake after all
#280Earlier quoted context omitted.
> Today, only benchmarks and HPC workloads make use of it. From what I've heard, there's also a PS3 emulator that benefits greatly from it and its users are quite annoyed by this [0]. According to the sources, users would need to disable E-cores and preferably HT as well to get the best results, though. Pretty niche and not helpful in general (since disabling up to 50% of the cores/threads doesn't seem great for othe…
> According to the sources, users would need to disable E-cores I don't know the specificis of these CPUs, but it seems likely that _a sane design_ could allow heterogeneous CPU features within a single machine. For example, let's assume two CPU feature sets, E and P. E is a proper subset of P. Further, an E core will issue an "illegal instruction" exception when it encounters an instruction that is undefined on E an…
Although this comes up a half dozen times every time hybrid CPUs and AVX-512 is mentioned, it is not so simple when considering existing x86 software.
Most [1] well-behaved software doesn't simply execute AVX-512 instructions (or any other recent ISA) to see what happens (this would just crash on any non-AVX-512 host), rather they query the ISA capabilities (via CPUID) and if AVX-512 support is reported, they'll use it.
So in your proposal, you need to decide what CPUID is going to report: does it report AVX-512 support, or not? Does it report differently depending on what CPU the CPUID instruction happens to run on? The latter option is a non-starter, because (a) it doesn't make sense and (b) the implied ABI is that CPUID ISA support won't change over the lifetime of a process.
So you are left with reporting AVX-512 on all cores, or none. If you report it on all cores, most processes will execute AVX-512, by the route of a few libc functions which are optimized to use the widest ISA available: so almost everything will end up pinned on the P cores, even if they get little benefit from it. OTOH if you report no AVX-512 support, well-behaved processes won't execute AVX-512 and trigger your dynamic migration in the first place.
Now you can imagine a greenfield where processes are aware of the hybrid nature of CPUs and then things might play out differently: but then you don't need the dynamic migration mechanism at all: since they are aware of what's going on, just have the processes hint to the OS where they should run.
---
[1] One exception is software compiled for a specific target ISA, e.g., -march=avx-512f or whatever. In this case the hybrid system kind of works: you compile your stuff that way if you want it to run on the big cores only, or with a lower-tier ISA if you want it to run everywhere. So it's like an opt-in to big cores w/o having to mess with affinity or other OS hinting.