By chance stumbled onto the work at ITH Zurich group targeting low power computation, that is designing and building, as in ASIC chips, research processors using variants of RISC-V.
One of their designs, Snitch, uses a simple integer processor core with a floating-point co-processor. Their primary figure of merit is energy per floating-point computation. To wit, they eschew GBOoO and register renaming but do use a scoreboard.
Some registers have vector semantics, e.g. act as DMA ports into memory and have buffers thereby lowering the needs for data caches!
The second effect is replacing the in-loop loads and stores with outside-of-loop resister setup/configuration. Search on "Stream Semantic Register Architecture".
The third effect is increasing the number of instructions per clock, as memory load/stores are implied.
Further, they are considering instructions which specify the use of additional registers in the floating point register file for unrolling loops. The loop instructions are held in the floating-point unit in a short buffer?

From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma".. https://pulp-platform.github.io/snitch/rm/custom_instructions/

Expect there will be further presentations at next week's RISC-V Summit?
Also see https://www.openhwgroup.org/

So, it appears that a research project is investigating simultaneous low power computation, low overhead vector processing, and high function unit utilization. E.g. an alternative to other vector architectures having very high performance goals via many small cores.

On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
> By chance stumbled onto the work at ITH Zurich group targeting low power computation, that is designing and building, as in ASIC chips, research processors using variants of RISC-V.
> One of their designs, Snitch, uses a simple integer processor core with a floating-point co-processor. Their primary figure of merit is energy per floating-point computation. To wit, they eschew GBOoO and register renaming but do use a scoreboard.
> Some registers have vector semantics, e.g. act as DMA ports into memory and have buffers thereby lowering the needs for data caches!
> The second effect is replacing the in-loop loads and stores with outside-of-loop resister setup/configuration. Search on "Stream Semantic Register Architecture".
> The third effect is increasing the number of instructions per clock, as memory load/stores are implied.
> Further, they are considering instructions which specify the use of additional registers in the floating point register file for unrolling loops. The loop instructions are held in the floating-point unit in a short buffer?
>
> From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma".. https://pulp-platform.github.io/snitch/rm/custom_instructions/
<
xfrep is basically equivalent to my LOOP instruction.
>
> Expect there will be further presentations at next week's RISC-V Summit?
> Also see https://www.openhwgroup.org/
>
> So, it appears that a research project is investigating simultaneous low power computation, low overhead vector processing, and high function unit utilization. E.g. an alternative to other vector architectures having very high performance goals via many small cores.

On Thursday, June 1, 2023 at 5:57:11 PM UTC-5, MitchAlsup wrote:
> On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
> > By chance stumbled onto the work at ITH Zurich group targeting low power computation, that is designing and building, as in ASIC chips, research processors using variants of RISC-V.
> > One of their designs, Snitch, uses a simple integer processor core with a floating-point co-processor. Their primary figure of merit is energy per floating-point computation. To wit, they eschew GBOoO and register renaming but do use a scoreboard.
> > Some registers have vector semantics, e.g. act as DMA ports into memory and have buffers thereby lowering the needs for data caches!
> > The second effect is replacing the in-loop loads and stores with outside-of-loop resister setup/configuration. Search on "Stream Semantic Register Architecture".
> > The third effect is increasing the number of instructions per clock, as memory load/stores are implied.
> > Further, they are considering instructions which specify the use of additional registers in the floating point register file for unrolling loops. The loop instructions are held in the floating-point unit in a short buffer?
> >
> > From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma". https://pulp-platform.github.io/snitch/rm/custom_instructions/
> <
> xfrep is basically equivalent to my LOOP instruction.

Yup, and there is the CDC6600 with implied loads and stores. Some of the TI chips had 2D DMA engines.
The ITH Zurich group is also looking into sparse vector acceleration:
Indirection Stream Semantic Register Architecture for Efficient Sparse-Dense Linear Algebra, Paul Scheffler 2020 etal.

> >
> > Expect there will be further presentations at next week's RISC-V Summit?
> > Also see https://www.openhwgroup.org/
> >
> > So, it appears that a research project is investigating simultaneous low power computation, low overhead vector processing, and high function unit utilization. E.g. an alternative to other vector architectures having very high performance goals via many small cores.

On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
> On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:

> > From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma". https://pulp-platform.github.io/snitch/rm/custom_instructions/
> <
> xfrep is basically equivalent to my LOOP instruction.

And xssr handles vectors by turning some registers into portals to vectors in memory.

So, while a Cray worked on vectors in big vector registers, this design works on
vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
in competition with the Cray I.

This is why I tend to think that the NEC SX-Aurora TSUBASA is doing it the "right" way,
but faces the problem of being stuck at 14nm because there's just not enough of a
supercomputer market to support custom development of this kind of chip.

And so this is why my thinking goes in the direction of: NEC should design a smaller
version of their processor, not as powerful, but get economies of mass manufacture
by convincing, say, SONY to put it in their next PlayStation! That way, computers in
general would advance to being much more powerful.

Using a scoreboard instead of GBOoO, of course, is an approach you're likely very
sympathetic to, and so if this works well, you would definitely be vindicated.

John Savard

On Thursday, June 1, 2023 at 11:45:55 PM UTC+1, JimBrakefield wrote:
> By chance stumbled onto the work at ITH Zurich group targeting low power computation, that is designing and building, as in ASIC chips, research processors using variants of RISC-V.
> One of their designs, Snitch, uses a simple integer processor core with a floating-point co-processor. Their primary figure of merit is energy per floating-point computation. To wit, they eschew GBOoO and register renaming but do use a scoreboard.

and time-slicing, aka "A Barrel Processor"

https://arxiv.org/pdf/2002.10143.pdf

> Some registers have vector semantics, e.g. act as DMA ports into memory and have buffers thereby lowering the needs for data caches!

not just caches but entirely *bypassing* caches because there's no point having them. follow the white rabbit...

* memory is ultimately 150 mhz DRAM cells
* therefore there is latency if running the CPU at say 1 ghz
* therefore you need to cater for the delay between "mem request" and "received"
* therefore you need to slow down the CPU
* but this is a waste therefore
* instead you do round-robin processing *aka a Barrel Processor*

> The second effect is replacing the in-loop loads and stores with outside-of-loop resister setup/configuration. Search on "Stream Semantic Register Architecture".

which

> The third effect is increasing the number of instructions per clock, as memory load/stores are implied.
> Further, they are considering instructions which specify the use of additional registers in the floating point register file for unrolling loops. The loop instructions are held in the floating-point unit in a short buffer?

this is where Zero-Overhead-Loop-Constructs come into play.

https://www.semanticscholar.org/paper/A-portable-specification-of-zero-overhead-looping-Kavvadias-Nikolaidis/dbaa66985cc730d4b44d79f519e96ec9c43ab5b7?p2df

> So, it appears that a research project is investigating simultaneous low power computation, low overhead vector processing, and high function unit utilization. E.g. an alternative to other vector architectures having very high performance goals via many small cores.

what they are extremely unlikely to have is compiler support alongside retaining a sequential programming model. if however they have managed that then they have hit the "holy grail" of solving Moore's Law.

l.

On Friday, June 2, 2023 at 12:58:24 AM UTC-6, Quadibloc wrote:

> So, while a Cray worked on vectors in big vector registers, this design works on
> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
> in competition with the Cray I.

Meditating on this - and on ways around this problem - has led me to think of
something which may have been what you were assuming all along.

A computer could get the same performance from instructions involving memory
as from instructions involving registers... *if* it could assume that the memory
was only accessed from the current thread. Then it could always use copies of data
that were in cache, or even in flight between registers, without having to refer back to
the actual copy in memory.

It used to be that computers had special instructions for I/O... now, I/O is normally
memory-mapped. Perhaps it would be time to go back, in a way: have normal
memory-reference instructions indicate that the memory accessed is thread-local,
and have special memory-reference instructions for memory that is not thread-local,
but which can be changed by other things. Those would be used for I/O, for communication
between processes, and so on.

Then, presumably, since the processor would know that certain memory it used was
thread-local, it could put the data in registers itself, without the compiler having to do so
explicitly, and gain increased performance.

John Savard

On Friday, June 2, 2023 at 7:58:24 AM UTC+1, Quadibloc wrote:
> On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
> > On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
>
> > > From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma". https://pulp-platform.github.io/snitch/rm/custom_instructions/
> > <
> > xfrep is basically equivalent to my LOOP instruction.
> And xssr handles vectors by turning some registers into portals to vectors in memory.
>
> So, while a Cray worked on vectors in big vector registers, this design works on
> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
> in competition with the Cray I.

you have to remember that all those systems had memory
running at the same speed (or faster) than the CPU. and
that ETH-Zurich's Pulpino work is all about Ultra-low-Power,
so they *can* say "we run CPU speed @ mem speed"
(the barrel-processor design of Snitch - they call it "Timeslicing"
or something - is the exception)

also there was the problem of not being able to use
"Vector Chaining" in a MEMORY-COMPUTE-MEMORY
ISA, which Cray solved (avoided) because it was
MEM-REG-{COMPUTE-REG)*-MEM

ETA-10 took a different approach by designing arithmetic
instructions as sourcing from IN-FLIGHT data. so it was:

* MEM->inflight_A
* MEM->inflight_B
* {A/B->COMPUTE->inflight_a_or_b}*
* inflight_a/b->MEM

and now we have both ARM, Eth-Zurich *and* the European
Processor Group all scrambling to roll back 50+ years in
the history of computing... reinventing the wheel.

c'est la vie :)

l.

p.s. does anyone recall where the EPI academic paper
on streaming extensions is? if i find it i'll post it.

On Friday, June 2, 2023 at 5:44:39 AM UTC-6, luke.l...@gmail.com wrote:

> p.s. does anyone recall where the EPI academic paper
> on streaming extensions is? if i find it i'll post it.

While the direct link in the text to the paper is broken, the link to
"Publications" in the menu on the left side works. That shows the
paper is behind a paywall.

https://pulp-platform.github.io/snitch/publications/

John Savard

On Friday, June 2, 2023 at 12:53:01 PM UTC+1, Quadibloc wrote:
> On Friday, June 2, 2023 at 5:44:39 AM UTC-6, luke.l...@gmail.com wrote:
>
> > p.s. does anyone recall where the EPI academic paper
> > on streaming extensions is? if i find it i'll post it.
> While the direct link in the text to the paper is broken, the link to
> "Publications" in the menu on the left side works. That shows the
> paper is behind a paywall.

(copies make their way out onto researchgate and arxiv)

sorry i meant EPI not Eth-Zurich,
https://www.european-processor-initiative.eu/

EPI is about SiPearl
https://www.eenewseurope.com/en/sipearl-raises-e90m-for-rhea-european-supercomputer-chip/

but i have seen a paper two weeks ago that is *also* about
"Streaming" from the *EPI* group

and ARM's SVE Matrix Extension *also* mentions "Streaming"
i just can't remember where i saw it. the RTL of the Matrix
Extension?

bottom line everyone and their dog is going hell-for-leather
backwards 50+ years in time.

the fundamental principle is "register tagging". oh look
we just had a discussion about register tagging :)

l.

On Friday, June 2, 2023 at 6:53:01 AM UTC-5, Quadibloc wrote:
> On Friday, June 2, 2023 at 5:44:39 AM UTC-6, luke.l...@gmail.com wrote:
>
> > p.s. does anyone recall where the EPI academic paper
> > on streaming extensions is? if i find it i'll post it.
> While the direct link in the text to the paper is broken, the link to
> "Publications" in the menu on the left side works. That shows the
> paper is behind a paywall.
>
> https://pulp-platform.github.io/snitch/publications/
>
> John Savard

Try https://arxiv.org/abs/2011.08070
possibly an earlier version (2020 versus 2021)

On Friday, June 2, 2023 at 1:58:24 AM UTC-5, Quadibloc wrote:
> On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
> > On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
>
> > > From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma". https://pulp-platform.github.io/snitch/rm/custom_instructions/
> > <
> > xfrep is basically equivalent to my LOOP instruction.
> And xssr handles vectors by turning some registers into portals to vectors in memory.
>
> So, while a Cray worked on vectors in big vector registers, this design works on
> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
> in competition with the Cray I.
<
I think you are making a mistake of turning that turning a few registers into memory
portals makes the ISA memory-to-memory. There are all sorts of ways, that after
describing the address pattern, that the number crunching part pulls operands from
some of the portals and pushes results into other portals; to make the portals "flow"
more than 1 operand per cycle.
<
The paper describes things I have considered in implementing VVM on larger machines.
I just did not go so far are to describe the stream as memory portals.
>
> This is why I tend to think that the NEC SX-Aurora TSUBASA is doing it the "right" way,
> but faces the problem of being stuck at 14nm because there's just not enough of a
> supercomputer market to support custom development of this kind of chip.
<
There is a huge market for supercomputers.
There is scant market for $10M+ supercomputers.
>
> And so this is why my thinking goes in the direction of: NEC should design a smaller
> version of their processor, not as powerful, but get economies of mass manufacture
> by convincing, say, SONY to put it in their next PlayStation! That way, computers in
> general would advance to being much more powerful.
<
I remember a comment back when I was designing a 6-wide GBOoO machine that
could utilize 16-DRAM DIMMs simultaneously. The comment was "Apple will only
sell it with 1 DRAM DIMM".
>
> Using a scoreboard instead of GBOoO, of course, is an approach you're likely very
> sympathetic to, and so if this works well, you would definitely be vindicated.
<
Scoreboards and reservation stations both do similar things, and if you descend from
5,000 feet to 20 feet, you can turn the CAMs of a reservation station into a dependence
matrix of the ScoreBoard. In effect, instead of broadcasting 6×8-bit tags per cycle,
you decode the tags locally and assert 6 of 128 wires--saving power without reducing
the amount of information flowing from calculation unit to instruction pickers.
>
> John Savard

On Friday, June 2, 2023 at 5:25:42 PM UTC-6, MitchAlsup wrote:

> Scoreboards and reservation stations both do similar things, and if you descend from
> 5,000 feet to 20 feet, you can turn the CAMs of a reservation station into a dependence
> matrix of the ScoreBoard. In effect, instead of broadcasting 6×8-bit tags per cycle,
> you decode the tags locally and assert 6 of 128 wires--saving power without reducing
> the amount of information flowing from calculation unit to instruction pickers.

So you're basically outlining a *third* way to implement classic OoO: there's reservation
stations, there's register renaming, and now there's a modified scoreboard.

John Savard

On Saturday, June 3, 2023 at 7:54:09 AM UTC+1, Quadibloc wrote:
> On Friday, June 2, 2023 at 5:25:42 PM UTC-6, MitchAlsup wrote:
>
> > Scoreboards and reservation stations both do similar things, and if you descend from
> > 5,000 feet to 20 feet, you can turn the CAMs of a reservation station into a dependence
> > matrix of the ScoreBoard. In effect, instead of broadcasting 6×8-bit tags per cycle,
> > you decode the tags locally and assert 6 of 128 wires--saving power without reducing
> > the amount of information flowing from calculation unit to instruction pickers.
> So you're basically outlining a *third* way to implement classic OoO: there's reservation
> stations, there's register renaming, and now there's a modified scoreboard.

i did an explanation of how to transform Tomasulo
into 6600-style Precise Scoreboards. topologically
they are not much different, but one very important
factor is that the size of the Reorder Buffer *must*
be equal to the number of Reservation Stations, which
no longer preserve instruction ordering "numerically"
(round-robin on the ROB numbers): instead you
have a bit-matrix to create a "linked-list" of the
instruction order, instead.

from there the topological-transformation falls into
place. the above is just another way of Mitch saying
"turn the CAMs of a RS into DMs of Scoreboard".

https://libre-soc.org/3d_gpu/architecture/tomasulo_transformation/

the second part of what Mitch is saying is that now
that you have 128 *unary bits* to assert (and then
read), if you want to do 6-way Multi-Issue you can
simply assert 6 bits. "read" becomes a AND gate.

contrast that with Tomasulo CAMs and you need
a 6W CAM which as a task given to a gate-layout
Engineer will make them think you've got two heads
or something (a la Zaphod Beetlebrox)

l.

On Saturday, June 3, 2023 at 3:50:53 AM UTC-5, luke.l...@gmail.com wrote:
> On Saturday, June 3, 2023 at 7:54:09 AM UTC+1, Quadibloc wrote:
> > On Friday, June 2, 2023 at 5:25:42 PM UTC-6, MitchAlsup wrote:
> >
> > > Scoreboards and reservation stations both do similar things, and if you descend from
> > > 5,000 feet to 20 feet, you can turn the CAMs of a reservation station into a dependence
> > > matrix of the ScoreBoard. In effect, instead of broadcasting 6×8-bit tags per cycle,
> > > you decode the tags locally and assert 6 of 128 wires--saving power without reducing
> > > the amount of information flowing from calculation unit to instruction pickers.
> > So you're basically outlining a *third* way to implement classic OoO: there's reservation
> > stations, there's register renaming, and now there's a modified scoreboard.
> i did an explanation of how to transform Tomasulo
> into 6600-style Precise Scoreboards. topologically
> they are not much different, but one very important
> factor is that the size of the Reorder Buffer *must*
> be equal to the number of Reservation Stations, which
> no longer preserve instruction ordering "numerically"
> (round-robin on the ROB numbers): instead you
> have a bit-matrix to create a "linked-list" of the
> instruction order, instead.
>
> from there the topological-transformation falls into
> place. the above is just another way of Mitch saying
> "turn the CAMs of a RS into DMs of Scoreboard".
>
> https://libre-soc.org/3d_gpu/architecture/tomasulo_transformation/
>
> the second part of what Mitch is saying is that now
> that you have 128 *unary bits* to assert (and then
> read), if you want to do 6-way Multi-Issue you can
> simply assert 6 bits. "read" becomes a AND gate.
>
> contrast that with Tomasulo CAMs and you need
> a 6W CAM which as a task given to a gate-layout
> Engineer will make them think you've got two heads
> or something (a la Zaphod Beetlebrox)
<
On my GBOoO designs, the CAMs only look at 1 of the
6 tag-busses; yes all 6 tag-busses go to every CAM,
but during INSERT the renamer tells the CAM which FU
will produce the result, and so there is a 6-way mux from
the tag-busses to the CAM, and the CAM only looks at a
single bus.
>
> l.

>xfrep is basically equivalent to my LOOP instruction.

>Yup, and there is the CDC6600 with implied loads and stores. Some of the
> TI chips had 2D DMA engines. The ITH Zurich group is also looking into
> sparse vector acceleration: Indirection Stream Semantic Register
> Architecture for Efficient Sparse-Dense Linear Algebra, Paul Scheffler 2020 etal.

And Wulf’s WM ?
https://dl.acm.org/doi/pdf/10.1145/44571.44577

On 6/4/2023 7:22 AM, mac wrote:
>> xfrep is basically equivalent to my LOOP instruction.
>
>> Yup, and there is the CDC6600 with implied loads and stores. Some of the
>> TI chips had 2D DMA engines. The ITH Zurich group is also looking into
>> sparse vector acceleration: Indirection Stream Semantic Register
>> Architecture for Efficient Sparse-Dense Linear Algebra, Paul Scheffler 2020 etal.
>
> And Wulf’s WM ?
> https://dl.acm.org/doi/pdf/10.1145/44571.44577

Bill was an old buddy of mine. He looked like the canonical Air Force
Lt. Colonel, while I looked like a disreputable hippie, so wherever we
went we were sure of offending someone.

The WM two-fer instructions might be seen as the philosophical ancestor
of Mill ganged ops. Two-fers were of greater use in WM as it was a
semantically lower level ISA that had to encode in fixed sized words.
Mill is higher level and lacks the encoding constraint.

The most useful WM two-fer is in addressing where the three-argument
two-fer lets you pack both the sums into one (two-fer) instruction; Mill
just lets you have three-operand subscripted load/store as primitive and
doesn't have to worry about encoding bits.

The second most useful pattern was cascading an arithmetic op into a
compare. That's a gang on Mill.

MitchAlsup <MitchAlsup@aol.com> wrote:
> On Friday, June 2, 2023 at 1:58:24 AM UTC-5, Quadibloc wrote:
>> On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
>>> On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
>>
>>>> From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma".
>>>> https://pulp-platform.github.io/snitch/rm/custom_instructions/
>>> <
>>> xfrep is basically equivalent to my LOOP instruction.
>> And xssr handles vectors by turning some registers into portals to vectors in memory.
>>
>> So, while a Cray worked on vectors in big vector registers, this design works on
>> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
>> in competition with the Cray I.
> <
> I think you are making a mistake of turning that turning a few registers into memory
> portals makes the ISA memory-to-memory. There are all sorts of ways, that after
> describing the address pattern, that the number crunching part pulls operands from
> some of the portals and pushes results into other portals; to make the portals "flow"
> more than 1 operand per cycle.
> <
> The paper describes things I have considered in implementing VVM on larger machines.
> I just did not go so far are to describe the stream as memory portals.
>>
>> This is why I tend to think that the NEC SX-Aurora TSUBASA is doing it the "right" way,
>> but faces the problem of being stuck at 14nm because there's just not enough of a
>> supercomputer market to support custom development of this kind of chip.
> <
> There is a huge market for supercomputers.
> There is scant market for $10M+ supercomputers.
>>
>> And so this is why my thinking goes in the direction of: NEC should design a smaller
>> version of their processor, not as powerful, but get economies of mass manufacture
>> by convincing, say, SONY to put it in their next PlayStation! That way, computers in
>> general would advance to being much more powerful.
> <
> I remember a comment back when I was designing a 6-wide GBOoO machine that
> could utilize 16-DRAM DIMMs simultaneously. The comment was "Apple will only
> sell it with 1 DRAM DIMM".

With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
carrier, quadrupling the dram bandwidth.

>> Using a scoreboard instead of GBOoO, of course, is an approach you're likely very
>> sympathetic to, and so if this works well, you would definitely be vindicated.
> <
> Scoreboards and reservation stations both do similar things, and if you descend from
> 5,000 feet to 20 feet, you can turn the CAMs of a reservation station into a dependence
> matrix of the ScoreBoard. In effect, instead of broadcasting 6×8-bit tags per cycle,
> you decode the tags locally and assert 6 of 128 wires--saving power without reducing
> the amount of information flowing from calculation unit to instruction pickers.
>>
>> John Savard
>

On Wednesday, June 7, 2023 at 4:42:36 PM UTC-5, Brett wrote:
> MitchAlsup <Mitch...@aol.com> wrote:
> > On Friday, June 2, 2023 at 1:58:24 AM UTC-5, Quadibloc wrote:
> >> On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
> >>> On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
> >>
> >>>> From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma".
> >>>> https://pulp-platform.github.io/snitch/rm/custom_instructions/
> >>> <
> >>> xfrep is basically equivalent to my LOOP instruction.
> >> And xssr handles vectors by turning some registers into portals to vectors in memory.
> >>
> >> So, while a Cray worked on vectors in big vector registers, this design works on
> >> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
> >> in competition with the Cray I.
> > <
> > I think you are making a mistake of turning that turning a few registers into memory
> > portals makes the ISA memory-to-memory. There are all sorts of ways, that after
> > describing the address pattern, that the number crunching part pulls operands from
> > some of the portals and pushes results into other portals; to make the portals "flow"
> > more than 1 operand per cycle.
> > <
> > The paper describes things I have considered in implementing VVM on larger machines.
> > I just did not go so far are to describe the stream as memory portals.
> >>
> >> This is why I tend to think that the NEC SX-Aurora TSUBASA is doing it the "right" way,
> >> but faces the problem of being stuck at 14nm because there's just not enough of a
> >> supercomputer market to support custom development of this kind of chip.
> > <
> > There is a huge market for supercomputers.
> > There is scant market for $10M+ supercomputers.
> >>
> >> And so this is why my thinking goes in the direction of: NEC should design a smaller
> >> version of their processor, not as powerful, but get economies of mass manufacture
> >> by convincing, say, SONY to put it in their next PlayStation! That way, computers in
> >> general would advance to being much more powerful.
> > <
> > I remember a comment back when I was designing a 6-wide GBOoO machine that
> > could utilize 16-DRAM DIMMs simultaneously. The comment was "Apple will only
> > sell it with 1 DRAM DIMM".
<
> With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
> carrier, quadrupling the dram bandwidth.
<
And makes upgrading DRAM size impossible.
<
> >> Using a scoreboard instead of GBOoO, of course, is an approach you're likely very
> >> sympathetic to, and so if this works well, you would definitely be vindicated.
> > <
> > Scoreboards and reservation stations both do similar things, and if you descend from
> > 5,000 feet to 20 feet, you can turn the CAMs of a reservation station into a dependence
> > matrix of the ScoreBoard. In effect, instead of broadcasting 6×8-bit tags per cycle,
> > you decode the tags locally and assert 6 of 128 wires--saving power without reducing
> > the amount of information flowing from calculation unit to instruction pickers.
> >>
> >> John Savard
> >

MitchAlsup wrote:
> On Wednesday, June 7, 2023 at 4:42:36 PM UTC-5, Brett wrote:
>> MitchAlsup <Mitch...@aol.com> wrote:
>>> On Friday, June 2, 2023 at 1:58:24 AM UTC-5, Quadibloc wrote:
>>>> On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
>>>>> On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
>>>>
>>>>>> From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma".
>>>>>> https://pulp-platform.github.io/snitch/rm/custom_instructions/
>>>>> <
>>>>> xfrep is basically equivalent to my LOOP instruction.
>>>> And xssr handles vectors by turning some registers into portals to vectors in memory.
>>>>
>>>> So, while a Cray worked on vectors in big vector registers, this design works on
>>>> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
>>>> in competition with the Cray I.
>>> <
>>> I think you are making a mistake of turning that turning a few registers into memory
>>> portals makes the ISA memory-to-memory. There are all sorts of ways, that after
>>> describing the address pattern, that the number crunching part pulls operands from
>>> some of the portals and pushes results into other portals; to make the portals "flow"
>>> more than 1 operand per cycle.
>>> <
>>> The paper describes things I have considered in implementing VVM on larger machines.
>>> I just did not go so far are to describe the stream as memory portals.
>>>>
>>>> This is why I tend to think that the NEC SX-Aurora TSUBASA is doing it the "right" way,
>>>> but faces the problem of being stuck at 14nm because there's just not enough of a
>>>> supercomputer market to support custom development of this kind of chip.
>>> <
>>> There is a huge market for supercomputers.
>>> There is scant market for $10M+ supercomputers.
>>>>
>>>> And so this is why my thinking goes in the direction of: NEC should design a smaller
>>>> version of their processor, not as powerful, but get economies of mass manufacture
>>>> by convincing, say, SONY to put it in their next PlayStation! That way, computers in
>>>> general would advance to being much more powerful.
>>> <
>>> I remember a comment back when I was designing a 6-wide GBOoO machine that
>>> could utilize 16-DRAM DIMMs simultaneously. The comment was "Apple will only
>>> sell it with 1 DRAM DIMM".
> <
>> With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
>> carrier, quadrupling the dram bandwidth.
> <
> And makes upgrading DRAM size impossible.

I am pretty sure that was done after getting some (automatic telemetry?)
statistics about how many Apple machines are ever modified by adding RAM
after purchase.

I always used to do this, but my two latest work machines (2.5 and 5
years old) both came with their max config of 32 GB, and I have never
felt a big need to upgrade this.

On the not unreasonable assumption that the average Apple buyer is less
inclined to modify their machines, I'm guessing the actual percentage of
RAM upgrades have been well under 1%.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Friday, June 9, 2023 at 8:41:03 AM UTC+3, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Wednesday, June 7, 2023 at 4:42:36 PM UTC-5, Brett wrote:
> >> MitchAlsup <Mitch...@aol.com> wrote:
> >>> On Friday, June 2, 2023 at 1:58:24 AM UTC-5, Quadibloc wrote:
> >>>> On Thursday, June 1, 2023 at 4:57:11 PM UTC-6, MitchAlsup wrote:
> >>>>> On Thursday, June 1, 2023 at 5:45:55 PM UTC-5, JimBrakefield wrote:
> >>>>
> >>>>>> From the "Snitch" web page: "custom ISA extensions Xssr, Xfrep, and Xdma".
> >>>>>> https://pulp-platform.github.io/snitch/rm/custom_instructions/
> >>>>> <
> >>>>> xfrep is basically equivalent to my LOOP instruction.
> >>>> And xssr handles vectors by turning some registers into portals to vectors in memory.
> >>>>
> >>>> So, while a Cray worked on vectors in big vector registers, this design works on
> >>>> vectors in memory... like a STAR-100. Which, as we all remember, was a _failure_
> >>>> in competition with the Cray I.
> >>> <
> >>> I think you are making a mistake of turning that turning a few registers into memory
> >>> portals makes the ISA memory-to-memory. There are all sorts of ways, that after
> >>> describing the address pattern, that the number crunching part pulls operands from
> >>> some of the portals and pushes results into other portals; to make the portals "flow"
> >>> more than 1 operand per cycle.
> >>> <
> >>> The paper describes things I have considered in implementing VVM on larger machines.
> >>> I just did not go so far are to describe the stream as memory portals..
> >>>>
> >>>> This is why I tend to think that the NEC SX-Aurora TSUBASA is doing it the "right" way,
> >>>> but faces the problem of being stuck at 14nm because there's just not enough of a
> >>>> supercomputer market to support custom development of this kind of chip.
> >>> <
> >>> There is a huge market for supercomputers.
> >>> There is scant market for $10M+ supercomputers.
> >>>>
> >>>> And so this is why my thinking goes in the direction of: NEC should design a smaller
> >>>> version of their processor, not as powerful, but get economies of mass manufacture
> >>>> by convincing, say, SONY to put it in their next PlayStation! That way, computers in
> >>>> general would advance to being much more powerful.
> >>> <
> >>> I remember a comment back when I was designing a 6-wide GBOoO machine that
> >>> could utilize 16-DRAM DIMMs simultaneously. The comment was "Apple will only
> >>> sell it with 1 DRAM DIMM".
> > <
> >> With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
> >> carrier, quadrupling the dram bandwidth.
> > <
> > And makes upgrading DRAM size impossible.
> I am pretty sure that was done after getting some (automatic telemetry?)
> statistics about how many Apple machines are ever modified by adding RAM
> after purchase.
>
> I always used to do this, but my two latest work machines (2.5 and 5
> years old) both came with their max config of 32 GB, and I have never
> felt a big need to upgrade this.
>
> On the not unreasonable assumption that the average Apple buyer is less
> inclined to modify their machines, I'm guessing the actual percentage of
> RAM upgrades have been well under 1%.
>

For majority of Macs - sure. Esp. considering that for majority of the models
it's simply impossible.
But specifically for cheese grater Mac Pro I wouldn't be so sure. Fully loaded
with memory it is VERY expensive even by Apple standards. So I can see people
originally buying more modest configuration and then upgrading after they found
out that they really need more.
But then, my knowledge of habits of Mac users is weak.

> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>MitchAlsup wrote:
>> On Wednesday, June 7, 2023 at 4:42:36 PM UTC-5, Brett wrote:
>>> With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
>>> carrier, quadrupling the dram bandwidth.
>> <
>> And makes upgrading DRAM size impossible.
>
>I am pretty sure that was done after getting some (automatic telemetry?)
>statistics about how many Apple machines are ever modified by adding RAM
>after purchase.

Sure. Every time a user upgraded the RAM, that was a lost opportunity
of a sale of a complete Apple machine. And they probably lost even
their ample margins on the DIMMs (or have they locked the hardware
such that it can only use Apple-supplied DIMMs?).

>I always used to do this, but my two latest work machines (2.5 and 5
>years old) both came with their max config of 32 GB, and I have never
>felt a big need to upgrade this.

Max config of 32GB? The maximum size of one DDR4 DIMM is 32GB. Did you
buy machines with only one DIMM slot? Or with soldered DRAM?

>On the not unreasonable assumption that the average Apple buyer is less
>inclined to modify their machines, I'm guessing the actual percentage of
>RAM upgrades have been well under 1%.

A collegue of mine had some Apple laptop with soldered RAM, and found
that the RAM became insufficient for processing his emails. So he
bought another laptop, this time with 64GB, which means that it was
extra expensive, but for some reason he still chose an Apple. So
Apple certainly profitted a lot from the non-upgradeability: Not only
did he buy a complete new machine, he also bought it with an
extra-large amount of RAM (at extreme prices) to avoid having to
upgrade for this reason again.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, June 9, 2023 at 1:58:32 PM UTC+3, Anton Ertl wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> >MitchAlsup wrote:
> >> On Wednesday, June 7, 2023 at 4:42:36 PM UTC-5, Brett wrote:
> >>> With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
> >>> carrier, quadrupling the dram bandwidth.
> >> <
> >> And makes upgrading DRAM size impossible.
> >
> >I am pretty sure that was done after getting some (automatic telemetry?)
> >statistics about how many Apple machines are ever modified by adding RAM
> >after purchase.
> Sure. Every time a user upgraded the RAM, that was a lost opportunity
> of a sale of a complete Apple machine. And they probably lost even
> their ample margins on the DIMMs (or have they locked the hardware
> such that it can only use Apple-supplied DIMMs?).
> >I always used to do this, but my two latest work machines (2.5 and 5
> >years old) both came with their max config of 32 GB, and I have never
> >felt a big need to upgrade this.
> Max config of 32GB? The maximum size of one DDR4 DIMM is 32GB.

So, you say, I can upgrade E-2176G based development server to
128 GB without losing bandwidth or latency?
By now, with 16GB DIMMs, it appears to operate at max rate (2666 MT/s),
but I am not sure about latency.

> Did you
> buy machines with only one DIMM slot? Or with soldered DRAM?
> >On the not unreasonable assumption that the average Apple buyer is less
> >inclined to modify their machines, I'm guessing the actual percentage of
> >RAM upgrades have been well under 1%.
> A collegue of mine had some Apple laptop with soldered RAM, and found
> that the RAM became insufficient for processing his emails. So he
> bought another laptop, this time with 64GB, which means that it was
> extra expensive, but for some reason he still chose an Apple. So
> Apple certainly profitted a lot from the non-upgradeability: Not only
> did he buy a complete new machine, he also bought it with an
> extra-large amount of RAM (at extreme prices) to avoid having to
> upgrade for this reason again.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>So, you say, I can upgrade E-2176G based development server to
>128 GB without losing bandwidth or latency?=20
>By now, with 16GB DIMMs, it appears to operate at max rate (2666 MT/s),=20
>but I am not sure about latency.

I am just saying that you can upgrade it to 128GB. However, if you
now use 4 two-sided 16GB DIMMs, I don't expect bandwidth or latency to
get worse if you change to 4 32GB DIMMs. If you have only 2 DIMMs, or
4 one-sided DIMMs, you may see worse numbers, but for a development
server I don't expect it to translate into a noticable slowdown.

We have Xeon E-2388G servers with 128GB here, and what dmidecode tells
me about one of the DIMMs is:

Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> MitchAlsup wrote:
>>> On Wednesday, June 7, 2023 at 4:42:36 PM UTC-5, Brett wrote:
>>>> With the M2 machines Apple has dumped DIMMs and brought RAM onto the CPU
>>>> carrier, quadrupling the dram bandwidth.
>>> <
>>> And makes upgrading DRAM size impossible.
>>
>> I am pretty sure that was done after getting some (automatic telemetry?)
>> statistics about how many Apple machines are ever modified by adding RAM
>> after purchase.
>
> Sure. Every time a user upgraded the RAM, that was a lost opportunity
> of a sale of a complete Apple machine. And they probably lost even
> their ample margins on the DIMMs (or have they locked the hardware
> such that it can only use Apple-supplied DIMMs?).
>
>> I always used to do this, but my two latest work machines (2.5 and 5
>> years old) both came with their max config of 32 GB, and I have never
>> felt a big need to upgrade this.
>
> Max config of 32GB? The maximum size of one DDR4 DIMM is 32GB. Did you
> buy machines with only one DIMM slot? Or with soldered DRAM?

The 5 year old had two RAM slots, each with 16 GB max.

The new machine was from a new job/new company, with much smaller
formfactor, and no real options for changing config.

Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz

>
>> On the not unreasonable assumption that the average Apple buyer is less
>> inclined to modify their machines, I'm guessing the actual percentage of
>> RAM upgrades have been well under 1%.
>
> A collegue of mine had some Apple laptop with soldered RAM, and found
> that the RAM became insufficient for processing his emails. So he
> bought another laptop, this time with 64GB, which means that it was
> extra expensive, but for some reason he still chose an Apple. So
> Apple certainly profitted a lot from the non-upgradeability: Not only
> did he buy a complete new machine, he also bought it with an
> extra-large amount of RAM (at extreme prices) to avoid having to
> upgrade for this reason again.
>
> - anton
>
:-(

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Michael S <already5chosen@yahoo.com> writes:
>>So, you say, I can upgrade E-2176G based development server to
>>128 GB without losing bandwidth or latency?=20
>>By now, with 16GB DIMMs, it appears to operate at max rate (2666 MT/s),=20
>>but I am not sure about latency.
>
>I am just saying that you can upgrade it to 128GB. However, if you
>now use 4 two-sided 16GB DIMMs, I don't expect bandwidth or latency to
>get worse if you change to 4 32GB DIMMs. If you have only 2 DIMMs, or
>4 one-sided DIMMs, you may see worse numbers, but for a development
>server I don't expect it to translate into a noticable slowdown.
>
>We have Xeon E-2388G servers with 128GB here, and what dmidecode tells
>me about one of the DIMMs is:
>
> Speed: 3200 MT/s
> Configured Memory Speed: 2933 MT/s

Our development machine has 380GB, DDR4, all at the
same speed as yours using 48 DIMMs.

$ grep DIMM /tmp/dmi.decode | wc -l
48
model name : Intel(R) Xeon(R) Gold 6246R CPU @ 3.40GHz