I've voiced this before but I think AVX-512 is completely irrelevant in the consumer space (which imho makes titles like "Intel artificially slows 12th gen down" incredulous). Even for commercial applications - sure there are some things that benefit from it. On the other hand, I work in HPC and even in (commercial, not nuke simulations or whatever the nuke powers do with their supercomputers) HPC applications AVX-512 is rarely used.
Also... AVX-512 was never announced for 12th gen. No one claimed it was there, would work, would be stable or anything to that tune. No one should have had an expectation that a 12th gen CPU would do AVX-512 (and no one did). Intel even explicitly said pre-launch that it won't do AVX-512. Some people found post-launch that some BIOSes allow you to turn the E-cores off and that causes AVX-512 to be detected. IIRC not even the BIOS option claimed anything about AVX-512.
There are a lot one can criticize about Intel. Many low hanging fruits. This isn't one of them.
It is irrelevant because it is not wide-spread.
AVX-512 is much nicer to program than nay previous Intel's vector instructions.
It will be relevant if programmer could assume, that 50% of her auditory has CPU with AVX-512.
If I want to play with it (as programmer who is interested in DSP on generic-purpose hardware) I need to rent special cloud instance for very non-hobby-friendly price. Additionally, benchamrks (of algorithms, not hardware) at shared instance is never good idea.
I have old (but fast enough for most my tasks) i7-6700K at my desk now, and I've hoped to upgrade it to something with full AVX-512, but alas. What is cheapest way to have local AVX-512 capable system (I know about exotic, low-power i3-8121U, lets ignore it)?
Unless developers will be able to buy reasonable-priced (think: current i5/i7 non-extreme prices, middle-level MoBo, not low-end, but not gaming or server one) system, AVX-512 will be completely irrelevant.
Yes, GPUGP is affordable now (or not? Prices for video cards are insane!), but not all tasks goes well with GPUGP, where transaction cost is insane (memory is slow, but PCIe is much slower and has much larger latency).
Update: And no, I don't need any "effective" cores at my desktop, thank you. I'm not sure, I need it on my laptop, either, but I'm pretty sure about my desktop.
> I've voiced this before but I think AVX-512 is completely irrelevant in the consumer spac
Don’t forget that reviewers made a huge deal out of the fact that CPUs downclock themselves when running AVX instructions.
Several reviewers tried to make this into some sort of scandal at the time, which I’d guess contributed to Intel wanting to remove the feature from consumer CPUs.
Of course, many of those same reviewers are now capitalizing on Intel removing AVX-512 support while ignoring the fact that you had to disable all of the efficiency cores if you wanted that feature (worsening thermals and performance in non-AVX) workloads.
> Don’t forget that reviewers made a huge deal out of the fact that CPUs downclock themselves when running AVX instructions.
It was and is kinda a huge deal. I followed the development of Corona Renderer for the past decade closely and one reoccuring theme with conflicting evidence was whether the inclusion of AVX was beneficial or detremental to performance due to resulting down clocking on certain platforms.
And surprisingly, now quickly looking through the search function, of the corona renderer forum an update apparently even dropped AVX because of better performance. ( https://forum.corona-renderer.com/index.php?topic=33889.msg1... ) Though I wonder if this is accurate or if the post is missing context...
To me, it does seem really weird that they opted to downclock the entire CPU rather than increase the latency of the instructions that caused overheating. That feels like it would have been a much less disruptive solution that would work strictly better.
If you increase latency, the ROB fills up quicker, and could get full which would back up the pipe. It makes sense why they’d choose to use the default “downclock on overheat” rather than add more circuitry to deal with that specific issue.
When the first AVX instruction is run after a long period of no AVX, something like this does happen: the dispatch of instructions is throttled to 1 out of 4 cycles while some AVX instruction is in the scheduler (this applies to all instructions, not just AVX).
This is severe restriction: even if could be limited to AVX instructions, running at 25% of the throughput would make AVX pretty useless.
This state persists only for a short time until a voltage and possibly frequency transition can be made at which point everything can run at full speed (albeit sometimes at a reduce frequency).
BCD instructions were ubiquitous from the 8086 to the last x86-32 processor, but were so rarely used they weren't extended to 64-bits on x86-64 even though 'backward compatibility' was considered critical. So...probably more complicated.
I could absolutely make a good use of AVX-512 for a lot of applications, including consumer space. It's even better than AVX2 when it comes to flexibility, and of course, it's double width.
Of course because of lower clock speed and the associated penalties limit it a bit. But you can work around those limitations, for example perhaps by dynamically switching between AVX2 and AVX-512 paths depending on workload.
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.
> 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.
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.
Huh, TIL. Would you say that most AVX-512 instructions are then useful in such applications? Given Intel's history of inventing less than useful things (segmented memory, for example) I figured AVX-512 was mostly useless.
Well, segmented memory was a pain in the butt but was useful at the time -- not to mention _way_ less of a pain than bank-switched memory.
The applications that I mentioned wouldn't use all of AVX-512, but once you're familiar with vectorization it's not hard to tell what they are meant to be used for. CPU designers don't spend silicon on instructions that don't have a use, and AVX-512 does a lot to round out the vector instruction set to make it orthogonal and have less special cases.
The bad cases tend to be from instructions that are either too slow or are side effects of the general design. The horizontal add instructions in SSE4, for instance, would have been useful except that they were just as slow as manually doing the shuffles and adds yourself. AVX/AVX2 extended a bunch of SSE2-4 instructions to 256-bit by replicating them across lanes, which led to borderline useless forms like PALIGNR shifting within each 128-bit lane instead of across the entire vector. AVX-512 looks pretty good here though I have seen data about some mask operations being slow, not to mention the whole "slows down the whole chip" issue.
That having been said, it's hard to argue that AVX-512 _isn't_ mostly useless, if for no other reason than it being mostly unavailable. Baseline AVX-512 has a market penetration of only 5.6% in the Steam hardware survey and Intel shipping their latest chip without officially supporting it isn't going to help that. Only niche software can afford to use it right now.
> On the other hand, I work in HPC and even in (commercial, not nuke simulations or whatever the nuke powers do with their supercomputers) HPC applications AVX-512 is rarely used.
Even in the nuke simulations it is rarely used. More recent cores might be better, but the frequency drop and the associated latency kill performances on the clusters I know. And the new generation ones are AMD anyway.
As ever, it depends, probably on whether your code is dominated by matrix-matrix linear algebra. BLIS DGEMM on my SKX workstation runs at ~88GF, or ~48 if I restrict it to using the haswell configuration (somewhat different on a typical compute node).
But yes, I'd rather have twice the cores and memory bandwidth with AVX2. For those that don't know: non-benchmark code usually doesn't get close to peak floating point performance, constrained by memory bandwidth and/or inter-node communication. Everyone is trying to get the compute performance from GPUs anyway.
Sure, there are gains if the code is right and the density of AVX instructions is high enough. In most cases that’s not really the case as these dense matrix multiplications are part of a larger algorithm, which includes things like time integration and some calculations that are not straightforward matrix products. The logic is also more complex. The state changes and reduced frequency caused by AVX-512 make the tradeoff difficult.
And as you say, if you have to redesign the code you might as well do it for a GPU that does not have the same issues.
I agree it's difficult. Do people ever just turn off the AVX512 in their BLAS, FFT, etc. because of throttling? I've never seen that, but then I usually don't see people measure anything usefully, if they even know the effect.
For varying mileage, I'm more familiar with, say, molecular dynamics codes, where Gromacs, for instance, has its own hand-tuned avx512 in places, and cp2k might use it at least for FFT, small matrices (libxsmm) and eigenfunctions (ELPA), as well as BLAS. Elsewhere, some R applications (on the desktop in this context) might hit BLAS heavily.
I should have made the point that there's avx512 and avx512, for people who don't know. At least GCC and LLVM -march=native does half-width SIMD on SKX et al because of throttling. If you wonder where a factor of two went, -mprefer-vector-width=512 might help.
Your applications don't do linear algebra or FFT? AVX-512 is overrated for HPC generally, but it's surely going to be used by an optimized BLAS (unless there's only one FMA unit per core if the implementation is careful).
Compute nodes actually should have a big.little structure with a service core for the batch daemon etc.
Elsewhere, I see ~130 AVX512 instructions in this Debian system's libc.
Glibc has this strange attraction to having SIMD everything for SIMD friendly functions even though average length to these functions is generally less than 16
> No one claimed it was there, would work, would be stable or anything to that tune.
Isn't that true of like 99.9999% of CPU features? I have never seen an Intel presentation or piece of marketing material that said my software would be able to use the EAX register, and yet it keeps showing up year after year.
Intel explicitly states which instructions sets each processor supports. They don’t list every random register or instruction. Those are captured in the detailed documents.
> What matters is whether consumers were defrauded by seeing a feature they bought
Nobody was defrauded.
The CPU never advertised AVX-512 support. You could never enable it “for free”. You had to disable the efficiency cores and use a BIOS where the manufacturers simply forgot to turn it off.
There is no fraud here and it’s weird to claim as much.
Many features of products aren't advertised explicitly. You don't expect those to be disabled, however, if part of the reason you purchased it was because you found out it was there.
I can see Intel's rationale if it were never promised, but the timing of the removal of the feature is suspect. If Intel is doing this because it sees some level of future chip sales being negatively impacted by a feature that is in the chip that they previously gave customers access to, then they should be held accountable in my opinion. If nothing else people burned by this can chalk another one up to Intel's misguided sales team. It's as if Intel is asking for this sort of attention lately.
Also... AVX-512 was never announced for 12th gen. No one claimed it was there, would work, would be stable or anything to that tune. No one should have had an expectation that a 12th gen CPU would do AVX-512 (and no one did). Intel even explicitly said pre-launch that it won't do AVX-512. Some people found post-launch that some BIOSes allow you to turn the E-cores off and that causes AVX-512 to be detected. IIRC not even the BIOS option claimed anything about AVX-512.
There are a lot one can criticize about Intel. Many low hanging fruits. This isn't one of them.