Re: Is a Raptor Blackbird (or other Power machine) a good general-purpose desktop?
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Mar 21, 2023 at 9:32 PM Linux User #330250
<linuxuser330250@gmx.net> wrote:
> I was looking at those projects in the past, but there are two problems:
> 1. They are way too expensive in terms of a performance to price ratio.
> 2. They are getting way too less support to make that extra investment
> worthwhile.
you just neatly summarised the entire problem with the Power community
which was what inspired IBM to buy Redhat, in their very special way
they thought would solve the problem, bless 'em.
> ideological decision. For now I'm on PC systems (desktops, laptops) with
> Windows preinstalled, and I get very well supported Linux systems at a
> reasonable price. In the past I also used Apple systems, which were
this was exactly why Toshaan Bharvani started the PowerPI initiative,
but it was soon taken over by naive people believing that you can get
a 5 watt system to do 4-core 3 ghz 7 nm with 128-bit-wide DDR3/4/5
memory and multiple lanes of PCIe and multiple lanes of OpenCAPI
in under a budget of USD 10 million, when 7nm Mask Charges are
$10 million on their own.
[https://www.semianalysis.com/p/the-dark-side-of-the-semiconductor]
> I would love to see a competitive truly open Linux computer, starting
> with alternative (if not open) processor designs (Power/PowerPC, MIPS,
> Arm, RISC-V), along with open source firmware (e.g. Coreboot) and ending
> with full Linux support.
as the Technical Director of RED Semiconductor Ltd, this is our goal,
not "bcuz FOSS" but because *i* properly and fully understand that
*full* transparency to the bedrock is a way to engender commercial
customer trust and confidence. and yes, it will use Libre-SOC HDL.
but we have to do the "crawl before walk before run" dance, so will
be starting out with a 1-core 22nm first (think "Pi Model B"), then
2-core (because the cache coherency path between 2 cores to achieve
SMP is a single one) then 8-core then 64-core, over a 6-7 year period.
> Would a live BE<->LE translation be so different? I'd rather have a
> slower but working emulated LE system than a in theory faster BE system
> with constant problems, like the one mentioned in Firefox.[5]
it will be absolute hell. like a *thousand* times or possibly even four
orders of magnitude slower.
the reason is very simple: every single memory access - both by the
I-Cache and the D-Cache - will require not just a JIT rewrite but a
trap-and-emulate of the entire L1, L2, TLB and Paging Virtual Memory
subsystem.
why?
because it's the memory where the LE/BE hit is carried out in hardware,
and you can't let *even one* single memory access go through - not
even byte-level ld/st - because you have to make sure those are tracked
as well through a *software* emulated TLB, that you can't not even for
one ld/st let it get out-of-date.
that's thousands if not tens of thousands of instructions executed just
by *one single* load or store.
at which point you're genuinely better off just running qemu, even
on a Power system.
l.
Reply to: