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

The end of my AArch64 desktop experiment

marcin.juszkiewicz.com.pl

Post reply on HN
Print view View original

81–89 of 89 posts

Re: The end of my AArch64 desktop experiment

#81

Post by pseudohadamard »

HerbManic wrote: post #5

I'm not surprised at the outcome. These Ampere system single core/thread performance is pretty low and that is where you feel it. The OS/software simply cannot allocate the threads across enough cores effectively to make up for this difference. This is why things like the Apple M Series feels so fast, because while they don't win the multi core performance especially when going up against a 80 core beast like this, t…

The whole thing just screams square-pegs-in-round-holes, for a desktop PC he bought a data-centre-server MB with a CPU with $ludicrous cores with an unsupported (qualified) GPU and a custom-built kernel... it sounds like he's trying to get a spot on Animarchy's YT channel, with his trademark line "And then... it got worse".

Re: The end of my AArch64 desktop experiment

#82

Post by pjmlp »

M95D wrote: post #54
rwmj wrote: post #40

Earlier quoted context omitted.

It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)

All IBM PC clones had (or emulated) the same 8253 timer, 8259 PIC, 8237 DMA controller, 8042 keyboard controller, CMOS RTC, 8250/16550 serial port, standard IDE/PATA, standard framebuffer addresses, standard PCI and ISA register addresses, FPU was always at IRQ13, mouse at IRQ12, RTC at IRQ8, LPT at 0x378, PC speaker at 0x61, etc. All this doesn't require any enumeration and was still standard until BIOS/CSM was remo…

IBM PC is the exception here, because how clones came to be, actually.

So ARM did what everyone else has always have done.

Re: The end of my AArch64 desktop experiment

#84

Post by theevilsharpie »

pseudohadamard wrote: post #81
HerbManic wrote: post #5

I'm not surprised at the outcome. These Ampere system single core/thread performance is pretty low and that is where you feel it. The OS/software simply cannot allocate the threads across enough cores effectively to make up for this difference. This is why things like the Apple M Series feels so fast, because while they don't win the multi core performance especially when going up against a 80 core beast like this, t…

The whole thing just screams square-pegs-in-round-holes, for a desktop PC he bought a data-centre-server MB with a CPU with $ludicrous cores with an unsupported (qualified) GPU and a custom-built kernel... it sounds like he's trying to get a spot on Animarchy's YT channel, with his trademark line "And then... it got worse ".

From the article:

> I work at Red Hat. Mostly on AArch64 support in several projects.

So an ARM developer, working for a major Linux distro vendor and trying to dogfood their work, used the closest thing to an ARM workstation that Linux can run on.

What other alternatives would you suggest? The various Apple Silicon or Snapdragon laptops that have their own well-documented problems running Linux? A smartphone running as a desktop?

There aren't very many ARM-based options that are even feasible for use as a developer desktop, even if the software did work correctly.

Re: The end of my AArch64 desktop experiment

#85

Post by theevilsharpie »

NavinF wrote: post #75
anthonj wrote: post #46

Earlier quoted context omitted.

I imagine, be he mentions video playback on youtube making things worse, and he does have a dedicated amd gpu. But iirc for both Firefox and chromium on Linux desktop hw acceleration is tricky so maybe it's that.

Yes anything GPU related other than CUDA is a shit show on Linux desktop. Another issue is that YT loves to use AV1 if they know you're on desktop. Almost all desktop users have a CPU powerful enough to software decode it in realtime, but if you're on a prebuilt PC you'll definitely notice the fans kick in

I can't speak for Firefox, but Google Chrome (and presumably anything Chromium-based) has working hardware-accelerated video on AMD and Intel GPUs.

It does admittedly take some effort to set up; I assume Google is hesitant to enable it by default because of issues with Nvidia GPUs. But when configured, it works and has for years.

Re: The end of my AArch64 desktop experiment

#86

Post by M95D »

yjftsjthsd-h wrote: post #66
M95D wrote: post #60

Earlier quoted context omitted.

> No one uses the firmware supplied DTs because they're usually broken. Oh, and an even more complex UEFI+ACPI solution won't be broken?

Many years of x86_64 PCs would seem to imply that it empirically has better outcomes.

My own experience is the opposite. Since ~2006 when I fist started using Linux, all systems had ACPI errors in Linux, sometimes making some hw components completely unusable in Linux. Device tree boards either just worked (Raspberry) or I patched them until they did (Asus, Radxa).

And you don't have to belive me. See what Linus said[1] about ACPI:

> [...] ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry [...]

[1] https://lkml.iu.edu/hypermail/linux/kernel/0507.3/2331.html

Re: The end of my AArch64 desktop experiment

#87

Post by pseudohadamard »

theevilsharpie wrote: post #84
pseudohadamard wrote: post #81

Earlier quoted context omitted.

The whole thing just screams square-pegs-in-round-holes, for a desktop PC he bought a data-centre-server MB with a CPU with $ludicrous cores with an unsupported (qualified) GPU and a custom-built kernel... it sounds like he's trying to get a spot on Animarchy's YT channel, with his trademark line "And then... it got worse ".

From the article: > I work at Red Hat. Mostly on AArch64 support in several projects. So an ARM developer, working for a major Linux distro vendor and trying to dogfood their work, used the closest thing to an ARM workstation that Linux can run on. What other alternatives would you suggest? The various Apple Silicon or Snapdragon laptops that have their own well-documented problems running Linux? A smartphone running…

Apart from the obvious "well, don't do that then", I'd probably use an ARM-based ODroid for development work, and if I needed more horsepower, the ODroid as a front-end for said thing with more horsepower.

(I actually do development on ODroids, they're quite nice, if underpowered compared to the Intel/AMD equivalents).

Re: The end of my AArch64 desktop experiment

#88

Post by M95D »

neobrain wrote: post #69
M95D wrote: post #57

Earlier quoted context omitted.

> software-side speaker protection What's that?

See https://asahilinux.org/2024/01/fedora-asahi-new/#speakers The effect is understated there, perhaps because Apple speakers are actually somewhat usable without this feature. For the X13s, the speakers might as well not exist in the current state on Linux.

Complexity in the name of cost cutting. A hardware power limiter based on temperature would cost... $1? A thermal pipe from speakers to case acting as a radiator would be... $5?
Post reply on HN