Hi,

Mark (nospamplease.delete@this.nothereorthere.com) on May 20, 2022 12:15 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on May 20, 2022 11:32 am wrote:
> > Brendan (btrotter.delete@this.gmail.com) on May 20, 2022 4:06 am wrote:
> > >
> > > To me, supporting dissimilar CPUs (for both "different ISA" and "same ISA with different instruction
> > > timings") is an interesting engineering challenge [...]
> >
> > That's an odd way to spell "stupid and pointless".
> >
> > We already know what the problem is. Intel already did the "expose that cores
> > are different" thing in their desktop/laptop chips. It was an abject and fundamental
> > failure that is basically unfixable, and Intel already disabled it.
> >
> > So no, it's not an "engineering challenge". It was a broken product. It's the
> > same kind of "engineering challenge" that Itanium was. Just give it up.
> >
> > Linus
>
> Impossible or merely painful?

It depends what we're talking about.

If we're talking about CPUs with the same ISA but performance differences (instruction throughput/latency, cache sizes, ...) it'd be relatively easy for software to be optimized for whichever CPU type is best and to tell scheduler that it prefers (but doesn't require) whatever CPU type it was optimized for.

If we're talking about "extremely dissimilar ISA"; then it depends on your approach. E.g. using E cores for GPGPU wouldn't be very painful; and "different kernel per CPU" (like Barrelfish from Microsoft Research) would be painful for unrelated reasons.

If we're talking about "slightly dissimilar ISA"; then you can compile it for the common subset and treat it like "same ISA"; and/or you can treat it the same as "extremely dissimilar ISA"; and/or you can migrate to a different CPU if/when necessary; and/or you can emulate unsupported instructions in software and not migrate; and all of that (in isolation or all combined) is merely painful.

The only thing that's impossible is old software that supports new things well.

- Brendan