Quadibloc wrote:

> On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:

>> Model 85 and 91 were combined into 195 but this still failed compared to
>> CDC 7600.

> I definitely remembered the Model 195.

> Even if the CDC 7600 outsold it, though, in one way the Model 195 was
> an enormous success. Its microarchitecture ended up being, in general
> terms, copied by the Pentium Pro and the Pentium II.

> So, today, all computers are made this way - OoO pipeline plus cache.

Depends on how accurately you think copying 91 reservation stations count.
Most machines today implement value-free reservation stations because they
are 1/8 the area and somewhat faster. Tomasulo used value-capturing res-
ervation stations.

Also note: the compute Luke was working on a few years ago used Scoreboard
technology rather than reservation station technology.....

Several of the very deep window machines use a dispatch-stack-like pre
scheduler before routing instructions to the FV reservation stations.

> John Savard

On Sun, 03 Dec 2023 22:34:56 +0000, MitchAlsup wrote:

> My last year at AMD ('06); I was working on a 1-wide x86-64, eXcel
> simulation indicated ½ the performance at 1/12 the area and likely 1/10
> the power.

Given that OoO is a wildly inefficient way to improve
the single-thread performance of CPUs, which we use
because we don't have anything better, I'm not surprised
you've expressed the wish that more research be done on
using multiple CPUs in parallel.

Myself, I don't believe the parallel programming problem
is solvable; there will always be too many problems that
have critical serial parts that are too big. But that
doesn't mean that I think we're doomed to require big
hot CPUs that hog electricity.

Because the problem of writing small, bloat-free programs
_is_ solvable. Back in the days when all we had was Windows
3.1 running on 386 and 486 processors, that was enough to
do nearly everything we do with computers today.

We could still run word processors, do spreadsheets, even
run _Mathematica_. All most computer users would miss would
be a bit of graphical pizazz.

Now, it isn't in the interest of CPU makers and others in
the computer industry for users not to be strongly motivated
to run out and buy newer and faster processors every year
or two. The death of Dennard Scaling, and the tapering off
of Moore's Law, however, are taking the wind out of the sails
of that. Eventually, the improvements will be so minor that
the CPU makers won't have enough *money* to fund fabs that
probe the ultimate limits of feature size any longer.

For some users, CPUs made of some exotic material beyond
silicon that was 10x as fast... but, because of yield
issues, could only be used to make small in-order CPUs,
so the CPUs are only 5x as fast... would be worth almost
any price. Because the parallel programming problem hasn't
been solved, whether or not it can be.

And I don't begrudge them such a development, as it would
be a step towards making better performance available to
everyone, as demand drives research into bringing costs
down.

What the rest of us really need is lighter-weight software
that isn't driven by the interests of computer makers instead
of computer users.

John Savard

On 12/3/2023 3:25 PM, Quadibloc wrote:
> On Sun, 03 Dec 2023 22:34:56 +0000, MitchAlsup wrote:
>
>> My last year at AMD ('06); I was working on a 1-wide x86-64, eXcel
>> simulation indicated ½ the performance at 1/12 the area and likely 1/10
>> the power.
>
> Given that OoO is a wildly inefficient way to improve
> the single-thread performance of CPUs, which we use
> because we don't have anything better, I'm not surprised
> you've expressed the wish that more research be done on
> using multiple CPUs in parallel.
>
> Myself, I don't believe the parallel programming problem
> is solvable; there will always be too many problems that
> have critical serial parts that are too big. But that
> doesn't mean that I think we're doomed to require big
> hot CPUs that hog electricity.
>
> Because the problem of writing small, bloat-free programs
> _is_ solvable. Back in the days when all we had was Windows
> 3.1 running on 386 and 486 processors, that was enough to
> do nearly everything we do with computers today.
>
> We could still run word processors, do spreadsheets, even
> run _Mathematica_. All most computer users would miss would
> be a bit of graphical pizazz.

While I absolutely agree that there is too much resources spent on
"graphical pizzazz", and while you could run many/most of the same
programs, that doesn't mean there is no user benefit from faster CPUs.
For example, you probably could run some simulations, fluid dynamics,
finite element analysis, etc. but you were severely limited in the size
of the program you could run in an acceptable amount of elapsed time.
And applications like servers of various flavors certainly benefit from
faster CPUs, as you need fewer of them. Not to mention driving graphics
at more realistic resolutions, etc.

So, no, it wasn't simply the greed of CPU makers that drive us to higher
performance systems.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:

> You CAN build Spectré-free, Melltdown-free, ROP-free,... in GBOoO by
> following one simple rule:: No microarchitectural changes until the
> causing instruction retires. AND you can do this without loosing
> performance.

I thought that the mitigations that _were_ costly in performance
were mostly attempts to approach following just that rule.

Since out-of-order is so expensive in power and transistors,
though, if mitigations do exact a performance cost, then
going to a simple CPU that is not out-of-order might be a
way to accept a loss of performance, but gain big savings in
power and die size, whereas mitigations make those worse.

John Savard

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>EricP <ThatWouldBeTelling@thevillage.com> writes:
>>Anton Ertl wrote:
>>> There is no compatibility at the ISA level. Using flags is a
>>> similarity, not compatibility.
>>
>>I would say its compatibility because it allows A64 to emulate
>>A32 functional behavior with minimal overhead.
>
>Emulation of A32 has not been relevant for quite a number of years,
>because all cores that understood A64 also understood A32/T32.

All cores from ARM did. Cavium's cores were A64 only. The
latest Neoverse cores are A64 only. V9.x deprecates A32/T32
completely.

Of
>course, implementing those cores was simplified by having the same
>flags in the same order, but if there had been good reason, they could
>just as well have built a data path hat produces both kinds of flags
>(or, if they had decided to forego flags on A64, that implemented
>flags just for A32/T32).

The Processor status word on Armv7 is split across three registers.
The processor status word on Armv8 has two different interpretations
depending on the current register width (nRW = 0 A32/T32, nRw = 1 A64).

The only flags in common are NCVZ - Armv7/A32 add Q (indicating saturation)
and the state bits for the IT instruction and the GE flags for the
parallel instructions.

There's really not much in common between A64 and A32/T32, other than
the first 16 registers of the register file.

>
>>That could keep you customers from fleeing to other architectures.
>
>They kept customers by providing cores with both A64 and A32/T32.

But nobody really used A32/T32 on ArmV8 cores. It wasn't
customer demand that lead to implementation on early ARM designs,
but rather the expectation of customer demand (ultimately, non-existent).

On 12/3/2023 5:25 PM, Quadibloc wrote:
> On Sun, 03 Dec 2023 22:34:56 +0000, MitchAlsup wrote:
>
>> My last year at AMD ('06); I was working on a 1-wide x86-64, eXcel
>> simulation indicated ½ the performance at 1/12 the area and likely 1/10
>> the power.
>
> Given that OoO is a wildly inefficient way to improve
> the single-thread performance of CPUs, which we use
> because we don't have anything better, I'm not surprised
> you've expressed the wish that more research be done on
> using multiple CPUs in parallel.
>
> Myself, I don't believe the parallel programming problem
> is solvable; there will always be too many problems that
> have critical serial parts that are too big. But that
> doesn't mean that I think we're doomed to require big
> hot CPUs that hog electricity.
>
> Because the problem of writing small, bloat-free programs
> _is_ solvable. Back in the days when all we had was Windows
> 3.1 running on 386 and 486 processors, that was enough to
> do nearly everything we do with computers today.
>
> We could still run word processors, do spreadsheets, even
> run _Mathematica_. All most computer users would miss would
> be a bit of graphical pizazz.
>

In my own efforts, I can note that a 50MHz CPU, with programs having
memory foot-prints measured in MB (or less) is "not entirely useless".

But, looking backwards, I am left to realize that, it seems, I am
nowhere near close to the levels of performance or efficiency of a lot
of these early systems.

Like, seemingly, often it is not so much that the CPU is too weak or
slow, but that my code code is still slow. Often, taking for granted
coding practices that were formed in the "relative abundance" of CPU
power in the early 2000s.

In nearly every other area of engineering, the design constraints were
relatively constant; but in software, nearly everyone had the mistaken
belief that the exponential increases in computing speed and power would
continue indefinitely.

Now it has been steadily falling off, but there has been a sort of
collective denial about it.

> Now, it isn't in the interest of CPU makers and others in
> the computer industry for users not to be strongly motivated
> to run out and buy newer and faster processors every year
> or two. The death of Dennard Scaling, and the tapering off
> of Moore's Law, however, are taking the wind out of the sails
> of that. Eventually, the improvements will be so minor that
> the CPU makers won't have enough *money* to fund fabs that
> probe the ultimate limits of feature size any longer.
>

I kinda suspect that when Moore's Law is good and dead, there may
actually be a bit of a back-slide in these areas, as the "best" fabs
will likely be more expensive to run and maintain than the "good but not
the best" fabs, and this will create a back-pressure towards whatever is
"the most bang for the buck" in terms of fab technology.

I also suspect that the transition from the past/current state, to this
state of things, is a world where x86-64 is unlikely to fare well.

Say, in this scenario, x86-64 would be left with an ultimately
unwinnable battle against the likes of ARM and RISC-V.

The exact form things will take will likely depend on a tradeoff:
Whether it is better to have a smaller number of cores getting the best
possible single-thread performance;
Or, a larger number of cores each giving comparably worse single-thread
performance, but there can be more of them for cheaper and less power.

Say, if you could have cores that only got 1/3 as much performance per
clock, but could afford to have 8x as many cores in total for the same
amount of silicon.

Or, say, people can find ways to make multi-threaded programming not
suck as much (say, if using an async join/promise and/or channels model
rather than traditional multi-threading with shared memory and
synchronization primitives).

Namely, with such models, it may be possible to make better use of a
many core system, with less pain and overhead than that associated with
trying to spawn off large numbers of conventional threads and have them
all sitting around trying to lock mutexes for shared resources.

Though, not necessarily a great way to map this stuff onto "ye olde C",
so effectively one may end up with something in this case resembling the
processes communicating in a form resembling COM objects or similar,
with the side effect that (given the structure of the internal dispatch
loops), these "objects" can be self-synchronizing and thus don't need an
explicit mutex (but, may potentially need a way for the task scheduler
to queue up in-flight requests, which are then handled asynchronously;
possibly with a mechanism in place to indicate whether the request will
block the caller until it will be handled, or whether the caller will
resume immediately, potentially even though the called object has not
yet seen the request).

Things like async/promises could scale a little easier to "well, do this
thing, potentially using as many cores as available". Though, async's
don't make as much sense on a primarily or exclusively single threaded
system, and have an annoying level of overhead if emulated on top of
conventional multithreading (it effectively needs a mutex protected
work-queue which can itself become a bottleneck).

Ideally, one would need a mechanism to distribute and balance tasks
across the available cores that does not depend on needing to lock a
mutex. Say, for example, maybe using an inter-processor interrupt or
similar to "push" tasks or messages to the other cores, with some shared
visible state for "how busy each core is" but not needing to lock
anything to look at this state.

But, OTOH, if the world can't move beyond conventional multithreading,
then everything may be "kinda screwed" here, and the priority would
likely remain on having smaller numbers of faster cores rather than
larger numbers of slower cores.

> For some users, CPUs made of some exotic material beyond
> silicon that was 10x as fast... but, because of yield
> issues, could only be used to make small in-order CPUs,
> so the CPUs are only 5x as fast... would be worth almost
> any price. Because the parallel programming problem hasn't
> been solved, whether or not it can be.
>

There are a few materials that have been used in power electronics that
can handle high temperatures and switching frequencies, but haven't
caught on for ICs because the density sucks (namely Silicon Carbide and
Gallium Nitride).

But, I have the differing view that many-core systems may be workable,
just not with pthreads or similar...

But, OTOH, if one tries to glue the async/promise model onto C or
similar, people are liable to be like "WTF?!".

_Async int foo() //aynchronous function
{ ... A path ...
return(x);
}

void bar()
{ _Promise int v;
int x;

v=foo();
... B path ...
x=*v; //"join"
}

Where the A and B paths may run in parallel, and then "join" when the
caller tries to deref the promise (if A has not yet finished, B will
stall until the final result has arrived).

Though, ironically, "do something kinda like Erlang but with COM
objects" manages to fit a little better into the conventional C model,
but is limited to a coarse granularity, and seems harder to scale to
computational tasks (one would just sort of end up with a situation
where they end up replacing thread creation and mutex locks with COM
object boilerplate, which isn't really much of a win...).

Works OK for "well, here is a task that manages the GUI subsystem, and
another that manages the OpenGL backend".

> And I don't begrudge them such a development, as it would
> be a step towards making better performance available to
> everyone, as demand drives research into bringing costs
> down.
>
> What the rest of us really need is lighter-weight software
> that isn't driven by the interests of computer makers instead
> of computer users.
>

Software is a gas that expands to fill any available space.

More CPU performance available, more we can spend doing trivial and
pointless stuff, then taking it for granted.

Then head-scratching being like "how was this even supposed to work?"
when presented with resource constraints.

Or, in my case, taking some inspiration from mostly 80s/90s era
retro-computing and game consoles for inspiration on how to make some
stuff work. But, then faced with gaps in my understanding for the stuff
where I don't understand how it works, and no one talks much about how
it works.

So, a lot of information on how early game consoles pulled their tricks.
But, say, "How did 80s Macs manage to not perform like total dog crap?
Or do much of anything whatsoever?" Not so much...

> But nobody really used A32/T32 on ArmV8 cores. It wasn't
> customer demand that lead to implementation on early ARM designs,
> but rather the expectation of customer demand (ultimately, non-existent).

FWIW, I'm running Debian's armhf port (tho on top of an AArch64 kernel)
on my only ARMv8 machine. For machines with small enough RAM, A32/T32
still makes sense.

Stefan

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> But nobody really used A32/T32 on ArmV8 cores. It wasn't
>> customer demand that lead to implementation on early ARM designs,
>> but rather the expectation of customer demand (ultimately, non-existent).
>
>FWIW, I'm running Debian's armhf port (tho on top of an AArch64 kernel)
>on my only ARMv8 machine. For machines with small enough RAM, A32/T32
>still makes sense.

ARMv7 cores are suitable for those machines. And less expensive.

> ARMv7 cores are suitable for those machines. And less expensive.

Maybe that's relevant for those designing the SoC, but for people like
me, machines with ARMv7 cores tend to be significantly less powerful,
typically in terms of number of CPUs, speed of each CPU, speed of
available IOs, etc...

Virtually all SBCs brought to market in the last 5 years use ARMv8 CPUs
rather than ARMv7 ones. Yet the majority of them still has ≤4GB of RAM,

Stefan

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> ARMv7 cores are suitable for those machines. And less expensive.
>
>Maybe that's relevant for those designing the SoC, but for people like
>me, machines with ARMv7 cores tend to be significantly less powerful,
>typically in terms of number of CPUs, speed of each CPU, speed of
>available IOs, etc...
>
>Virtually all SBCs brought to market in the last 5 years use ARMv8 CPUs
>rather than ARMv7 ones. Yet the majority of them still has ≤4GB of RAM,
>

Given that A64, A32 and (for the most part) T32 have the same
32-bit instruction footprint, I don't see RAM size as a determinent
in this case.

> Given that A64, A32 and (for the most part) T32 have the same
> 32-bit instruction footprint, I don't see RAM size as a determinent
> in this case.

Code size is not the issue, pointer size is.

In theory I could use AArch64 compiled to use 32bit pointers, but in
practice it's not widely available/supported
(https://wiki.debian.org/Arm64ilp32Port).

If your workload does not involve many pointers, then the difference is
probably not worth the trouble, admittedly.

Stefan

Quadibloc wrote:

> On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:

>> You CAN build Spectré-free, Melltdown-free, ROP-free,... in GBOoO by
>> following one simple rule:: No microarchitectural changes until the
>> causing instruction retires. AND you can do this without loosing
>> performance.

> I thought that the mitigations that _were_ costly in performance
> were mostly attempts to approach following just that rule.

The mitigations were closer to:: cause the problem to vanish,
but change as little of the µArchitecture as possible in doing
it. But 6 years later, they apparently are still unwilling to
alter the µArchitecture enough to completely eliminate them.

> Since out-of-order is so expensive in power and transistors,
> though, if mitigations do exact a performance cost, then
> going to a simple CPU that is not out-of-order might be a
> way to accept a loss of performance, but gain big savings in
> power and die size, whereas mitigations make those worse.

> John Savard

MitchAlsup [2023-12-04 18:58:51] wrote:
> Quadibloc wrote:
>> On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:
>>> You CAN build Spectré-free, Melltdown-free, ROP-free,... in GBOoO by
>>> following one simple rule:: No microarchitectural changes until the
>>> causing instruction retires. AND you can do this without loosing
>>> performance.
>> I thought that the mitigations that _were_ costly in performance
>> were mostly attempts to approach following just that rule.

IIUC the mitigations are all done in software, and on the hardware side
they seem to largely disregard the issue as if they had abandoned all
hope to solve it at all.

> The mitigations were closer to:: cause the problem to vanish,
> but change as little of the µArchitecture as possible in doing
> it. But 6 years later, they apparently are still unwilling to
> alter the µArchitecture enough to completely eliminate them.

While you write above that "you can do this without loosing
performance", IIUC it does have a cost in that you have to keep more
information as "speculative" and for longer. Presumably we can make
this cost small.

But it reminds me of a recent discussion with similar costs: sequential
consistency, where there again the cost is to keep more instructions as
"speculative" for longer.

Is my association of those two just the result of my lack of knowledge
of how these things are really implemented, or is there indeed
some similarity?

Stefan

On 12/4/2023 11:58 AM, Stefan Monnier wrote:
>> ARMv7 cores are suitable for those machines. And less expensive.
>
> Maybe that's relevant for those designing the SoC, but for people like
> me, machines with ARMv7 cores tend to be significantly less powerful,
> typically in terms of number of CPUs, speed of each CPU, speed of
> available IOs, etc...
>
> Virtually all SBCs brought to market in the last 5 years use ARMv8 CPUs
> rather than ARMv7 ones. Yet the majority of them still has ≤4GB of RAM,
>

Yeah, RAM isn't free...

And, as with other things, the endless march of "bigger and faster"
seems to have slowed down.

As for 4GB, probably the majority of programs would be happy enough with
a 4GB limit, so in this sense, 32-bit almost still makes sense.

Though, possibly slightly more useful is to use a 64-bit ISA, but using
a 32-bit virtual address space and pointers. Then one can potentially
save some memory, while still having the advantages of being able to
work efficiently with larger data.

Though, things like this haven't really caught on in the past, as the
memory use delta between 32 and 64 bit pointers isn't all that large
(but with the added cost of now having two different ABIs and now
needing to have both 32 and 64 bit versions of all the shared libraries).

Or, at least, absent an OS using the 32-bit pointer ABI exclusively.

OTOH, 16-bit was never really sufficient, from what I can tell.

Well, except for small integer values, but the world has settled on
32-bit 'int' as the default "meh whatever" integer type, even if despite
in the vast majority of cases, it is unnecessary.

Well, and for ISA and ABI design reasons, there isn't really any storage
advantage to using smaller types for normal variables, as they just end
up using larger storage on the stack or in the ".bss"/".data" sections
anyways.

Though, there is actually a slight disadvantage, as using 'char' or
'short' or similar for local variables means that now the compiler needs
to go through extra hoops of maintaining the illusion of a smaller
storage size (via frequent sign and zero extensions).

For 32-bit 'int', there are at least some operators with explicit sign
and zero extension built-in (and thus avoid the issue of values going
out of the allowed range).

Though, for small integer values, one can also use sign/zero extension
ops in place of MOV's as another filter against out-of-range values
leaking into the flow.

Though, in my ISA, the 32-bit ops generally have *both* sign and zero
extending forms, rather than just sign or zero extending forms (with the
ABI rule that signed types are kept sign-extended, and unsigned types
are kept zero extended).

Vs, say: ARM64 and x86-64, where signed 32-bit values are zero extended,
or RISC-V where unsigned 32-bit values are sign-extended.

Sometimes, this can come back to bite, as I had recently noted a bug was
due to writing:
bm|=1<<(x&63);
Rather than the intended:
bm|=1ULL<<(x&63);

But, alas...

>
> Stefan

On 12/4/2023 12:54 PM, Stefan Monnier wrote:
>> Given that A64, A32 and (for the most part) T32 have the same
>> 32-bit instruction footprint, I don't see RAM size as a determinent
>> in this case.
>
> Code size is not the issue, pointer size is.
>
> In theory I could use AArch64 compiled to use 32bit pointers, but in
> practice it's not widely available/supported
> (https://wiki.debian.org/Arm64ilp32Port).
>
> If your workload does not involve many pointers, then the difference is
> probably not worth the trouble, admittedly.
>

In my own past testing in these areas, I think I saw something like a 15
or 20% difference for the programs tested, which didn't really seem like
enough of a difference to really care about...

This was small enough to be like, "meh whatever, will just go for 64-bit
pointers even if they are probably unnecessary". Though, in my case, the
64-bit pointers did come with the advantage of being able to use the
high-order bits as type-tag bits, which isn't really viable with a
32-bit address space (for 32-bit pointers, you really do need all the bits).

Nevermind whatever can be said about 64-bit pointers with a 48 bit
virtual address space where:
High bits are ignored (normal load/store ops);
High-bits encode memory bounds for bounds-check ops;
High-bits encode format metadata (eg: the LDTEX op, ...);
High-bits encode CPU mode/state (Function-Pointers and Link-Register);
...

>
> Stefan

Quadibloc wrote:

> On Sun, 03 Dec 2023 22:34:56 +0000, MitchAlsup wrote:

>> My last year at AMD ('06); I was working on a 1-wide x86-64, eXcel
>> simulation indicated ½ the performance at 1/12 the area and likely 1/10
>> the power.

> Given that OoO is a wildly inefficient way to improve
> the single-thread performance of CPUs, which we use
> because we don't have anything better, I'm not surprised
> you've expressed the wish that more research be done on
> using multiple CPUs in parallel.

> Myself, I don't believe the parallel programming problem
> is solvable; there will always be too many problems that
> have critical serial parts that are too big. But that
> doesn't mean that I think we're doomed to require big
> hot CPUs that hog electricity.

> Because the problem of writing small, bloat-free programs
> _is_ solvable. Back in the days when all we had was Windows
> 3.1 running on 386 and 486 processors, that was enough to
> do nearly everything we do with computers today.

> We could still run word processors, do spreadsheets, even
> run _Mathematica_. All most computer users would miss would
> be a bit of graphical pizazz.

Question (to everyone):: Has your word processor or spreadsheet
added anything USEFUL TO YOU since 2000 ??

If not, why are they still adding unused bloat to them ??

{{Come to think of it, my 2003 WORD is more useful than my wife's
2022 WORD because mine wastes less space on the screen with stuff
I never use.}}

> Now, it isn't in the interest of CPU makers and others in
> the computer industry for users not to be strongly motivated
> to run out and buy newer and faster processors every year
> or two. The death of Dennard Scaling, and the tapering off
> of Moore's Law, however, are taking the wind out of the sails
> of that. Eventually, the improvements will be so minor that
> the CPU makers won't have enough *money* to fund fabs that
> probe the ultimate limits of feature size any longer.

My desktops tend to last 7-9 years before blowing out a power
supply transistor. My laptops when the battery dies.

> For some users, CPUs made of some exotic material beyond
> silicon that was 10x as fast... but, because of yield
> issues, could only be used to make small in-order CPUs,
Gallium Arsenide.
> so the CPUs are only 5x as fast... would be worth almost
> any price. Because the parallel programming problem hasn't
> been solved, whether or not it can be.

> And I don't begrudge them such a development, as it would
> be a step towards making better performance available to
> everyone, as demand drives research into bringing costs
> down.

> What the rest of us really need is lighter-weight software
> that isn't driven by the interests of computer makers instead
> of computer users.

Bloatware is driven by the software companies needing to sell
new SW features to stay in business. CUP companies don't care,
customers with CD or DVD ROM disks don't care either....

> John Savard

Stephen Fuld wrote:

> On 12/3/2023 3:25 PM, Quadibloc wrote:
>>
>>
>> We could still run word processors, do spreadsheets, even
>> run _Mathematica_. All most computer users would miss would
>> be a bit of graphical pizazz.

> While I absolutely agree that there is too much resources spent on
> "graphical pizzazz", and while you could run many/most of the same
> programs, that doesn't mean there is no user benefit from faster CPUs.
> For example, you probably could run some simulations, fluid dynamics,
> finite element analysis, etc. but you were severely limited in the size
> of the program you could run in an acceptable amount of elapsed time.

I might note that all of those applications have no real limitation
in parallelism.

> And applications like servers of various flavors certainly benefit from
> faster CPUs, as you need fewer of them. Not to mention driving graphics
> at more realistic resolutions, etc.

> So, no, it wasn't simply the greed of CPU makers that drive us to higher
> performance systems.

I would say that CPU makers were driven to build faster, bigger, ...
machines because SW makers were continuing to consume all of the
available cycles (whether the end user cared or not.)

Quadibloc wrote:

> On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:

>> You CAN build Spectré-free, Melltdown-free, ROP-free,... in GBOoO by
>> following one simple rule:: No microarchitectural changes until the
>> causing instruction retires. AND you can do this without loosing
>> performance.

> I thought that the mitigations that _were_ costly in performance
> were mostly attempts to approach following just that rule.

> Since out-of-order is so expensive in power and transistors,
> though, if mitigations do exact a performance cost, then
> going to a simple CPU that is not out-of-order might be a
> way to accept a loss of performance, but gain big savings in
> power and die size, whereas mitigations make those worse.

18 years ago, when I quit building CPUs professionally, GBOoO
performance was 2× what an 1-wide IO could deliver. In those
18 years the CPU makers have gone from 2× to 3× performance
while the execution window has grown from 48 to 300 instructions.
Clearly an unsustainable µArchitectural direction.

> John Savard

mitchalsup@aol.com (MitchAlsup) writes:
>Quadibloc wrote:
>
>> On Sun, 03 Dec 2023 22:34:56 +0000, MitchAlsup wrote:

>> We could still run word processors, do spreadsheets, even
>> run _Mathematica_. All most computer users would miss would
>> be a bit of graphical pizazz.
>
>Question (to everyone):: Has your word processor or spreadsheet
>added anything USEFUL TO YOU since 2000 ??

Dunno. I still use troff.

>
>If not, why are they still adding unused bloat to them ??

You can't sell a new version if there's nothing different.

>
>My desktops tend to last 7-9 years before blowing out a power
>supply transistor. My laptops when the battery dies.

My cubicle desktop (a Dell tower) is now 11 years old and
going strong. It's only been powered down a half dozen times
during that period. I did replace the boot disk with an
SSD in 2013.

BGB <cr88192@gmail.com> writes:
>On 12/4/2023 11:58 AM, Stefan Monnier wrote:
>>> ARMv7 cores are suitable for those machines. And less expensive.
>>
>> Maybe that's relevant for those designing the SoC, but for people like
>> me, machines with ARMv7 cores tend to be significantly less powerful,
>> typically in terms of number of CPUs, speed of each CPU, speed of
>> available IOs, etc...
>>
>> Virtually all SBCs brought to market in the last 5 years use ARMv8 CPUs
>> rather than ARMv7 ones. Yet the majority of them still has ≤4GB of RAM,
>>
>
>Yeah, RAM isn't free...
>
>And, as with other things, the endless march of "bigger and faster"
>seems to have slowed down.
>
>
>As for 4GB, probably the majority of programs would be happy enough with
>a 4GB limit, so in this sense, 32-bit almost still makes sense.
>
>Though, possibly slightly more useful is to use a 64-bit ISA, but using
>a 32-bit virtual address space and pointers. Then one can potentially
>save some memory, while still having the advantages of being able to
>work efficiently with larger data.

When we did our first A64 chip, we spent some time building an ILP32
toolchain for it based on GCC. Nobody wanted it.

BGB wrote:

> On 12/3/2023 5:25 PM, Quadibloc wrote:
>> On Sun, 03 Dec 2023 22:34:56 +0000, MitchAlsup wrote:
>>>>

> In my own efforts, I can note that a 50MHz CPU, with programs having
> memory foot-prints measured in MB (or less) is "not entirely useless".

I was working on an Automotive Engine simulator in eXcel on a 33 MHz
486, That CPU died and I got a 200 MPH Pentium Pro. On the 486, I
could change a variable (rod length for example) and eXcel would be
done by the time I walked to the frige, got a beer and walked back.
On the PP, it was done in less than 1 second.

> But, looking backwards, I am left to realize that, it seems, I am
> nowhere near close to the levels of performance or efficiency of a lot
> of these early systems.

> Like, seemingly, often it is not so much that the CPU is too weak or
> slow, but that my code code is still slow. Often, taking for granted
> coding practices that were formed in the "relative abundance" of CPU
> power in the early 2000s.

> In nearly every other area of engineering, the design constraints were
> relatively constant; but in software, nearly everyone had the mistaken
> belief that the exponential increases in computing speed and power would
> continue indefinitely.

> Now it has been steadily falling off, but there has been a sort of
> collective denial about it.

As I mentioned above, this has more to do with SW companies needing to
stay in business than in satisfying customer requirements.

>> Now, it isn't in the interest of CPU makers and others in
>> the computer industry for users not to be strongly motivated
>> to run out and buy newer and faster processors every year
>> or two. The death of Dennard Scaling, and the tapering off
>> of Moore's Law, however, are taking the wind out of the sails
>> of that. Eventually, the improvements will be so minor that
>> the CPU makers won't have enough *money* to fund fabs that
>> probe the ultimate limits of feature size any longer.
>>

As someone who skipped every other generation; I bought my destops
more because the last one died, than the need for faster and faster
CPUs. Also, since I always had a second disk in the box, transferring
my files was as simple as moving the drive from box to box.

> I kinda suspect that when Moore's Law is good and dead, there may
> actually be a bit of a back-slide in these areas, as the "best" fabs
> will likely be more expensive to run and maintain than the "good but not
> the best" fabs, and this will create a back-pressure towards whatever is
> "the most bang for the buck" in terms of fab technology.

The only thing chips smaller than 22nm bring is lower power (which we
can use and more cores which apparently we cannot). We have been at 5GHz
for nearly a decade.

> I also suspect that the transition from the past/current state, to this
> state of things, is a world where x86-64 is unlikely to fare well.

It is loosing %-TAM to cell phones and ARM.

> Say, in this scenario, x86-64 would be left with an ultimately
> unwinnable battle against the likes of ARM and RISC-V.

ARM: yes; RISC-V: I would bet against, but it is too early to tell.
With all the Chinese money in RISC-V I don't think USA.gov will
allow what the pundents are predicting.

> The exact form things will take will likely depend on a tradeoff:
> Whether it is better to have a smaller number of cores getting the best
> possible single-thread performance;
> Or, a larger number of cores each giving comparably worse single-thread
> performance, but there can be more of them for cheaper and less power.

> Say, if you could have cores that only got 1/3 as much performance per
> clock, but could afford to have 8x as many cores in total for the same
> amount of silicon.

> Or, say, people can find ways to make multi-threaded programming not
> suck as much (say, if using an async join/promise and/or channels model
> rather than traditional multi-threading with shared memory and
> synchronization primitives).

If you want multi-threaded programs to succeed you need to start writing
them in a language that is not inherently serial !! It is brain dead
easy to write embarrassingly parallel applications in a language like
Verilog. The programmer does not have to specify when or where a gate
is evaluated--that is the job of the environment (Verilog).....

> Namely, with such models, it may be possible to make better use of a
> many core system, with less pain and overhead than that associated with
> trying to spawn off large numbers of conventional threads and have them
> all sitting around trying to lock mutexes for shared resources.

If you want multi-threaded parallel programs you need to design the
host language under the assumption of having infinite cores (not just
"many"). It is not the job of the programmer to distribute the work,
and verify the fork/joins or synchronization, but the environment

> Though, not necessarily a great way to map this stuff onto "ye olde C",

None of the vonNeumann programming paradigms carry to the parallel realm.
a) you can't single step the program
b) you cannot assume that one inst is performed and then the next ...
c) you cannot assume the "I call you and you return to me" control handoff
d) you cannot assume there is 1 point of control

> so effectively one may end up with something in this case resembling the
> processes communicating in a form resembling COM objects or similar,

You need a "net list" of how data flows through the application
that manages itself.

> with the side effect that (given the structure of the internal dispatch
> loops), these "objects" can be self-synchronizing and thus don't need an
> explicit mutex (but, may potentially need a way for the task scheduler
> to queue up in-flight requests, which are then handled asynchronously;
> possibly with a mechanism in place to indicate whether the request will
> block the caller until it will be handled, or whether the caller will
> resume immediately, potentially even though the called object has not
> yet seen the request).

You are starting to get the jist, but our feet are still stuck in the vN
paradigm.

> Things like async/promises could scale a little easier to "well, do this
> thing, potentially using as many cores as available". Though, async's
> don't make as much sense on a primarily or exclusively single threaded
> system, and have an annoying level of overhead if emulated on top of
> conventional multithreading (it effectively needs a mutex protected
> work-queue which can itself become a bottleneck).

This is simply syntactic sugar--the programmer should not have to
manage the parallelism !! The environment does this !!

> Ideally, one would need a mechanism to distribute and balance tasks
> across the available cores that does not depend on needing to lock a
> mutex. Say, for example, maybe using an inter-processor interrupt or
> similar to "push" tasks or messages to the other cores, with some shared
> visible state for "how busy each core is" but not needing to lock
> anything to look at this state.

I used to make a joke:: Verilog compiles your parallel application into
2 miles of straight line code, the first mile is the clock high code,
the second mile is the clock low code. No loops, no branches, just
LD/ST and compute.

This was back in the 1 CPU/system era. But all those loops, linked
data structures, and procedure call/return tree were completely flattened
into straight line code.

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>MitchAlsup [2023-12-04 18:58:51] wrote:
>> Quadibloc wrote:
>>> On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:
>>>> You CAN build Spectr�-free, Melltdown-free, ROP-free,... in GBOoO by
>>>> following one simple rule:: No microarchitectural changes until the
>>>> causing instruction retires. AND you can do this without loosing
>>>> performance.
>>> I thought that the mitigations that _were_ costly in performance
>>> were mostly attempts to approach following just that rule.
>
>IIUC the mitigations are all done in software, and on the hardware side
>they seem to largely disregard the issue as if they had abandoned all
>hope to solve it at all.

On the x86_64 side, perhaps.

ARM added a number of hint instructions, including a speculation
barrier instruction, that provide some hardware support for mitigations.

mitchalsup@aol.com (MitchAlsup) writes:
>BGB wrote:

>
>> Or, say, people can find ways to make multi-threaded programming not
>> suck as much (say, if using an async join/promise and/or channels model
>> rather than traditional multi-threading with shared memory and
>> synchronization primitives).
>
>If you want multi-threaded programs to succeed you need to start writing
>them in a language that is not inherently serial !! It is brain dead
>easy to write embarrassingly parallel applications in a language like
>Verilog. The programmer does not have to specify when or where a gate
>is evaluated--that is the job of the environment (Verilog).....

That is true, but only really usable when the resulting design
is realized on silicon. Verilog simulations won't win any
speed races, even with verilator.

> This was small enough to be like, "meh whatever, will just go for 64-bit
> pointers even if they are probably unnecessary".

In most cases, that's true.
I wouldn't have bothered to use an armhf userland with an arm64 kernel
if it weren't for the fact that the userland is a clone of the one
I used on a previous machine.
IOW, the "meh whatever" works in both directions.

Stefan

> I kinda suspect that when Moore's Law is good and dead, there may
> actually be a bit of a back-slide in these areas, as the "best" fabs
> will likely be more expensive to run and maintain than the "good but
> not the best" fabs, and this will create a back-pressure towards
> whatever is "the most bang for the buck" in terms of fab technology.

AFAIK this future arrived a few years ago: the lowest cost
per-transistor is not on the densest/smallest nodes any more, which is
why many SoCs don't bother to use those densest/smallest nodes.

> I also suspect that the transition from the past/current state, to
> this state of things, is a world where x86-64 is unlikely to
> fare well.

I suspect that the ISA makes sufficiently little difference at this
point that it doesn't matter too much.

> Things like async/promises could scale a little easier to "well, do
> this thing, potentially using as many cores as available".

Async/promises are handy for concurrency, but they don't bring much
benefit for parallelism.

Stefan