Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel completely disables AVX-512 on Alder Lake after all

igorslab.de

Post reply on HN
Print view View original

191–200 of 317 posts

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

#191

Post by blackoil »

codeflo wrote: post #11

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

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

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

#192

Post by marcan_42 »

fsflover wrote: post #184
Fnoord wrote: post #180

Earlier quoted context omitted.

..and still, a Fairphone is more free than almost every smartphone out there. And still, a Framework is more free than almost every laptop out there. Because they are easily repairable because of their modularity. Something, yes, Thinkpads used to be too. But you're bound to old, refurbished ones (X230/T430 apparently) [1]. You don't care about that, you only care about one thing, and the rest is seemingly rationaliz…

> Fairphone is more free than almost every smartphone out there Except it relies on proprietary drivers, which will not be updated by the vendor, resulting in a brick after some years. Librem 5 and Pinephone will receive software updates forever. > But you're bound to old, refurbished ones (X230/T430 apparently) [1]. Not necessarily: https://forum.qubes-os.org/t/community-recommended-computers... . > Librem 5 deliver…

> Librem 5

Ah yes, that phone where the FSF told them they had to move a blob from the bootloader into an external Flash memory and load it through two layers of CPUs, because going through that pointless dance magically makes it Free™ (read: hidden enough that users won't notice so they won't realize they're still running a blob as part of something as critical as making the RAM work).

Also that phone which runs a pile of other giant blobs, including the USB-PD controller and the baseband, of course.

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

#193

Post by wmf »

SkeuomorphicBee wrote: post #10

Stuff like this is why I plan to never buy Intel ever again. I always disliked Intel's strategy for market segmentation by disabling specific instructions, I much prefer AMD's strategy of segmenting just by speed and number of cores. It is really annoying that with Intel you can't run the same program on the server and on your desktop, it makes development and testing a huge pain.

Just don't investigate AM4 motherboard compatibility and AGESA revisions... Absolutely no artificial segmentation here, no sir.

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

#194

Post by fsflover »

marcan_42 wrote: post #190
fsflover wrote: post #152

Earlier quoted context omitted.

> your uncompromising way of doing things (including not loading microcode 'because it is closed source') Libreboot disagrees with that: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-... . Also, FSF would never endorse an Intel CPU with disabled Intel ME. It must be fully removed to get the RYF certification.

The FSF endorse ThinkPads with two or three chips running secret firmware blobs with full access to system memory via the LPC bus. They also endorse Bluetooth dongles running hundreds of kilobytes of proprietary firmware blob (which doesn't count for them because it's in ROM, not /lib/firmware). RYF certification is absolutely meaningless, both from the freedom and security/privacy perspectives. It is actually active…

As my link already says, the FSF can and should be improved. However, I think there is a point in separating "hardware" from "software", where the former is not to be updated. If it can be updated by anyone, in any way, it's not hardware.

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

#195

Post by fsflover »

marcan_42 wrote: post #192
fsflover wrote: post #184

Earlier quoted context omitted.

> Fairphone is more free than almost every smartphone out there Except it relies on proprietary drivers, which will not be updated by the vendor, resulting in a brick after some years. Librem 5 and Pinephone will receive software updates forever. > But you're bound to old, refurbished ones (X230/T430 apparently) [1]. Not necessarily: https://forum.qubes-os.org/t/community-recommended-computers... . > Librem 5 deliver…

> Librem 5 Ah yes, that phone where the FSF told them they had to move a blob from the bootloader into an external Flash memory and load it through two layers of CPUs, because going through that pointless dance magically makes it Free™ (read: hidden enough that users won't notice so they won't realize they're still running a blob as part of something as critical as making the RAM work). Also that phone which runs a p…

The point is that the proprietary software has no access to the RAM or CPU and plays absolutely no role whatsoever in the device usage. I personally agree that it can be called "hardware" and don't care that it has another CPU.

The baseband is on the upgradable M.2 card, also has no access to anything. It can even be killed with a hardware switch. The best smartphone you can find if you care about it. Nobody says that other blobs are fine, but it's already a huge step to the freedom.

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

#196

Post by marcan_42 »

fsflover wrote: post #194
marcan_42 wrote: post #190

Earlier quoted context omitted.

The FSF endorse ThinkPads with two or three chips running secret firmware blobs with full access to system memory via the LPC bus. They also endorse Bluetooth dongles running hundreds of kilobytes of proprietary firmware blob (which doesn't count for them because it's in ROM, not /lib/firmware). RYF certification is absolutely meaningless, both from the freedom and security/privacy perspectives. It is actually active…

As my link already says, the FSF can and should be improved. However, I think there is a point in separating "hardware" from "software", where the former is not to be updated. If it can be updated by anyone, in any way, it's not hardware.

If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one.

This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for users, and also a net security negative. This whole rhetoric that updatability matters, or that somehow lack of source code means "only the manufacturer can update it" and that somehow "makes things less free for users" needs to stop. Users are still in control of updates, the thing isn't magically phoning home (corner cases of stuff with network access notwithstanding). Having access to the blob is a net positive on all fronts for users. This whole policy keeps trying to use this excuse as a rationale, but the reality is the only thing it achieves is convincing people that they aren't running blobs at all by condoning devices where the blobs aren't evident to users because they're not in their filesystem.

This was all brought to its logical extreme of silliness with the Librem 5, which actively engineered an obfuscation mechanism for their RAM training blob to put itself in compliance with RYF, for absolutely no benefit to users: it's still running the same blob as it would've otherwise, and it's still updatable (you can even ignore the entire obfuscation and just flash your own bootloader that does it the normal way).

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

#197

Post by fsflover »

marcan_42 wrote: post #196
fsflover wrote: post #194

Earlier quoted context omitted.

As my link already says, the FSF can and should be improved. However, I think there is a point in separating "hardware" from "software", where the former is not to be updated. If it can be updated by anyone, in any way, it's not hardware.

If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one. This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for…

> If it can be updated by the user, even if the source code is not available, it is freer than if it cannot.

So we both say the same thing with different words. I agree, which is why there is a call to FSF for change.

Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.

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

#198

Post by blacklion »

formerly_proven wrote: post #73
codeflo wrote: post #11

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

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

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

#199

Post by marcan_42 »

fsflover wrote: post #197
marcan_42 wrote: post #196

Earlier quoted context omitted.

If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one. This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for…

> If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.

> So we both say the same thing with different words. I agree, which is why there is a call to FSF for change.

I thought you were saying that hardware is whatever "cannot be updated". That's the argument the FSF uses to say ROM firmware is OK because it's not software. I'm saying that's not okay, because updatability is a plus, not a minus, and ROMs are still software.

> Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.

The obfuscation in the Librem 5 did absolutely nothing to isolate the proprietary blob in any way, shape, or form. It would always run on a dedicated CPU, from the get-go (and that CPU is part of the RAM controller, so it is a security risk for the entire system either way). They added a third CPU in the loop to load the blob, because somehow touching the blob from the main CPU gives it the digital equivalent of cooties in the FSF's view, but adding this extra step of indirection makes it all OK. And then they put the blob in a separate Flash memory so it wouldn't live in the same flash as the main open firmware, because that somehow helps freedom too? Seriously, that whole story is just utterly stupid no matter which way you look at it.

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

#200

Post by jrockway »

formerly_proven wrote: post #73
codeflo wrote: post #11

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

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…

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

Post reply on HN