Hacker News Reader

Comment by codeflo | Hacker News Reader

If all of this was planned (and I’m not saying it is), that would have been very clever. It would work like this:

1. You “accidentally forget” to disable the feature in hardware. Given how competitive the market is, motherboard manufacturers can be relied upon to enable it in their “1337 OVERCLOCKZ” mode. No conspiracy is needed.

2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come.

3. And when you finally do turn the feature off to protect the market for your server chips, you can plausibly claim that you had explicitly forbidden using this configuration from the very beginning. None of this is your fault.

Edit/Addendum: Just to clarify my actual opinion, of course an honest mistake is more likely, at least for step 1. Very few “evil schemes” exist in reality because people aren’t all that clever (and all that evil). But the possibility is interesting to speculate on.

View on HN

> 2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come.

That’s not what happened here.

The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unless disabling those extra cores was offset by the AVX-512 instructions on the remaining cores.

None of the benchmarks you saw in reviews or marketing material would have used these instructions unless specifically called out by the reviewers as having made all of these changes.

Benchmarks like the multi-core Geekbench would actually go down, not up, with this enabled because you’re giving up cores. Thermal performance would be worse because the efficiency cores were disabled.

Intel never marketed the part with AVX-512. It was discovered by a reviewer poking around in the BIOS of a review board.

> motherboard manufacturers can be relied upon to enable it in their “1337 OVERCLOCKZ” mode. No conspiracy is needed.

Nope. You had to disable cores to enable AVX-512 and I doubt it would show up in any gaming or consumer benchmarks as a positive.

The conspiracy theory about Intel doing this to mislead consumers not only doesn’t make sense, it’s completely wrong given how this worked and how it was discovered.

> The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unless disabling those extra cores was offset by the AVX-512 instructions on the remaining cores.

If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Sixteen 256-bit AVX channels are the same as eight 512-bit channels in theoretical throughput. Because there are fewer load/store commands and fewer bunches of setup code to run, overall theoretical efficiency should be higher.

Power efficiency was a killer at 14nm. The cores would downclock into oblivion when AVX-512 executed. Given the node shrink and shutting off half the cores, I don't see why this would happen here. Doing the same calculations with less power means a lot for the kinds of workloads that actually use AVX-512. Sure, idle performance may go down a bit, but once again, if you're running the kind of application that benefits from this, that's also probably not a top consideration either.

The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and unconditionally pin the thread to the big cores. It wouldn't be hard either, just catch the unknown instruction exception and see if it is AVX-512 then move the thread.

> If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too.

Maybe if you have a poorly parallelized problem where the bulk of the code is spent in AVX-512 instructions and you don’t ever do anything else on the computer, but that’s going to be rare for any consumer.

> The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and unconditionally pin the thread to the big cores. It wouldn't be hard either, just catch the unknown instruction exception and see if it is AVX-512 then move the thread.

“It wouldn’t be hard” is a huge understatement. This is OS-level support, not something Intel can just do inside the CPU. And operating system vendors and developers are still catching up to basic Alder Like scheduler support without AVX-512 handing, so it’s not reasonable to suggest this would be easy.

There have been reports that it was possible to enable AVX512 on the big cores with the little ones enabled [0] by toggling some bits in the MSR.

For a first step it would have been enough to manually pin threads to the big cores for adventurous users, but Linux already tacks which threads use AVX (since it comes with a clock penalty, so you want to isolate them if possible), it's not unreasonable to think that auto-setting CPU mask based on that should be possible too.

[0] https://lkml.org/lkml/2021/12/2/1059

I don't see how "poorly parallelized" is relevant compared with, say, a decent OpenMP BLAS which is likely to benefit from any reduced power consumption that allows a faster clock. In general on compute nodes it's worth turning off cores dynamically which aren't being used by jobs, like on a half-full node.

Having actually worked on this, it’s quite a bit more complicated, although it is possible. For better or for worse, though, Intel made a decision that all cores would expose the same feature set, and now this is baked into Linux and probably other OSes at the ABI level, and changing it would be a mess.

A correct heterogeneous ABI (and frankly a good AVX512 ABI at all) would require explicit opt-in, per process, for AVX512. Opting in would change the signal frame format, the available features, and the set of allowed cores.

Boost your benchmarks with AVX-512 by subscribing to Intel+

What benchmarks? Not a lot of real programs actually use AVX512, and a lot of the ones that did discovered that it made performance worse, so they stopped.

(The issue is that AVX512 (the actual 512-bit parts, not the associated EVEX and masking extensions) may well be excellent for long-running vector-math-heavy usage, but the cost of switching AVX512 on and off is extreme, and using it for things like memcpy() and strcmp() is pretty much always a loss except in silly microbenchmarks.)

To be clear, I don't like the type of product line differentiation that Intel does, and I think Intel should have supported proper heterogenous ISA systems so that AVX512 and related technologies on client systems would make sense, but I don't think any of this is nefarious.

> What benchmarks? Not a lot of real programs actually use AVX512, and a lot of the ones that did discovered that it made performance worse, so they stopped.

This paints a picture of what happened to Intel's fab process rather than AVX-512 itself.

AVX-512 was proposed back in 2013. It was NOT designed for desktops. The original designs were for their Phi chips (basically turning a bunch of x86 cores into a GPU). These Phi chips ran between 1 and 1.5GHz, so power consumption and clocks were always matched up.

Intel wanted to move these instructions into their HPC CPUs. The problem at hand was ultra-high turbo speeds. These speeds work because the heat is a bit spread out on the chip and a lot of pieces are disabled at any given time. With AVX-512, they had 30% of the core going wide open for the vector units (not to mention the added usage from saturating the load/store bandwidth).

They wanted 10nm and then 7nm to fix these issues. At their predicted schedule, 10nm would have launched in 2015 and 7nm in 2017.

Given the introduction of AVX-512 in 2013, they had plenty of time. In fact, the first official product was Knight's landing in 2016. Skylake with AVX-512 didn't launch until 2017 when they were supposed to be on 7nm.

Intel was forced to backport their designs to 14nm++++++++++++ which forced a deal with the devil. They had to downclock the CPU to keep within thermal limits, but this slowed down EVERYTHING. Maybe they could have created a separate power plane for AVX, but this would be a BIG change (and probably politically infeasible).

What happens with the downclocking? If you run dedicated AVX-512 loads, then maybe you should have been looking at Phi instead. If not, mixed loads suffered overall because of the lower clockspeeds.

Their second revision of 10nm superfin is still a generation larger (well, probably a half-generation) than what they anticipated. There might still be downclocking, but I'd guess that it's nowhere near what previous iterations required.

TL;DR -- AVX-512 was launched two nodes too early which screwed over performance. It should become acceptable either with 10nm Superfin or 7nm when it launches so the CPU doesn't have to downclock constantly.

It's worth saying that in my life as and academic, the only program I've ever used that has commonly benefited from avx-512 in my work is Gromacs. Gromacs is a molecular dynamics program that creates beautifully graphical simulations and often appears as-is in benchmarks (the so-called ns-per-day metric). Although almost indescribably complex it's also fundamentally strangely straightforward in what it does, and avx-512 does indeed make it significantly faster.

The overwhelming bulk of my research does not use Gromacs, however. Mkl, matrix algebra and similar hybrid MPI tasks, yes, but oddly there the extensions really don't seem to do much, and frankly the inferior memory architecture of the Xeon platinum nodes we use makes itself apparent. I frequently get annoyed that Intel charge you a fortune for CPUs into which you can put a ton of ram, and then marketing makes the CPU's exclusive feature an instruction that doesn't seem to help that much in my actual workloads.

They really should just shunt it to some specialised product and use the die space for something else. I'm with Linus here.

I think the technology will be there to do the mixed instruction set stuff in 5 years, but for now I understand why Intel have played it safe.

> The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and unconditionally pin the thread to the big cores.

Wouldn't it be entirely up to the OS to decide on what core(s) a thread will run?

Theoretically, the E core can raise a #UD (undefined instruction) exception that the OS would trap (which already happens if the CPU doesn’t have AVX-512). The OS could then detect that the offending instruction is from the AVX-512 set, and move it to a P core. It could even set a flag on the thread to force it to use P cores.

Intel even touted the work they did with Microsoft about the scheduler to deal with selecting which E or P core to use.

I’m not sure why they chose to disable AVX-512 instead of doing that. Maybe that is their end goal, but it’s too much effort to have it done by release.

Comparing the facts to all the suspicious people here, it made me realize something. Our zeitgeist sure is a cynical one.

Humans seem prone to find meaning and conspiracy amidst chaos and confusing circumstances.

There's a saying I like - Humans are deterministic machines in a probabilistic world.

Intel has spent decades accumulating its reputation. Sometimes cynicism is appropriate.

Let's see: Intel

- ME https://news.ycombinator.com/item?id=21534199

- Anti Trust: https://www.networkworld.com/article/2239461/intel-and-antit...

- The cripple AMD function in their compiler: https://www.agner.org/optimize/blog/read.php?i=49

I could keep this up quite a bit longer if you want. Intel well deserves any skepticism and cynicism it is targeted with.

> I could keep this up quite a bit longer if you want. Intel well deserves any skepticism and cynicism it is targeted with.

Intel deserves skepticism and cynicism based on what is true.

All companies deserve skepticism, to be clear. AMD have their management engine too. As far as I'm concerned the only reason why AMD's ME isn't as developed as Intel's is because their products have been such a joke leading up to Zen that no one with men in suits bothered asking them for the capabilites, or something like that.

Don't forget the Intel Payola scheme: https://www.theatlantic.com/technology/archive/2010/07/dells...

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.

> 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).

Everything is rarely used until the instructions are ubiquitous.

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.

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...

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.

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.

Thanks for the info, this was insightful. :)

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.

If you just want to play with AVX-512, you can rent an Ice Lake Xeon on AWS EC2 for only 3¢/hour, which strikes me as very hobby-friendly pricing.

But why would you want to play around with AVX512 if you can't benefit from it on your local machine?

e.g. to develop software that works well on servers that do support them?

But rocket lake exists. You can avx512 on a 11 series

> 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.

e.g. https://www.intel.com/content/www/us/en/products/sku/226066/...

> 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.

> HPC applications AVX-512 is rarely used

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

AVX-512 gives RPCS3 a pretty hefty boost, though that is arguably a niche consumer use case.

* 1. Very few “evil schemes” exist in reality because people aren’t all that clever (and all that evil)*

Uh, no. That is a very common technique commonly used the last 15 years.

Many products have different parts, such as different types for display panels in different revisions. So a very common tactic is to only release the one with the superior part at first.

And a few weeks/months later all the reviews have been written or at least have sourced their review sample you start pushing the cheaper version.

Mobile phones, computer displays, TVs etc. suffer from this. Perhaps less so nowadays because most of those critical components are specified in the spec. sheet.

I'll be honest, this looks to be a simple mistake. Cutting AVX-512 literally (meaning in hardware) requires actual staff doing that cut plus it'll increase turnaround times, plus the efficiency cores don't have it. Unlike "let's bin perfectly functional processors into a lower-cored product", this is economically not logical for Intel, which often is the closest from the truth.

Then why not leave it as an option for people who want to experiment with the feature?

Fair point, but again most Windows programs aren't designed with heterogeneous CPUs in mind, so probably they don't want to deal with the headaches, plus the space used for AVX-512 (note that it's now in microcode) can be repurposed for more important tasks.

Of course, this could be evil Intel playing its tricks again but financially speaking removing AVX-512 do have tangible benefits to them in the form of increased microcode for the rest of the instructions (I want to see the detailed Alder Lake errata, maybe there's indeed a bug in another instruction that requires more microcode to implement - AVX-512 is an easy sacrifice for that).

It's not in microcode, they're just disabling it in a microcode update. Microcode updates aren't replacements for microcode either, they're patches. The vast majority of microcode is in ROM and can never be changed wholesale; updates can just patch in hooks and change certain things, limited by the number of patch slots available. Doing this does not "free up" any microcode. It's purely disabling a feature, there is absolutely nothing to be gained in return.

One word: support.

Once you advertise a feature, you have to support it. It'd be pretty damn hard for Intel to explain why lower tier i5 and i3 CPUs have a feature that higher tier i7 and i9 SKUs are missing unless you jump through hoops via hardware (e.g. disable E-cores) or software (e.g. making sure to only run your process on P-cores).

If you want to experiment with AVX-512, just get an older CPU. Much less hassle for both Intel and their customers in this particular case.

They don't support CPUs that were overclocked, yet advertise that feature, so support isn't the reason.

> yet advertise that feature

An therein lies the difference. They advertise the feature, which is something they never did for AVX-512 on Alder Lake desktop. If they advertise a feature, they cannot disable it without getting into legal trouble.

If you get K-SKU, you get an unlocked multiplier. That's guaranteed by Intel and that's were their support begins and ends.

They cannot do the same for AVX-512, though, because that's not possible in their heterogeneous architecture. There's currently no desktop OS that supports different CPU cores (as in capabilities) on the same socket (or even board).

Such feature would require kernel drivers, thread schedulers, and possibly compiler toolchains to be modified for at least Linux and Windows and that's the kind of support Intel would need to provide. They did provide a thread scheduler, but to my knowledge that didn't include any AVX-512 related logic.

>though, because that's not possible in their heterogeneous architecture

Nobody asks them to enable both AVX-512 and E-cores. People want them to not disable the mode that already works today -- P-cores only mode with AVX-512. There are no OS or driver reasons to not do that.

> One word: support.

That hypothesis is not credible. They can simply declare a feature is unsupported, and even that using it voids some guarantee. I mean, look at how overclocking is handled.

You can still use the feature at your own risk - no one is forcing you to install the microcode update.

Soon enough most motherboard BIOSes will come already with the new microcode disabling AVX-512, so you also have to hunt down an old-stock motherboard.

"cuts" are almost always fuses that are blown by ATEs during wafer manufacturing or post packaging tests. It is a bit flip.

There is no extra cost.

And if it wasn't designed to be "blowed up" in the first place, in the hopes that the E-cores do have AVX-512? In that case, it's a literal cut and not simply blowing the fuse.

They always have fuses for this stuff. They have fuses for everything. Modern silicon has piles and piles of chicken bits and fuses to make sure they cover all their bases. There is zero chance they didn't have a hard fuse to disable a known controversial/segmentable feature like AVX-512.

If it wasn't desigend to be disabled it would be buried under multiple and multiple metal layers. You can't "cut" it like a wire. Metal layers run all over the place [1].

Therefore it would have a an e-fuse or a regular old 'current' fuse -- which is just passing a calculated amount of current through an intentionally thin interconnect so that it burns away.

1 - https://static.techspot.com/articles-info/1840/images/2019-0...

>> Very few “evil schemes” exist in reality because people aren’t all that clever

True, but those that try actual evil schemes must be watched for repeats. Remember Intel and Rambus?

This somewhat reminds of the following software optimization procedure:

  - Let's thread this thing.

  - OMG things are working N times faster (where N=cpus)

  - 1 year later, shit... In 0.1% of the cases there is race condition and we can't figure it out, random garbage to our data...

  - 1 week later rolled back to single thread and now everyone is complaing why things are slow...

  - This actually happened... (just not the same time frames)

I'd normally say this is paranoid but with Intel I'll have to give you the benefit of the doubt.

Is AVX-512 even useful in benchmarks? I thought it was mostly used for specialized workloads, and was basically useless for end users and gamers.

Specialized like software video decoding and encoding,....

Some parts of the game would probably benefit a bit from 512 (also remember that it isn't just wider, it adds a lot of new operations entirely), but there simply isn't enough parallelism in the main loop of a game to make all that much difference.

Also "useful" and benchmarks do not mix well.

For games generally those parts can be shifted to the GPU because they feed the rendering pipeline anyway. Doing so has other benefits of lowering latency for that data to be picked up by the graphics bits already there etc. Also the clock speed penalty for AVX512 is pretty steep so unless you're going to do a lot of AVX512 it really doesn't make sense either. Games generally aren't using double precision either which is the AVX512 bread and butter. To make it more fun even if they were... a 4x4 matrix is composed of 256bit elements so the vast majority of register usage wouldn't be 512 bit anyway. The main benefit would be the new instructions more than the register width.

Long story short: Games generally aren't doing enough AVX to really benefit from it as implemented. They can be quite bursty in their use. Not to mention that Not every CPU even has AVX (because apparently Pentium Gold is a thing) even today.

If Intel convinced AMD to pick up the 256 bit versions and removed the clock speed penalties I could see them getting more use. But at the moment it's really just a feature for the HFT market primarily and even they are extremely careful in use because of the clock speed penalty. To the point they will literally benchmark both ways to make sure the penalty is overcome by the throughput.

AVX-512 is so useful in benchmarks that sites like Anandtech intentionally build their benchmarks without it, because the presence of AVX-512 spoils the whole horse race narrative they are trying to sell.

> Very few “evil schemes” exist in reality because people aren’t all that clever (and all that evil).

Also, groups of people are really bad at keeping secrets. In my experience most orgs that do bad things find a way to make everyone think that it’s either actually a good thing, or that someone else is responsible for it. If you make people think there’s a dark secret, they’ll tell eventually.

This makes no sense. There are plenty of secrets and schemes out there. Often it's only necessary to keep a secret in the present. If it comes out years later, often people just ignore it.

> 2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come.

Problem with this scheme is that it assumes reviewers will go to length of running a special hidden mode which may have value in some fringe cases and rave about it.

> just long enough to win the critical initial wave of reviews and benchmarks.

Is the average set of tests by, say, LTT or THG influenced by presence of these instructions? (not being snarky, I really don't know).

Even if a reviewers test suite does benefit from AVX512, it's unlikely that their Alder Lake reviews would actually be swung by it because AVX512 was always disabled in the standard configuration with all of the CPU cores enabled. Enabling AVX512 required disabling the efficiency cores altogether, and running with just the performance cores.

It might have mattered with the lower end Alder Lake parts that only have performance cores, but those haven't been released or reviewed yet.

I don't think that anyone who cares about specific CPU features would not know that it shouldn't work and therefore wouldn't risk getting it removed later

Everyone else would not know that this might have a performance impact.

I wonder if it's more just they had higher yields if they treated the AVX-512 bits as dead silicon :P

Reply on news.ycombinator.com