Intel completely disables AVX-512 on Alder Lake after all • Hacker News Board

Re: Intel completely disables AVX-512 on Alder Lake after all

#301

Post by simoncion » Sat, Jan 08, 2022, 3:18 PM UTC

marcan_42 wrote: post #267

simoncion wrote: post #229

Earlier quoted context omitted.

> ...unbuffered ECC RAM isn't even particularly widely available. Every time I've gone looking for unbuffered ECC RAM over the past three or five years, I've had no trouble finding it. In my experience, the trick is to shop for "server" RAM, rather than "desktop" RAM. Are there speeds or capacities here that you'd particularly like to see that aren't present? https://nemixram.com/server-memory/ecc-udimm/ >

It's available, but not nearly as widely, and even less so at reasonable prices. Last time I had to buy ECC RAM over here in Japan, I had to go to a niche webshop to get a decent price on the capacity I was interested in. For every other PC part I'd just use Amazon and get it delivered next day, usually at the market lowest price or almost.

> Last time I had to buy ECC RAM over here in Japan, I had to go to a niche webshop to get a decent price on the capacity I was interested in.

I've been quite satisfied with the three orders that I've placed with Nemix. I see no indication that they _don't_ ship to Japan, and indications that they _do_ ship internationally... so consider purchasing from them next time you have a need for such memory.

Or, hell, I'd be _shocked_ if there wasn't a company in JP or or KR or CN that also does what Nemix does (that is, yank RAM from decommissioned servers, test it, and sell the stuff that's solid).

And, with Ryzen (and Ryzen Threadripper) becoming ever-more popular, I would expect ECC RAM to continue to drop in price when compared to non-ECC RAM. (But, let's be real here, when you spread the price out over five or ten years, it's _totally_ worth it to have RAM you can rely on.)

Re: Intel completely disables AVX-512 on Alder Lake after all

#302

Post by navjack27 » Sat, Jan 08, 2022, 3:39 PM UTC

blacklion wrote: post #198

formerly_proven wrote: post #73

Earlier quoted context omitted.

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-51…

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…

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

Re: Intel completely disables AVX-512 on Alder Lake after all

#303

Post by temac » Sat, Jan 08, 2022, 3:50 PM UTC

marcan_42 wrote: post #275

temac wrote: post #218

Earlier quoted context omitted.

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.

In theory some weak ECC on top of particularly unreliable storage can still be less reliable than way more reliable storage not employing any ECC, but I also suspect this won't be the case here. However, if the target reliability is only say 2 or 3 times what you had DDR4 without ECC, it is still completely unsuitable for serious applications. And really we should find another name for the internal ECC of DDR5, because the services it provides is completely different from real ECC.

Re: Intel completely disables AVX-512 on Alder Lake after all

#304

Post by dr_zoidberg » Sat, Jan 08, 2022, 4:22 PM UTC

qayxc wrote: post #300

dr_zoidberg wrote: post #284

Earlier quoted context omitted.

That was before Ice Lake, where it had a very decent performance (just downclocking 10%) and then on Rocket Lake it didn't even downclock [0]. But the thing that stuck in our collective mind was that "it's bad because it downclocks". And seeing the RKL numbers, which are new to me (I had only read de Ice Lake numbers back in 2020) it wasn't even 14nm's fault, just an implementation issue which Intel eventually worked…

> That was before Ice Lake My comment was about Alder Lake, where only P-cores even have AVX-512 units. The i9 has 8 P-cores and 8 E-cores and users need to disable the 8 E-cores to use AVX-512. That's 50% of the cores gone for very niche use cases. Considering that the PS3 emulator only got ~10% better performance on the highest end, it'd be better to simply get an 11th gen high-end part instead of a lower end 12th…

I was commenting on the fact that people stuck with the idea that "AVX512 is bad because it downclocks". As for turning off the E-cores, yes, it's a tradeoff that you have to consider if it's worth or not for your use case, and probably for most use cases it won't make sense.

Even then, you're not turning off half the cores:

* Area wise, 4 E-cores use as much die space as 1 P-core.

* Thread wise, turning off the E-cores brings you from 24 threads down to 16 threads.

* I didn't see the PS3 emulator benchmark, but you are telling me that they got a speedup.

* There are some anecdotal accounts ("hardware influencers", YouTube channels, etc) about P-cores being the main driver for gaming performance, hence why these sources mainly recommend the 12400 processor with no E-cores as a price/performance sweet spot.

* Of course, not everything is gaming, and depending on what you do with your computer(s), what will work better.

All in all, I'm more interested in the Celeron/Pentiums which will be Gracemont only (E-cores) and what kind of performance, battery life they get from them. I have an old (2018) sub-notebook that houses an N4000 Celeron (that'd be Goldmont+), and it was surprisingly good for answering emails, web browsing and watching online video. Abysmall performance if you tried to do anything that required math with it (10x to 100x slower than an i5 from the same time) but apparently they've ironed out all those things and those little cores can get in the same ballpark performance, at a much lower power envelope.

Re: Intel completely disables AVX-512 on Alder Lake after all

#305

Post by [deleted] » Sat, Jan 08, 2022, 4:39 PM UTC

temac wrote: post #303

marcan_42 wrote: post #275

Earlier quoted context omitted.

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.

In theory some weak ECC on top of particularly unreliable storage can still be less reliable than way more reliable storage not employing any ECC, but I also suspect this won't be the case here. However, if the target reliability is only say 2 or 3 times what you had DDR4 without ECC, it is still completely unsuitable for serious applications. And really we should find another name for the internal ECC of DDR5, becau…

[deleted]

Re: Intel completely disables AVX-512 on Alder Lake after all

#306

Post by jeffbee » Sat, Jan 08, 2022, 5:24 PM UTC

temac wrote: post #303

marcan_42 wrote: post #275

Earlier quoted context omitted.

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.

In theory some weak ECC on top of particularly unreliable storage can still be less reliable than way more reliable storage not employing any ECC, but I also suspect this won't be the case here. However, if the target reliability is only say 2 or 3 times what you had DDR4 without ECC, it is still completely unsuitable for serious applications. And really we should find another name for the internal ECC of DDR5, becau…

In the industry we already have terms of art that are better than just “ECC”. Normally we speak of EDAC, error detection and correction. We refer to them by their capabilities, such as SECDED, ChipKill, or whatever.

Re: Intel completely disables AVX-512 on Alder Lake after all

#307

Post by seba_dos1 » Sat, Jan 08, 2022, 7:05 PM UTC

marcan_42 wrote: post #292

amosbatto wrote: post #287

Earlier quoted context omitted.

Hi, I'm the "random community member" who wrote that FAQ answer. Thanks for investigating how this works. Where is the file cpu_rec.py located? I can't find it. I will edit the FAQ answer to clarify that the DDR training blobs are being executed on an ARC core in the DDR controller, and not on the M4 core. I was going off what Angus Ainslie wrote ( https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... ) tha…

cpu_rec: https://github.com/airbus-seclab/cpu_rec > However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules The question is why are they doing that? Why are they pandering to a program which ends up encouraging less free devices? RYF is completely broken and does not deliver what people think…

> Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work.

For the record - we have some changes for this driver in our downstream tree waiting to get upstreamed (some may need to be reworked though): https://source.puri.sm/Librem5/linux-next/-/commits/next/byz...

Re: Intel completely disables AVX-512 on Alder Lake after all

#308

Post by mhh__ » Sat, Jan 08, 2022, 7:23 PM UTC

_xnmw wrote: post #299

pantalaimon wrote: post #232

Earlier quoted context omitted.

mitigations=off is IMHO a save thing to do on a single user desktop unless you have nation state level adversaries

There are Spectre/Meltdown exploits done in JavaScript, on the browser. You do NOT want to turn off mitigations unless you're in a Faraday cage.

The browsers themselves have implemented quite a few mitigations themselves, for the record.

Spectre only works in the same address space, which is why chrome uses so many processes.

Re: Intel completely disables AVX-512 on Alder Lake after all

#309

Post by Fnoord » Sat, Jan 08, 2022, 7:43 PM UTC

marcan_42 wrote: post #292

amosbatto wrote: post #287

Earlier quoted context omitted.

Hi, I'm the "random community member" who wrote that FAQ answer. Thanks for investigating how this works. Where is the file cpu_rec.py located? I can't find it. I will edit the FAQ answer to clarify that the DDR training blobs are being executed on an ARC core in the DDR controller, and not on the M4 core. I was going off what Angus Ainslie wrote ( https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... ) tha…

cpu_rec: https://github.com/airbus-seclab/cpu_rec > However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules The question is why are they doing that? Why are they pandering to a program which ends up encouraging less free devices? RYF is completely broken and does not deliver what people think…

I wanted to add that I noticed this kind of all or nothing (or perfionist, or black and white thinking) all the time in the free software community, the vegan community, as well as the Fairphone community (who have made 4 iterations of a fair smartphone (fair being for environment and workers), as well as 3 iterations on a repairable, modular smartphone). They innovated long term support on smartphones for 3 iterations, and the competition is slowly but surely getting better there as well.

I get the frustrations behind it, but its harmful. Its unfair to advocate for others to not use/buy a device because it doesn't fit their perfectionist specifications, while the project made a substantial effort and should be judged on the incremental improvement instead. More so, when they its a unique project which is far ahead of the competition.

What happened though, with regards of that extra layer, is akin to the glue Nvidia uses for their proprietary driver. Its akin to greenwashing. Its dishonest, and unnecessary. Its a marketing ploy. Yes, we should criticize companies for such behavior. No, it does not mean the entire product (or company) is terrible.

Re: Intel completely disables AVX-512 on Alder Lake after all

#310

Post by flatiron » Sat, Jan 08, 2022, 10:12 PM UTC

Fnoord wrote: post #42

flatiron wrote: post #33

Earlier quoted context omitted.

I’m waiting for amd to do TB4 so I can get a ryzen framework laptop.

Yeah, AMD Ryzen Framework laptop would be amazing. (Would also have ECC support?) They'd have to license TB from Intel. I don't know about TB4, but TB3 is royalty-free, just gotta pass a certification. TB3 or better would be great for eGPUs in general. Not sure I personally would need TB4. Also, I wonder if Framework would be usable with say Proxmox and macOS (or 'native' Hackintosh?)

All RAM should be ECC. This intel ECC paywall is terrible. I have no actual need for ECC. My business is in cloud and personal doesn't really benefit too much from it.