Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - DKnoto

Pages: [1] 2 3 ... 8
1

I wouldn't buy a POWER9 system today either.

A) too expensive
B) new systems should be coming out soon.

Re: 1) You’re right that they’re expensive compared to x86_64 solutions, but when you look at the cost per day of use, it’s not that bad. My Talos II cost me a little over $10,000. I’ve been using it for over 4 years, so it works out to less than $7 a day. It’s not that bad ;-)

Re. 2) I’ve been hearing about these new systems for a long time now—probably over two years—and still nothing :(

2
Applications and Porting / Re: [DEV] JIT support for Firefox
« on: July 22, 2026, 04:54:47 am »
@tle

I'll try to add your patches from yesterday for version 153 to my Void Linux templates as soon as possible and run some comparison tests with version 152.

3
Following up on my recent project of bootstrapping Void Linux on ppc64le, I decided to quantify the exact performance penalty we pay when using generic distribution binaries on our Talos II workstations.

I compiled Firefox 152 natively using both GCC and Clang (with and without LTO/PGO) and ran a rigorous Speedometer 3.1 benchmark against the standard Firefox 151 package provided by Fedora 42.

To eliminate DVFS noise, the CPU was strictly pinned to 2.8 GHz, and tests were run in an isolated E27 environment using --new-instance --private-window to avoid the unaccelerated paths of the standard safe mode.

The Build Times & Toolchain Limits

Clang: 43m 30.668s
Clang + LTO: 45m 32.136s
Gcc: 67m 05.885s
Gcc + LTO:  84m 28.716s

Note on PGO: I attempted PGO builds, but the current toolchain state on ppc64le (specifically regarding VSX) makes it a dead end. GCC instrumentation resulted in an Internal Compiler Error, and Clang took over 3 hours (185m real time) only to produce a crashing binary.

Performance Results (Speedometer 3.1)

FF151 / F42: 1.647; stdev = 0.018;
FF152 / GCC: 5.449; stdev = 0.086
FF152 / GCC+LTO: 5.518; stdev = 0.063;
FF152 / Clang: 5.478; stdev = 0.065;
FF152 / Clang+LTO: 5.779l stdev = 0.050.

Key Architectural Takeaways:

  • The VSX/JIT Effect: The native Clang+LTO build delivers a ~250% performance increase (a 3.5x multiplier) over the default Fedora 42 package. This heavily implies that standard distro builds are either running scalar code or heavily crippling the JS JIT compiler for stability.
  • LLVM Dominance: Clang not only builds significantly faster than GCC, but it also scales much better with LTO.
  • GCC UI Anomaly trimmed: During the tests, I noticed that regardless of LTO, the GCC-compiled binaries exhibit significant UI desynchronization (the "burger menu" lags about three cursor positions behind). The SpiderMonkey engine runs fine, but the interaction with system libraries (GTK/Cairo) is visibly degraded compared to the Clang build.
Has anyone else experienced similar UI latency with GCC-compiled GTK applications on POWER9, or is this strictly a Mozilla codebase quirk when compiled outside of LLVM?

The full raw data, generated charts, XBPS build templates, and the critical patch fixing VSX alignment issues in the Mozilla codebase are available in my public GitHub repository here: https://github.com/DKnoto/Firefox-Benchmarks


5
I’ve adopted a different build philosophy: I don’t want to forcefully reduce dependencies, but rather compile as much as possible. I only reduce dependencies when I have to. Additionally, I have testing software that checks a large number of different Lua versions and dialects.


I build the Enlightenment environment directly from the source code in the project repository. Version 0.27.0 has slightly fewer features.

I've already built 1,877 packages ;-)

6
For fastfetch: LuaJIT is not supported. Lua support is optional.

In that case, I'll have to remove the dependency, but it'll be hard to track down because it's not a direct dependency.

7
I made an almost identical fix in fill_array_from_sys, but there's still a memory leak in that function.

8
Update from the development front on Void Linux on ppc64le:

- I built cpufetch and fastfetch packages;

- The first one required some minor code refactoring for PPC—unused variables, memory leaks—I did only what was necessary to ensure it compiled without errors;

- In the second package, I ran into massive dependencies; I had to build 608 packages, including LuaJIT;

- For LuaJIT, I used sources from OpenResty; they compile, but unfortunately the JIT doesn’t work.

Here’s a screenshot of how it ultimately looks: https://www.dropbox.com/scl/fi/rh5n4a9vx7i47yoy0rueh/Void-Linux-Talos2-ppc64le-fast-cpu-fetch.png?rlkey=4bcs27d2gqtc9a7wf7wd12lfe&st=lqtizzog&dl=0

9
“Works” might be a bit of an overstatement. I'm starting with a minimal installation. I'm currently putting together a more comprehensive set of packages to perform a full installation and migrate package building from Fedora 42 to Void Linux. Unfortunately, I need to expand my infrastructure with a second processor because the entire build process takes a while on a single C18.

10
Hi everyone,

    I just wanted to share a recent personal milestone. After a few days of intensive compiling and debugging, I’ve successfully bootstrapped a complete, native Void Linux base system (almost 1,000 packages) for ppc64le directly on my Talos II.

    I used Void's xbps-src environment to build everything from source. If anyone else is looking to try this, here are a few technical hurdles I ran into and how I bypassed them:
  • Kernel 6.18 & pSeries LPAR code: The build initially failed on papr-hvpipe.c. Since our machines run on PowerNV (skiboot) and don't need IBM's PAPR w/ LPAR virtualization overhead, I temporarily patched out the failing code with preprocessor macros. My ultimate goal is to build a leaner kernel with CONFIG_PPC_PSERIES completely disabled.
  • x265 compilation errors: The x265 package tripped over AltiVec/VSX hardware optimizations during the 10-bit depth build pass. I had to explicitly disable the altivec option in the package's build template to get it to compile cleanly via standard C++.
  • Booting via Petitboot: Instead of fighting with ISO generation scripts designed for x86, I installed the built packages (xbps-install) directly onto an ext4-formatted USB drive via chroot. I wrote a minimal grub.cfg pointing to the native vmlinux and initramfs, and Petitboot flawlessly parsed it and booted the system via kexec on the first try.
    I'm taking a short breather now, but my next step is to configure the network with ConnMan and compile a native, lightweight graphical environment—likely Enlightenment—to keep the system as responsive and bloat-free as possible.

    If anyone is working on a similar Void/OpenPOWER port and needs details on the xbps-src patches, let me know!

Cheers.

11
Operating Systems and Porting / Re: [NEWS] Fedora 44 Beta is out!
« on: March 18, 2026, 01:55:30 am »
It works very well on this machine, the MoreFine M600. I’ve been using this machine alongside the Talos 2 for over a year, since December 2024. During that time, I’ve experienced two or three instances of amdgpu crashing. I recently bought the latest version of the MoreFine H1, the AMD AI PRO MAX, but FreeBSD doesn’t work on this hardware yet.

12
Operating Systems and Porting / Re: [NEWS] Fedora 44 Beta is out!
« on: March 15, 2026, 04:15:29 am »
I’ve gone back to my roots and have been using Enlightenment E27.1 for a few months now. Unfortunately, F44B doesn’t include the X11 version of E27.1, and the Wayland version doesn’t work. On my x86_64 workstation, I’ve switched to FreeBSD:

Code: [Select]
```                        `        dknoto@mfm600
  ` `.....---.......--.```   -/     -------------
  +o   .--`         /y:`      +.    Host: M600
   yo`:.            :o      `+-     Kernel: FreeBSD 14.4-RELEASE
    y/               -/`   -o/      Uptime: 3 days, 12 hours, 31 mins
   .-                  ::/sy+:.     Shell: bash 5.3.9
   /                     `--  /     Display (DELL U4021QW): 3456x1458 @ 1.17x in 40", 60 Hz [External] *
  `:                          :`    Display (HP LP2475w): 1920x1200 @ 1.17x in 26", 60 Hz [External]
  `:                          :`    WM: Enlightenment (X11)
   /                          /     Theme: Breeze-Dark [GTK2], Breeze [GTK3]
   .-                        -.     Icons: breeze-dark [GTK2/3/4]
    --                      -.      Font: Noto Sans (11pt) [GTK2], IBM Plex Sans (13pt, Light) [GTK3], Noto Sans (11pt) [GTK4]
     `:`                  `:`       Cursor: breeze (24px)
       .--             `--.         Terminal: terminology 1.14.0
          .---.....----.            CPU: AMD Ryzen 9 7940HS (16) @ 4.00 GHz
                                    GPU: AMD Radeon 780M Graphics
                                    Memory: 50.41 GiB / 63.18 GiB (80%)
                                    Swap: 133.82 MiB / 2.00 GiB (7%)
                                    Disk (/): 127.72 GiB / 645.29 GiB (20%) - zfs
                                    Disk (/zroot): 96.00 KiB / 517.57 GiB (0%) - zfs
                                    Local IP (re0): 192.168.0.57/24
                                    Locale: pl_PL.UTF-8

13
Operating Systems and Porting / Re: [NEWS] Fedora 44 Beta is out!
« on: March 14, 2026, 09:52:14 am »
The geniuses at GNOME have taken anti-ergonomics to the point of absurdity. They’ve turned the simple “double-click” + “middle-click” operation into a sequence of “double-click” + “right-click” + “select copy” + “click” + “right-click” + “select paste.”

14
Operating Systems and Porting / FreeBSD 16 plans to drop support for PPC64.
« on: November 18, 2025, 10:07:29 am »
Hi

I have sad news for fans of diversity on the PPC64 platform. The FreeBSD team plans to discontinue support for PPC64 starting with version 16. Link to the original discussion: https://lists.freebsd.org/archives/freebsd-arch/2025-November/001078.html.

15
Applications and Porting / Re: [DEV] Electron support for ppc64le
« on: November 12, 2025, 07:25:23 am »

Pages: [1] 2 3 ... 8