I'm pretty happy with the Lenovo Ryzen 7 7435HS gaming laptop that I bought on a Black Friday sale at Best Buy.
-
The x86_64 port of OpenVMS won't even boot if the VM doesn't have XSAVE, while other guest OS's I've tested are sluggish at best. There's a little green turtle icon in the VirtualBox status bar if it's running on Hyper-V instead of natively (a little counterintuitive since green usually means "go").
I also got Ubuntu installed on the laptop as a dual boot after turning off BitLocker (the installer wasn't happy with just disabling it, but at least now I can see my NTFS partition from Linux).
-
The only reason I hesitated to turn off the hypervisor and uninstall Hyper-V in order to have VirtualBox run properly was that I really like the integration of WSL v2 (Windows Subsystem for Linux) and it's nice to have a bash shell in a Terminal tab intermixed with PowerShell. I really like how Microsoft got X11 and Linux audio working with no configuration, so I can run the Linux version of Visual Code to edit files inside my Linux /home partition. I use WSL daily at work for Yocto Linux dev.
-
It's fun that there's no noticeable overhead from running Ubuntu or Gentoo in VirtualBox, in WSL, or on bare metal, except for the suboptimal VirtualBox-on-Hyper-V case.
Anyway, Gentoo, I just discovered "-march=native" doesn't seem to be the best choice for AMD CPUs. At least according to Rust's "rustc -C target-cpu=help", LLVM seems to think it's a generic x86-64 but not anything specific". GCC's flags passed to cc1plus indicate it's enabling MMX, SSE, AVX, etc. as individual feature flags.
-
So I think both GCC and Clang/Rust are able to generate code that enables all the supported SIMD features with "-march=native", but are they able to optimize code scheduling for the microarchitecture or not? I'm doubtful.
So I changed the compiler flags to "-march=znver3" ("-C target-cpu=znver3" for Rust) in /etc/portage/make.conf to ensure it's generating code for Zen 3 (actually Zen 3+, but code scheduling is the same).
Gentoo really makes me ponder optimizing packages for many CPU types.
-
Gentoo also makes me think about combinatorial explosion of configuration options. Even if we restrict to 64-bit x86, there's glibc vs. musl libc, systemd vs. OpenRC, desktop vs. non-desktop, GNOME vs. KDE vs. Xfce, system hardening, and that's without getting into all the USE flags you can toggle individually.
Fortunately, Gentoo provides a stage3 to start with configured with systemd and desktop, so I got Rust, GCC, GTK 3, etc. prebuilt and only needed to add Xfce and some Xorg meta packages.
-
A few years ago, I was really interested in making a user-friendly desktop Linux to make 1996-2006 era non-x86 PCs usable as Internet terminals and for LibreOffice, etc.. There are plenty of PowerMacs floating around, but ideally you want to have separate builds for G3, G4, and G5. Does it matter enough that there are two variants of the G4 (7400 and 7450) to build two different sets of binaries for G4 and G4+? G3 doesn't have AltiVec, that's a big difference and incompatibility vs. later PPCs.
-
For DEC Alpha, you'd want at minimum two versions of all compiled code since the byte-word extension isn't present in the earlier Alphas, and they need multiple instructions to load/save bytes and 16-bit words compared to later Alphas with BWX support (or other CPUs).
32-bit SPARC didn't ship with multiply/divide instructions, added later (SPARC V8). Any type of SIMD or math extension is going to make it worthwhile to compile the code both ways, perhaps in the same binary to select at runtime.
-
Don't get me started on PowerPC after Apple. IBM has added so many new instructions in each new POWER version that today's ports of popular open-source code that generates code or needs to be bootstrapped from binaries (Node.js, Rust, Go, etc.) are often compiled to, or generate code requiring instructions that aren't in a G5's CPU. It's 64-bit PowerPC, circa 2004.
Not to mention that Linux on PowerPC decided to switch to little-endian because big-endian is such a giant code porting headache.
-
The G5 CPU can't run in little-endian mode. It may be the only PowerPC CPU that isn't bi-endian. Apple didn't need little-endian support but they did need some other obscure compatibility features not found in other PowerPC chips (there's a "zero a cache line" opcode that Mac code expected to zero a certain # of bytes, so G5's emulate zeroing that # of bytes, which is now smaller than a cache line, which other PowerPC's don't, a compatibility feature only needed to run 32-bit Mac PowerPC code).
-
The QEMU/KVM hypervisor on PowerPC/POWER is quite clever. First of all, the fact that it works at all on G3/G4/G5/PS3/etc. CPUs that don't even have a hypervisor mode is kind of amazing. It's called "KVM-PS" (for "problem state", the IBM term for "user mode"), vs. "KVM-HV" for the kernel module that uses a real hypervisor.
The PPC KVM module knows how to trap and emulate the "zero a cache line" instruction, which is how you can run old versions of MacOS 9 or X on a recent POWER9 or whatever.
-
O [email protected] shared this topic
