Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 5313

General discussion • Re: RPi 5 as a desktop daily driver?

$
0
0
That's one I'm thinking about quite a bit right now. Looking at some benchmarking figures, it looks like the Pi 5 might have surpassed my old Dell XPS desktop from 2010. Not quite yet for pure number crunching, but in all-around performance for someone like me (my main applications are libreoffice, claws, firefox, and basic photo editing).
My impression is pure number crunching improved the most between the Pi 5 and the Pi 4B. Consider the spider plot showing the difference for the Pi Chart calculations:

Image
viewtopic.php?p=2148085#p2148085

The raspberry-colored curve stretched along the lower right axis means Lorenz 96 experienced far greater improvement compared to the others. Since Lorenz is a numerical kernel while the others are either dominated by memory latency or integer performance, that's why I say number crunching improved the most.
One nice thing about my status quo is that, according to lscpu, my AMD processor is patched against the few speculative execution vulnerabilities to which it is exposed. [I'm running Linux Mint on that old Dell]. My Pi 400 does appear to be a bit exposed (Spectre
V2 and "Spec store bypass"). My Intel laptop (running Mint) has the most vulns of those three (in total and unmitigated). It looked like the Cortex A76 still has some vulns, per ARM (Spectre V1 and BHB, if not V2 and V4 as well).

Not sure how much weight to put on this in the decision (keep or upgrade to Pi 5) process. It's unclear to me if these vulns always require local access to a machine, or if the way that JS can be executed in a browser - running untrusted code, perhaps from hijacking a page/site - obviates the need to be physically present to compromise the data on the machine. In some ways I have it good with that desktop - no unpatched cpu vulns. Still at risk of evil maid attacks though (legacy bios on that thing).
In my opinion legacy BIOS is simpler and less likely to pose a security risk. It's also worth pointing out that already mitigated CPU vulnerabilities in complex performance cores may be possible to exploit in novel ways that haven't yet been revealed.

According to the dog developer, recent headlines highlighting GoFetch speculative pointer dereferencing in Apple M1, M2 and M3 processors

https://arstechnica.com/security/2024/0 ... mac-chips/

also indicate a way forward: Build heterogeneous processors with efficiency cores that are simple enough to be free of speculative side channels. Run security-sensitive code on the efficiency cores and only run trusted code on the performance cores.

I can guess why Fido likes go fetch; however, security-based process scheduling for heterogeneous architectures seems like a nightmare to me. On the other hand, it appears manufacturing a secure performance core is about as likely as a tasty low calorie meal. Maybe it's more practical to have two types of food--no compromise security cores and no compromise performance cores.

Although hybrid electric seems complicated for a car daily driver, maybe a computer daily driver is better with a heterogeneous processor.

Statistics: Posted by ejolson — Sun Apr 21, 2024 4:20 am



Viewing all articles
Browse latest Browse all 5313

Trending Articles