Live data from Hacker News

Intel completely disables AVX-512 on Alder Lake after all

igorslab.de

311–317 of 317 posts

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

#311
post #256

Earlier quoted context omitted.

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…

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

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.

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

#312

Earlier quoted context omitted.

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.

It turned out that was inaccurate IIRC, and both have the TSO MSR bit.

It wasn't inaccurate. It was true only for the Developer Transition Kit (with Apple A12X). It doesn't apply to release hardware.

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

#313
post #312

Earlier quoted context omitted.

It turned out that was inaccurate IIRC, and both have the TSO MSR bit.

It wasn't inaccurate. It was true only for the Developer Transition Kit (with Apple A12X). It doesn't apply to release hardware.

To be fair, an M1 isn't a A12X.

But of course you're totally right, and it's great to finally know the etymology of this particular misunderstanding.

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

#314

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…

The RYF certification program is based on Richard Stallman's outdated idea that hardware shouldn't be changed and software is anything that can be changed or updated after the device is produced. Anyone who looks at how x86 processors use microcode updates and the security threats with Meltdown and Spectre knows that a modern x86 PC needs to get microcode updates. Even worse is the fact that building a device to comply with RYF actually makes it more difficult to work on freeing the blobs. In the case of the Librem 5, you have to write to the SPI NOR Flash chip to replace the 4 blob files, rather than simply changing the files stored on in the /lib/firmware directory.

However, there are people in the FSF who recognize this. See the comments of Leah Rowe (the Libreboot maintainer) about the problems with the RYF criteria: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-... (read her comments in the libreboot policy she linked to)

I have also criticized the binary nature of RYF certification and suggested that it either needs to move to a category based system: https://forums.puri.sm/t/does-respects-your-freedom-certific... or a number score system: https://forums.puri.sm/t/does-respects-your-freedom-certific...

> That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.

I largely agree that RYF has problems, but it isn't useless, since it does tell people that they can install a new OS or upgrade it without having to deal with proprietary blobs. However, if people want to upgrade the firmware, a RYF device makes that very inconvenient, because you can't just stick the new firmware in the /lib/firmware directory, but have to follow an awkward procedure to upgrade each component's proprietary firmware, and the RYF rules are unclear about whether those upgrades are even allowed. I have written repeatedly to the FSF asking for clarification on whether proprietary firmware can be upgraded under the RYF rules, and I have never received an answer. See: https://forums.puri.sm/t/does-respects-your-freedom-certific...

It's worth mentioning that Purism intends to provide firmware updates for the L5 and has already posted instructions upgrading a couple components: * Texas Instruments TPS65982 USB Type-C and Power Delivery controller: https://source.puri.sm/Librem5/firmware-tps6598x-nonfree * Silicon Labs RS9116 WiFi/Bluetooth: https://source.puri.sm/Librem5/redpine-firmware-nonfree

However, I would agree that the RYF certification isn't useful for distinguishing whether the PinePhone's firmware is more free than the Librem 5's firmware. In fact, it can be argued that the PinePhone has inspired a lot of community work to replace parts of the EG25-G modem's proprietary firmware, so the PinePhone will potentially have a freer modem than the Librem 5.

RYF also has nothing to say about the freeness of your hardware. For example, the MNT Reform provides all its sources for the design of the hardware, so anyone can legally make it, whereas Purism has released the PDF files for the L5's schematics, and the STL files for its case, but won't release the original design files for the boards and case until it recovers its development costs. PINE64 releases the board schematics as PDF files, but they have a normal copyright, so no one can legally reuse or modify them. If you want to do board repair, however, you need to know the placement of each component on the board, and neither Purism nor PINE64 have released board views, whereas board views are leaked for most Apple devices.

> the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem.

It seems that you want to throw the baby out with the bath water. In my opinion, the basic goals of the FSF need to be supported. The problem is the strategy that the FSF uses to reach those goals and its specific policies. I want to see a world where ordinary people can control the technology that they rely on, rather than technology being used as a means to control people.

As I see it, we got lucky with the x86 architecture, because Intel and AMD used a standard booting procedure which wasn't locked, so it was possible to install our own OS on almost any PC in the past, but as PCs move to ARM, I fear that every company is going to copy Apple in designing their own ARM processors for PCs, which have custom booting procedures. Maybe Qualcomm, Samsung, MediaTek, UNISOC and all the rest who are reportedly designing custom ARM processors (Google, Xiaomi and Oppo) will release their files or share info, but I suspect that many PCs in the future will be like the Apple A-series processors where we can't install Linux.

In my opinion, the best strategy to avoid this dark future is to support the device makers and component makers who support free/open source software, rather than continuing to buy products from companies that don't share our goals. Apple sued Corellium (and thankfully lost in court), which is a good indication of Apple's attitude toward its users. When we buy Apple products, we give more resources to a company that is openly hostile to users being able to control their own hardware.

While I have specific criticisms of the RYF, I want the RYF certification program to be reformed so it is useful in the real world, because I do think that people who care about FOSS should be giving their money to companies that support their goals, because that is the best way to create a sustainable industry in the long term that respects user rights and are willing to work with the community. Giving our money to companies like PINE64, Purism, Lulzbot, OLIMEX, Raptor Systems, Arduino, MNT, etc. helps build up our leverage, because these companies will have more power to make demands of component suppliers.

NXP has positioned itself as the best ARM manufacturer for the Linux community (ahead of Rockchip), whereas I rank Apple as the second worst (although today I would now place it as the third worst ahead of UNISOC and HiSilicon). See: https://forums.puri.sm/t/concerns-about-the-security-risk-of...

I know that the Librem 5 doesn't have great performance compared to a phone based on an A13 or Snapdragon 888 (see my benchmarks: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...), but I bought the phone anyway, because I know that Purism went out of its way to select component manufacturers who support FOSS. NXP makes commits to mainline Linux to support its i.MX processors, and releases documentation to the community without NDA's. Silicon Labs (formerly Redpine Signals) releases the drivers for its WiFi/Bluetooth chips under the GPL 2 and altered its firmware at the request of Purism so it didn't have to load the firmware from the main Linux file system. By giving money to Purism, NXP and Silicon Labs, I'm helping to build up a better supply chain, so there is more hope of getting hardware in the future that respects our digital rights.

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

#315

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…

> Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally. I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020.

Before anything else, let me say thank you for your work on the M1, because it is essential that we have Linux support for processors even when the device maker is opposed. Considering how many millions of people have bought Apple's M1 devices, Asahi's work is critical because it provides a path for people to discover a freer system when they get disgusted with Apple's bad practices and the restrictions of its "walled garden."

Having said that, I don't think that your criticism of Purism's kernel work is very fair. Purism made its first commit to mainline Linux for the Librem 5 in July 2018 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). Purism submitted the device tree for the Librem 5 DevKit to mainline Linux on June 17, 2019 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), which was 7 months after it started shipping the DevKits in mid-December 2018 (https://puri.sm/posts/2018-devkits-are-shipping/). I can find emails from Purism trying to submit the device tree for the Librem 5 since May 25, 2020 (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/00715.html), which was 7 months after it started shipping on Nov 17, 2019. Since Linux version 4.20, Purism has made roughly 150 commits to mainline Linux to support the Librem 5, whereas System76 has made 13 commits to the Linux kernel (https://blog.system76.com/post/667593198841069568/open-up-co...) and TUXEDO Computers has made one commit (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...), and I can find commits for the rest of Purism’s competitors (PINE64, Juno Computers, Slimbook, ThinkPenguin, F(x)tec, Planet Computers, Hallo Welte, etc.)

You are comparing the work of a company with two kernel developers (Angus Ainslie and Martin Kepplinger) to an entire community working on Linux support for the M1. Purism has only shipped 2600 Librem 5's so far, whereas Apple is shipping roughly 7 million M1 Mac PCs and 15 million M1 iPads every quarter. If you are going to brag about getting M1 support into mainline Linux within 4 months of the release of the M1, consider the fact that the first commits to mainline Linux for the i.MX 8M processors were submitted just 8 days after NXP announced that it had started volume shipping of the processors (https://www.pengutronix.de/en/blog/2018-01-17-first-mx8m-mai...). This was possible because NXP shipped early versions of the processor to many companies and has released 7000 pages of documentation on the processor, plus NXP pays several of its own employees to work on getting the i.MX 8M supported in mainline Linux. It does make a huge difference whether a company decides to collaborate with the Linux community or not.

You also have to keep in mind that Apple has shipped 2 billion devices with A-series processors that never got mainline Linux support, so we got really lucky that 1) Corellium managed to figure out how to run Linux on the M1 and 2) Apple decided to not block the use of custom kernels with the M1. Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017 (https://craft.co/corellium) and company's blog makes clear that it was its previous work on the A-series (boot sequence, PCIe and USB controller) which helped it get Linux support working so fast on the M1 (https://www.corellium.com/blog/linux-m1), so Corellium wasn't starting from scratch in figuring out how the M.1 works.

By the way, it's worth pointing out that most of Purism's dev work hasn't focused on the kernel, but has instead focused on creating the Phosh mobile environment on top of GTK/GNOME, and Purism has created about a quarter million lines of new code so far (https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr...), and 169.4k of that code (libhandy, libadwaita, Chats and Calls) has been incorporated as official GNOME projects. Purism purposely designed the L5's software to work as a thin overlay on top of an existing desktop Linux stack, so PureOS/Phosh has done a better job than Meego, Sailfish OS, Firefox OS, Ubuntu Touch and WebOS at making a version of mobile Linux which is compatible with the larger Linux ecosystem. Purism commits upstream as much as possible to projects like Linux, wlroots, ModemManager, Geoclue, GTK, GNOME and about 20 different GTK/GNOME apps (Nautilus, gEdit, GNOME Calendar, CNOME Contacts, GNOME Clock, etc.) so that the L5 will be easier to maintain and be able to run on other Linux distros (postmarketOS, Mobian, Ubuntu Touch, etc.).

> To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might)

The i.MX 8M does have a secure boot option, but Purism isn't going to use it because it isn't controllable by the user. Purism's Kyle Rankin commented that they are discussing how to implement a user-verifiable boot procedure, like they have with PureBoot + Librem Key on their laptops, but Purism has a lot of other stuff on its plate (like suspend to RAM, camera auto-focus, encryption with keys from the OpenPGP card, etc.) which is higher priority, so I doubt that it will be implemented soon. The Ubuntu Touch port should have secure boot, but UBports has put their porting of the L5 on hold to focus on the PinePhone and PineTab, so I assume that will also take a while.

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

#316

Earlier quoted context omitted.

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…

> Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally. I submitted upstream bring-up for the M1 Mac Mini with the device tr…

>Apple decided to not block the use of custom kernels with the M1.

More like deliberately modified their design to allow it.

>Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017

I don't think Corellium did have much effect on the Asahi upstreaming effort, they just posted haphazardly patched up kernel tree which they were using for validation of their virtualization platform. Majority of their patches weren't suitable for upstream submission.

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

#317

Earlier quoted context omitted.

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…

The RYF certification program is based on Richard Stallman's outdated idea that hardware shouldn't be changed and software is anything that can be changed or updated after the device is produced. Anyone who looks at how x86 processors use microcode updates and the security threats with Meltdown and Spectre knows that a modern x86 PC needs to get microcode updates. Even worse is the fact that building a device to comp…

>As I see it, we got lucky with the x86 architecture

x86 situation is actually horrible. Not only there are SMM interrupts that are continuing to execute firmware code outside of OS control, it also has proprietary security processors running signed code (ME/PSP) with potentially unlimited access to main memory. M1 fares much better in category of "amount of proprietary code running that might affect your security": no firmware code running at all on the main CPU after bootloader passes control to the OS, and all coprocessors are safely gated behind IOMMUs.

As for other ARM PC consumer devices, they will probably use whatever Windows requires to boot, which is UEFI + ACPI.

Post reply on HN