On Wednesday, August 16, 2023 at 6:04:50 PM UTC+1, pec...@gmail.com wrote:
> Big cores perform most of the floating point operations in the SIMD units.

ahh but bcoz RISK-5 Vectors, there ain't no SIMD satisfaction...

l.

On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:

> Conversely all static VLIW forms have failed.

could you give examples of "static VLIW"? i am currently
designing an 8-bit ISA, which is so insanely short it may
have to go VLIW, and would prefer it greatly if i actually
knew what had and hadn't failed in this space :)

l.

On Wednesday, August 16, 2023 at 9:09:23 PM UTC+1, Timothy McCaffrey wrote:

> I don't think it was purely religious. If you have a fixed size (power of 2 size) instruction it will:
> b) Your page fault handler never has to test to see if this
> instruction straddles a page boundary and make sure both pages are present.
>
> Are these a *real* problem?

(on D-Cache side)
when you have to solve multi-issue massive numbers of LD/ST issue
at the same time in the same clock cycle, looking for merges and
overlaps... yes! Power ISA solves this by setting limits @ (i think)
20-bit of addresses (where 4k/64k of that is the page size).
if you cross over a boundary of 20-bit *then* a page-fault must
be raised.

(on I-Cache side)
you can get away with doing what Power ISA does which is to set
limits on 64-word-aligned roll-over. the 64-bit instruction encoding
is prohibited from falling on a pair of 64-word-aligned blocks.
that gives pretty damn good multi-issue opportunities without
the disadvantage of wasting vast amounts of space with nops
or complexifying the compiler.

l.

On Wednesday, August 16, 2023 at 9:19:52 PM UTC+1, Timothy McCaffrey wrote:

> Given a variable length instruction set, it seems to me it makes sense to encode the most used
> instructions into small instructions, if possible. I believe I have read that the most used
> instructions are load, compare, add and branch. The rest are in the single digits percentage wise.
> (I wish I had a reference, so take the above with a rock sized grain of salt). Anyway, if
> you could encode those instructions into a 16 bit word, and leave the longer instructions
> for all the useful but not used that much remainder, wouldn't that basically "compress"
> your instruction set (even if variants of the longer instructions "overlapped" the short instructions,
> it would probably still be a win).

it gets complicated, *real* fast.

the very act of adding the compressed instructions means that their
limitations (access to a reduced register range for example) now puts
pressure on those registers, such that only *some* functions gain
advantage but others (with more parameters in an ABI) would not...

plus there is a similar distortion based on the ops themselves.
if you happened to make the statistical assessment based on a
limited suite of software, you end up designing something that's
fantastic for those limited applications and crap at everything else.
(someone already mentioned FP a few posts back).

our team attempted to design Compressed encoding for Power ISA:
the code-size gains, based on register allocation by gcc of Power v3.0
compiled binaries, were... disappointing. i was quite surprised.

l.

On Saturday, August 26, 2023 at 5:04:13 PM UTC-5, luke.l...@gmail.com wrote:
> On Monday, August 14, 2023 at 7:28:58 PM UTC+1, BGB wrote:
>
> > It matters if you care about a 10% to 30% delta in code-density, but is
> > mostly irrelevant for performance if one has a "sufficient" I-cache
> > (say, 16K or more).
>
> unfortunately the impact on power of increased code-density
> is a square law related to the i-cache size, not a linear one.
> thus a 10% increase in code size results in appx 1.1^2=21%
> power consumption increase.
<
Is there published literature on this ??
>
> On Tuesday, August 15, 2023 at 12:17:09 AM UTC+1, Brett wrote:
>
> > This is the killer argument that would have saved me from caring about 16
> > bit opcodes.
> > Only toy CPU’s can care about 16 bit opcodes.
>
> don't let Hitachi/Renesas (sh2 / sh4) or the J-Core team hear you say that :)
>
> https://en.wikipedia.org/wiki/SuperH
> https://j-core.org/
>
> l.

On Saturday, August 26, 2023 at 5:11:44 PM UTC-5, luke.l...@gmail.com wrote:
> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
>
> > Conversely all static VLIW forms have failed.
>
> could you give examples of "static VLIW"? i am currently
> designing an 8-bit ISA, which is so insanely short it may
> have to go VLIW, and would prefer it greatly if i actually
> knew what had and hadn't failed in this space :)
>
Multiflow
Cydrome
I860
Trimedia
SHARC
Itanic
Elbrus
and maybe MILL
> l.

On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:
> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
>
>> Conversely all static VLIW forms have failed.
>
> could you give examples of "static VLIW"? i am currently
> designing an 8-bit ISA, which is so insanely short it may
> have to go VLIW, and would prefer it greatly if i actually
> knew what had and hadn't failed in this space :)
>

I guess, unambiguously failed:
IA-64;
TriMedia;
Transmeta (VLIW internally, x86 as surface-level ISA).

Moderate success:
TMS320C6x
Qualcomm Hexagon

Mixed:
ESP32
Its official successor jumped to RISC-V instead
Apparently as a single-issue RISC core.
But, ESP32 still seems to be popular.
AMD TeraScale
Replaced with GCN:
GCN was apparently a single-issue scalar design;
Followed by RDNA, which apparently kept GCN's ISA.

But, I can also note that the vast majority of RISC's that had once
existed have also effectively died off...

Apart from IA-64, most of the failure cases seem to be either:
The parent company died (TriMedia and Transmeta);
The successors typically went to single-issue / scalar cores.

This doesn't appear to be a good example of a critical weakness of VLIW
as a concept, as then one would have expected the typical successors to
have gone to superscalar or OoO.

On 8/26/2023 8:01 PM, BGB wrote:
> On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:
>> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
>>
>>> Conversely all static VLIW forms have failed.
>>
>> could you give examples of "static VLIW"? i am currently
>> designing an 8-bit ISA, which is so insanely short it may
>> have to go VLIW, and would prefer it greatly if i actually
>> knew what had and hadn't failed in this space :)
>>
>
> I guess, unambiguously failed:
>   IA-64;
>   TriMedia;
>   Transmeta (VLIW internally, x86 as surface-level ISA).
>
> Moderate success:
>   TMS320C6x
>   Qualcomm Hexagon
>
> Mixed:
>   ESP32
>     Its official successor jumped to RISC-V instead
>       Apparently as a single-issue RISC core.
>     But, ESP32 still seems to be popular.
>   AMD TeraScale
>     Replaced with GCN:
>       GCN was apparently a single-issue scalar design;
>     Followed by RDNA, which apparently kept GCN's ISA.
>
>
> But, I can also note that the vast majority of RISC's that had once
> existed have also effectively died off...

I think that it is also true that the vast majority of CISCs that had
once existed have also effectively died off... :-(

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

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 8/24/2023 12:02 PM, MitchAlsup wrote:
>> On Tuesday, August 22, 2023 at 6:04:34 PM UTC-5, Paul A. Clayton wrote:
>>> On 8/19/23 12:31 PM, MitchAlsup wrote:
>> [snip]
>>>
>>> While you, Mitch, have argued persuasively for a unified register
>>> set, there are some benefits to architectural specialization. Of
>>> course, microarchitectural specialization can be applied if there
>>> is a natural idiom which can be easily detected. An artificial
>>> convention (optimization recommendation) can also provide such an
>>> idiom.
>> <
>> Allow me to clarify::
>> <
>> I am not trying to create and architecture which is
>> a) a marvelous microcontroller CPU
>> b) a marvelous vector supercomputer CPU
>
> OK, I will ask. If you were trying to create a marvelous vector
> supercomputer CPU, how would it be different from MY66000?

Mitch already answered, just one remark...

Today's supercomputing is mainly about graphics cards, for those
workloads where this is an advantage. Memory bandwidth between
CPU and GPU can be a major bottleneck there, and registers on the
graphics card itself are also a very limited resource.

And high performance for graphics cards is very difficult to
achieve for compilers, you need to look into details (and tune a
lot by hand; fortunately the tuning tools are quite good) to get
close to the optimum performance. And divergent branches, when
threads within a warp take different paths, are also a potential
performance killer.

Some of you may remember "same sum of digits up to some prime
number" hobby project I was doing a couple of years ago (see
https://oeis.org/A345296 ). I am getting help from somebody with
a lot of graphics cards fu, and am running a combined GPU+CPU
algorithm. Finding 70911040973874056146188543 in a search that
checks for the same digit sum in basis 2, 3, 5, 7, 11, 13 and 17
now takes around an hour instead of around five days previously,
which is not bad. (We actually found one more number, but are
still looking to extend the number range before publishing on OEIS).

So, I am now learning a bit about graphics card programming.

And how to make a graphics cards ISA that makes things easy for
programmers and compilers... Ugh. This is not helped by having
something like PTX as an intermediate code, so the main compiler
does not even have the information about the available number
of registers.

On Sunday, August 27, 2023 at 6:26:46 AM UTC-5, Thomas Koenig wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:
> > On 8/24/2023 12:02 PM, MitchAlsup wrote:
> >> On Tuesday, August 22, 2023 at 6:04:34 PM UTC-5, Paul A. Clayton wrote:
> >>> On 8/19/23 12:31 PM, MitchAlsup wrote:
> >> [snip]
> >>>
> >>> While you, Mitch, have argued persuasively for a unified register
> >>> set, there are some benefits to architectural specialization. Of
> >>> course, microarchitectural specialization can be applied if there
> >>> is a natural idiom which can be easily detected. An artificial
> >>> convention (optimization recommendation) can also provide such an
> >>> idiom.
> >> <
> >> Allow me to clarify::
> >> <
> >> I am not trying to create and architecture which is
> >> a) a marvelous microcontroller CPU
> >> b) a marvelous vector supercomputer CPU
> >
> > OK, I will ask. If you were trying to create a marvelous vector
> > supercomputer CPU, how would it be different from MY66000?
>
> Mitch already answered, just one remark...
>
> Today's supercomputing is mainly about graphics cards, for those
> workloads where this is an advantage. Memory bandwidth between
> CPU and GPU can be a major bottleneck there, and registers on the
> graphics card itself are also a very limited resource.
<
Where limited means each shader core gets 1024-2048 of these registers.
>
> And high performance for graphics cards is very difficult to
> achieve for compilers, you need to look into details (and tune a
> lot by hand; fortunately the tuning tools are quite good) to get
> close to the optimum performance. And divergent branches, when
> threads within a warp take different paths, are also a potential
> performance killer.
<
They are also a performance killer in normal vector processing, too.
>
> Some of you may remember "same sum of digits up to some prime
> number" hobby project I was doing a couple of years ago (see
> https://oeis.org/A345296 ). I am getting help from somebody with
> a lot of graphics cards fu, and am running a combined GPU+CPU
> algorithm. Finding 70911040973874056146188543 in a search that
> checks for the same digit sum in basis 2, 3, 5, 7, 11, 13 and 17
> now takes around an hour instead of around five days previously,
> which is not bad. (We actually found one more number, but are
> still looking to extend the number range before publishing on OEIS).
>
> So, I am now learning a bit about graphics card programming.
>
> And how to make a graphics cards ISA that makes things easy for
> programmers and compilers... Ugh. This is not helped by having
> something like PTX as an intermediate code, so the main compiler
> does not even have the information about the available number
> of registers.

On Sunday, August 27, 2023 at 4:01:32 AM UTC+1, BGB wrote:
> On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:
> > On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
> >
> >> Conversely all static VLIW forms have failed.
> >
> > could you give examples of "static VLIW"? i am currently
> > designing an 8-bit ISA, which is so insanely short it may
> > have to go VLIW, and would prefer it greatly if i actually
> > knew what had and hadn't failed in this space :)
> >
> I guess, unambiguously failed:
> IA-64;
> TriMedia;
> Transmeta (VLIW internally, x86 as surface-level ISA).

(thank you to both - ok i now get it).

> Moderate success:
> TMS320C6x
> Qualcomm Hexagon

ok Hexagon is entirely proprietary and is in *all* Qualcomm
ARM/SoC products as the R.F. base-band processor. not going away
soon.

TI's TMS320 series is... an anomaly that is likely down to
it being mostly used by military/defense customers of TI
(radar, signal processing) and just being damn good. CEDAR
Audio used it for example to achieve 50 MFLOPs (1000 ops
per audio sample) and was able to do real-time audio processing
*in 1990* for goodness sake. we had to do assembly-level
programming, because the compilers were shite, but it *worked*
and it was simple enough to do because the 7+7 VLIW slots
were allocated to Left+Right Audio Channels. blam. done.

> But, I can also note that the vast majority of RISC's that had once
> existed have also effectively died off...

like Elvis, ARC didn't die, it "just went away" (got bought by Synopsis)
and is used as the basis of Broadcom's VideoCore IV (big mass-volume,
ain't gonna die as long as Broadcom doesn't die)

likewise Tensilica got bought by Cadence a few years after they'd
sold their BILLIONTH license (!!!) back around 2010, mostly in Audio
(where do you think Maxim gets their Audio DSPs from?)

which just leaves the other-VLIWs, and having looked at a couple
they have "slots" (non-uniform instructions). whilst in the TI TMS320
series DSPs they were slow-enough clock rate to be hand-assembly
programmed (FMAC was *only* two cycles @ the 12.5 mhz clock,
Left-Right Odd-Even reg-nums hence 50 MFLOPs), the "slots" in
e.g. the TriMedia VLIW DSPs looked to be absolute hell to work with.

depending on the operation type it would have a *different* length
of completion?? *and* the operations that can be run have to be
in certain "slots", meaning all the hard work is done by the compiler??
i'm not bloody surprised at all that that went down like a lead balloon.

if the VLIW slots were orthogonal *or* the operations were uniform length
i'd say "yyeah that'd be manageable [by assembly-writers and compilers
alike]", but both at the same time?

naah.

l.

On Sunday, August 27, 2023 at 1:27:10 AM UTC-5, Stephen Fuld wrote:
> On 8/26/2023 8:01 PM, BGB wrote:
> > On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:
> >> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
> >>
> >>> Conversely all static VLIW forms have failed.
> >>
> >> could you give examples of "static VLIW"? i am currently
> >> designing an 8-bit ISA, which is so insanely short it may
> >> have to go VLIW, and would prefer it greatly if i actually
> >> knew what had and hadn't failed in this space :)
> >>
> >
> > I guess, unambiguously failed:
> > IA-64;
> > TriMedia;
> > Transmeta (VLIW internally, x86 as surface-level ISA).
> >
> > Moderate success:
> > TMS320C6x
> > Qualcomm Hexagon
> >
> > Mixed:
> > ESP32
> > Its official successor jumped to RISC-V instead
> > Apparently as a single-issue RISC core.
> > But, ESP32 still seems to be popular.
> > AMD TeraScale
> > Replaced with GCN:
> > GCN was apparently a single-issue scalar design;
> > Followed by RDNA, which apparently kept GCN's ISA.
> >
> >
> > But, I can also note that the vast majority of RISC's that had once
> > existed have also effectively died off...
<
> I think that it is also true that the vast majority of CISCs that had
> once existed have also effectively died off... :-(
<
One could argue that the original x86 has also died off, and that
all but a few of the CISCs have similarly died off, especially the
stack machines.
>
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, August 27, 2023 at 1:27:10=E2=80=AFAM UTC-5, Stephen Fuld wrote:
>> On 8/26/2023 8:01 PM, BGB wrote:=20
>> > On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:=20
>> >> On Wednesday, August 16, 2023 at 7:15:42=E2=80=AFPM UTC+1, MitchAlsup =
>wrote:=20
>> >>=20
>> >>> Conversely all static VLIW forms have failed.=20
>> >>=20
>> >> could you give examples of "static VLIW"? i am currently=20
>> >> designing an 8-bit ISA, which is so insanely short it may=20
>> >> have to go VLIW, and would prefer it greatly if i actually=20
>> >> knew what had and hadn't failed in this space :)=20
>> >>=20
>> >=20
>> > I guess, unambiguously failed:=20
>> > IA-64;=20
>> > TriMedia;=20
>> > Transmeta (VLIW internally, x86 as surface-level ISA).=20
>> >=20
>> > Moderate success:=20
>> > TMS320C6x=20
>> > Qualcomm Hexagon=20
>> >=20
>> > Mixed:=20
>> > ESP32=20
>> > Its official successor jumped to RISC-V instead=20
>> > Apparently as a single-issue RISC core.=20
>> > But, ESP32 still seems to be popular.=20
>> > AMD TeraScale=20
>> > Replaced with GCN:=20
>> > GCN was apparently a single-issue scalar design;=20
>> > Followed by RDNA, which apparently kept GCN's ISA.=20
>> >=20
>> >=20
>> > But, I can also note that the vast majority of RISC's that had once=20
>> > existed have also effectively died off...
><
>> I think that it is also true that the vast majority of CISCs that had=20
>> once existed have also effectively died off... :-(=20
><
>One could argue that the original x86 has also died off, and that
>all but a few of the CISCs have similarly died off, especially the
>stack machines.

Some stack machines still exist, mostly now in emulation.

See clearpath libra.

On Sunday, August 27, 2023 at 11:19:54 AM UTC-5, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Sunday, August 27, 2023 at 1:27:10=E2=80=AFAM UTC-5, Stephen Fuld wrote:
> >> On 8/26/2023 8:01 PM, BGB wrote:=20
> >> > On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:=20
> >> >> On Wednesday, August 16, 2023 at 7:15:42=E2=80=AFPM UTC+1, MitchAlsup =
> >wrote:=20
> >> >>=20
> >> >>> Conversely all static VLIW forms have failed.=20
> >> >>=20
> >> >> could you give examples of "static VLIW"? i am currently=20
> >> >> designing an 8-bit ISA, which is so insanely short it may=20
> >> >> have to go VLIW, and would prefer it greatly if i actually=20
> >> >> knew what had and hadn't failed in this space :)=20
> >> >>=20
> >> >=20
> >> > I guess, unambiguously failed:=20
> >> > IA-64;=20
> >> > TriMedia;=20
> >> > Transmeta (VLIW internally, x86 as surface-level ISA).=20
> >> >=20
> >> > Moderate success:=20
> >> > TMS320C6x=20
> >> > Qualcomm Hexagon=20
> >> >=20
> >> > Mixed:=20
> >> > ESP32=20
> >> > Its official successor jumped to RISC-V instead=20
> >> > Apparently as a single-issue RISC core.=20
> >> > But, ESP32 still seems to be popular.=20
> >> > AMD TeraScale=20
> >> > Replaced with GCN:=20
> >> > GCN was apparently a single-issue scalar design;=20
> >> > Followed by RDNA, which apparently kept GCN's ISA.=20
> >> >=20
> >> >=20
> >> > But, I can also note that the vast majority of RISC's that had once=20
> >> > existed have also effectively died off...
> ><
> >> I think that it is also true that the vast majority of CISCs that had=20
> >> once existed have also effectively died off... :-(=20
> ><
> >One could argue that the original x86 has also died off, and that
> >all but a few of the CISCs have similarly died off, especially the
> >stack machines.
<
> Some stack machines still exist, mostly now in emulation.
<
Would you consider a fountain using an electrical pump to be "like"
Heron's fountain ??
>
> See clearpath libra.

According to MitchAlsup <MitchAlsup@aol.com>:
>> Today's supercomputing is mainly about graphics cards, for those
>> workloads where this is an advantage. ...

Right, for trivially paralellizable workloads, GPUs are great. (It's not
the workload that's trivial, it's finding work to do in parallel that is.)

Europe's latest supercomputer is LUMI which combines 200,000 AMD CPU cores with
some number of AMD Instinct GPUs. It's located in northern Finland so the
electricity comes from a hydro station and the waste heat will provide 20%
of the local city's district heating so it's nominally carbon negative.

It's doing a lot of stuff that GPUs can't do or at least can't do cost
effectively.

The fastest supercomputer is Frontier at Oak Ridge, with 8 million AMD cores
and Instinct accelerators.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, August 27, 2023 at 11:19:54=E2=80=AFAM UTC-5, Scott Lurndal wrot=
>e:
>> MitchAlsup <Mitch...@aol.com> writes:=20
>> >On Sunday, August 27, 2023 at 1:27:10=3DE2=3D80=3DAFAM UTC-5, Stephen Fu=
>ld wrote:=20
>> >> On 8/26/2023 8:01 PM, BGB wrote:=3D20=20
>> >> > On 8/26/2023 5:11 PM, luke.l...@gmail.com wrote:=3D20=20
>> >> >> On Wednesday, August 16, 2023 at 7:15:42=3DE2=3D80=3DAFPM UTC+1, Mi=
>tchAlsup =3D=20
>> >wrote:=3D20=20
>> >> >>=3D20=20
>> >> >>> Conversely all static VLIW forms have failed.=3D20=20
>> >> >>=3D20=20
>> >> >> could you give examples of "static VLIW"? i am currently=3D20=20
>> >> >> designing an 8-bit ISA, which is so insanely short it may=3D20=20
>> >> >> have to go VLIW, and would prefer it greatly if i actually=3D20=20
>> >> >> knew what had and hadn't failed in this space :)=3D20=20
>> >> >>=3D20=20
>> >> >=3D20=20
>> >> > I guess, unambiguously failed:=3D20=20
>> >> > IA-64;=3D20=20
>> >> > TriMedia;=3D20=20
>> >> > Transmeta (VLIW internally, x86 as surface-level ISA).=3D20=20
>> >> >=3D20=20
>> >> > Moderate success:=3D20=20
>> >> > TMS320C6x=3D20=20
>> >> > Qualcomm Hexagon=3D20=20
>> >> >=3D20=20
>> >> > Mixed:=3D20=20
>> >> > ESP32=3D20=20
>> >> > Its official successor jumped to RISC-V instead=3D20=20
>> >> > Apparently as a single-issue RISC core.=3D20=20
>> >> > But, ESP32 still seems to be popular.=3D20=20
>> >> > AMD TeraScale=3D20=20
>> >> > Replaced with GCN:=3D20=20
>> >> > GCN was apparently a single-issue scalar design;=3D20=20
>> >> > Followed by RDNA, which apparently kept GCN's ISA.=3D20=20
>> >> >=3D20=20
>> >> >=3D20=20
>> >> > But, I can also note that the vast majority of RISC's that had once=
>=3D20
>> >> > existed have also effectively died off...=20
>> ><
>> >> I think that it is also true that the vast majority of CISCs that had=
>=3D20=20
>> >> once existed have also effectively died off... :-(=3D20
>> ><=20
>> >One could argue that the original x86 has also died off, and that=20
>> >all but a few of the CISCs have similarly died off, especially the=20
>> >stack machines.
><
>> Some stack machines still exist, mostly now in emulation.=20
><
>Would you consider a fountain using an electrical pump to be "like"=20
>Heron's fountain ??

I wouldn't try to make that analogy in the first place.

The software running on the system believes it is running on
a stack machine. Virtual or otherwise.

On Sunday, August 27, 2023 at 2:46:40 AM UTC+3, MitchAlsup wrote:
> On Saturday, August 26, 2023 at 5:11:44 PM UTC-5, luke.l...@gmail..com wrote:
> > On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
> >
> > > Conversely all static VLIW forms have failed.
> >
> > could you give examples of "static VLIW"? i am currently
> > designing an 8-bit ISA, which is so insanely short it may
> > have to go VLIW, and would prefer it greatly if i actually
> > knew what had and hadn't failed in this space :)
> >
> Multiflow
> Cydrome
> I860

Only 2 verbs per instruction group.

> Trimedia
> SHARC

SHARC/HammerSHARC are not VLIW. One can argue that they are LIW.
Another ADI architecture, TigerSHARC, is VLIW, but uncharacteristically
narrow one.

> Itanic

It lacks one of the key characteristics of VLIW - exposed pipeline.

> Elbrus
> and maybe MILL
> > l.

On 8/26/2023 12:33 PM, MitchAlsup wrote:
> On Saturday, August 26, 2023 at 9:04:22 AM UTC-5, Stephen Fuld wrote:
>> On 8/24/2023 12:02 PM, MitchAlsup wrote:
>>> On Tuesday, August 22, 2023 at 6:04:34 PM UTC-5, Paul A. Clayton wrote:
>>>> On 8/19/23 12:31 PM, MitchAlsup wrote:
>>> [snip]
>>>>
>>>> While you, Mitch, have argued persuasively for a unified register
>>>> set, there are some benefits to architectural specialization. Of
>>>> course, microarchitectural specialization can be applied if there
>>>> is a natural idiom which can be easily detected. An artificial
>>>> convention (optimization recommendation) can also provide such an
>>>> idiom.
>>> <
>>> Allow me to clarify::
>>> <
>>> I am not trying to create and architecture which is
>>> a) a marvelous microcontroller CPU
>>> b) a marvelous vector supercomputer CPU
> <
>> OK, I will ask. If you were trying to create a marvelous vector
>> supercomputer CPU, how would it be different from MY66000?
> <
> What an intriguing question !!

I thought you might like it. :-)

>>
>> Specifically, would you still use the VVM mechanism? How different
>> would the ISA be (or would it just use more FP functional units and
>> perhaps more/bigger buffers for VVM use?)? Would you provide full
>> support for 128 bit FP? etc., etc.
> <
> After thinking about this for an hour::
> <
> ISA would probably be pretty much the same, the memory system and
> interconnect would be vastly beefier. I would shoot for a cache line
> width of FPUs (8)×{FADD, FMAC, FDIV/SQRT} 8 to 16 cache line staging
> buffers, 4 AGENs per cycle, all feeding off the 1MB 16-banked L2, taking
> 4 caches misses per cycle. Then over in the memory/DRAM area there
> would be a minimum of 16 DIMMs (or HBMs) operating at 2 speed
> grades below maximum BW DDR <of that generation> could muster.
> Every lane would be capable of integer and logical calculations.

Your emphasis on memory bandwidth is in line with Seymour Cray's designs
for CDC and Cray, where the vector instructions were supported by a huge
(for the time) memory bandwidth. Of course, you have the "advantage" of
things like DRAMS which have faster access to "close" or even sequential
locations that Cray's SRAM based and lack of cache designs didn't.

This all raises a question about modern supercomputers. As others have
pointed out, most of them toady have large numbers of relatively
standard CPU chips, with or without GPUs with some kink of high speed
interconnect. So the question is, how much of requirement for the large
number of chips is due to adding compute power versus adding memory
bandwidth to the system?

> <
> After writing the above and more thought, I can't see any changes in
> ISA, as we already get gather (LDD->LD) and Scater (LDD-ST) falling
> out for free.

A question about the workloads. Is the use of scatter/gather to
multiple arbitrary locations, or to locations at some "fixed" stride.
If the latter, would it make sens to add some sort of stride detector to
the VVM buffers?

> <
> My hope would be that it would not melt when operating at full throughput.

:-)

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

On 8/28/2023 10:25 AM, Michael S wrote:
> On Sunday, August 27, 2023 at 2:46:40 AM UTC+3, MitchAlsup wrote:
>> On Saturday, August 26, 2023 at 5:11:44 PM UTC-5, luke.l...@gmail.com wrote:
>>> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
>>>
>>>> Conversely all static VLIW forms have failed.
>>>
>>> could you give examples of "static VLIW"? i am currently
>>> designing an 8-bit ISA, which is so insanely short it may
>>> have to go VLIW, and would prefer it greatly if i actually
>>> knew what had and hadn't failed in this space :)
>>>
>> Multiflow
>> Cydrome
>> I860
>
> Only 2 verbs per instruction group.
>
>> Trimedia
>> SHARC
>
> SHARC/HammerSHARC are not VLIW. One can argue that they are LIW.
> Another ADI architecture, TigerSHARC, is VLIW, but uncharacteristically
> narrow one.
>

If one respects the LIW/VLIW distinction, than LIW machines (2 or 3 wide
with groups of 1 to 3 RISC-like instructions able to be flagged to
execute in parallel) likely far outweigh "actual" VLIW machines in terms
of use (eg: 6 or 8 wide, often with a fixed-size / densely packed bundle
format).

So, likely, things Hexagon and Tensilica/Xtensa would more likely fall
under the LIW camp in this sense.

>> Itanic
>
> It lacks one of the key characteristics of VLIW - exposed pipeline.
>

If you mean the property that trying to use a result before it is ready
will cause the pipeline to be delayed until the result is ready (like
RISC's and most other non-VLIW ISAs), rather than give a stale value
(many other VLIWs).

Then, yes, my BJX2 ISA also has this property FWIW.

There is also an imposed restraint that bundled instructions will be
required to give the same results as-if the instructions had been
executed sequentially on a serial machine.

Though, this still does leave the matter of instructions which can't
really be implemented on a 1-wide implementation, like MOV.X (which
requires at least a 4R2W register file to pull off; or alternatively a
mechanism to break it apart into multiple logical instructions, *).

*: I have noted that by the time one pays for a larger register file
(and associated decode-path machinery), they almost may as well throw in
another ALU and have a lane there (the cost of the register ports being
seemingly more significant than the cost difference of adding/removing
an ALU and similar).

Well, and one also needs to pay the cost of a more expensive register
file to be able to support some bigger/more-complex instructions (and it
would be silly to have a 6R2W register file on a 1-wide machine just for
sake of 128-bit SIMD FMAC...).

Granted, one "could" argue for a machine with 2R1W but with native
128-bit register ports (rather than, say, doing 128-bit inputs/outputs
by using register ports in pairs).

Under the LIW / VLIW distinction, BJX2 would also fall on the LIW side.

Things like exposing instruction latency within the pipeline, or things
like branch-delay slots and similar, weren't really a bridge I was
willing to cross.

>> Elbrus
>> and maybe MILL
>>> l.

On Monday, August 28, 2023 at 1:30:33 PM UTC-5, BGB wrote:
> On 8/28/2023 10:25 AM, Michael S wrote:
> > On Sunday, August 27, 2023 at 2:46:40 AM UTC+3, MitchAlsup wrote:
> >> On Saturday, August 26, 2023 at 5:11:44 PM UTC-5, luke.l...@gmail.com wrote:
> >>> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
> >>>
> >>>> Conversely all static VLIW forms have failed.
> >>>
> >>> could you give examples of "static VLIW"? i am currently
> >>> designing an 8-bit ISA, which is so insanely short it may
> >>> have to go VLIW, and would prefer it greatly if i actually
> >>> knew what had and hadn't failed in this space :)
> >>>
> >> Multiflow
> >> Cydrome
> >> I860
> >
> > Only 2 verbs per instruction group.
> >
> >> Trimedia
> >> SHARC
> >
> > SHARC/HammerSHARC are not VLIW. One can argue that they are LIW.
> > Another ADI architecture, TigerSHARC, is VLIW, but uncharacteristically
> > narrow one.
> >
> If one respects the LIW/VLIW distinction, than LIW machines (2 or 3 wide
> with groups of 1 to 3 RISC-like instructions able to be flagged to
> execute in parallel) likely far outweigh "actual" VLIW machines in terms
> of use (eg: 6 or 8 wide, often with a fixed-size / densely packed bundle
> format).
>
>
> So, likely, things Hexagon and Tensilica/Xtensa would more likely fall
> under the LIW camp in this sense.
> >> Itanic
> >
> > It lacks one of the key characteristics of VLIW - exposed pipeline.
> >
> If you mean the property that trying to use a result before it is ready
> will cause the pipeline to be delayed until the result is ready (like
> RISC's and most other non-VLIW ISAs), rather than give a stale value
> (many other VLIWs).
>
>
> Then, yes, my BJX2 ISA also has this property FWIW.
<
The former (stall) or the later (stale) ??
>
> There is also an imposed restraint that bundled instructions will be
> required to give the same results as-if the instructions had been
> executed sequentially on a serial machine.
<
This tenet prevents the use of stale.
>
> Though, this still does leave the matter of instructions which can't
> really be implemented on a 1-wide implementation, like MOV.X (which
> requires at least a 4R2W register file to pull off; or alternatively a
> mechanism to break it apart into multiple logical instructions, *).
>
I disagree (in the small) I still consider my 66100 to be a 1-wide machine
even when using CARRY spread across several serial instructions. This
may appear as 4R2W but the µArchitecture has a Carry-Loop which
provides 1R1W without consuming RF ports (right then and there).
{{On the low end machines, CARRY itself supplies the 1R, after the
Carry-Shadow, forwarding supplies the 1R, and sooner or later there
will be an instruction without a result and Carry can steal that port on
this cycle. Higher end machines have many more options and this is
seldom an issue.}}
>
> *: I have noted that by the time one pays for a larger register file
> (and associated decode-path machinery), they almost may as well throw in
> another ALU and have a lane there (the cost of the register ports being
> seemingly more significant than the cost difference of adding/removing
> an ALU and similar).
<
The area footprint of an ALU is smaller that the area footprint delta of
adding 1 more read port to an already 3 read ported file. The ALU
footprint is way smaller than adding a second write port to a 1W RF.
So, the ALU is "almost free". In many of my machines, the forwarding
logic was bigger than the integer ALU. In my 6-wide and 8-wide designs
we simply threw an ALU on the front of every (but 1) function unit.
<
AGEN units can do integer additions and have integer shifters (we
typically call aligners).
FADD is so big you can hardly see an integer ALU pasted on the front.
FMAC is even bigger than FADD....
*CMP IS an integer ALU (both integer and FP with a few special checks)
.....
>
> Well, and one also needs to pay the cost of a more expensive register
> file to be able to support some bigger/more-complex instructions (and it
> would be silly to have a 6R2W register file on a 1-wide machine just for
> sake of 128-bit SIMD FMAC...).
<
It is beyond silly.....and when the ISA supports generous constants, a
RF with 6R ports should be supporting a 3-wide µArchitecture.
>
> Granted, one "could" argue for a machine with 2R1W but with native
> 128-bit register ports (rather than, say, doing 128-bit inputs/outputs
> by using register ports in pairs).
>
You are making assumptions that DECODE is setup ONLY to push decoded
instructions into execution and/or that it has no facility to repeatedly
perform a "cycle of work" until it is time to move forward. Under your
assumption, what you said is true enough, it is not when DECODE can
sequence an instruction into execution.
>
> Under the LIW / VLIW distinction, BJX2 would also fall on the LIW side.
>
>
> Things like exposing instruction latency within the pipeline, or things
> like branch-delay slots and similar, weren't really a bridge I was
> willing to cross.
<
It is not the exposing (code scheduling uses exposure of the pipeline details)
It is the Architecture not presenting a vonNeumann execution paradigm!
If the code sequence is wrong you get stale data rather than architectural
data.
<
> >> Elbrus
> >> and maybe MILL
> >>> l.

On 8/28/2023 2:18 PM, MitchAlsup wrote:
> On Monday, August 28, 2023 at 1:30:33 PM UTC-5, BGB wrote:
>> On 8/28/2023 10:25 AM, Michael S wrote:
>>> On Sunday, August 27, 2023 at 2:46:40 AM UTC+3, MitchAlsup wrote:
>>>> On Saturday, August 26, 2023 at 5:11:44 PM UTC-5, luke.l...@gmail.com wrote:
>>>>> On Wednesday, August 16, 2023 at 7:15:42 PM UTC+1, MitchAlsup wrote:
>>>>>
>>>>>> Conversely all static VLIW forms have failed.
>>>>>
>>>>> could you give examples of "static VLIW"? i am currently
>>>>> designing an 8-bit ISA, which is so insanely short it may
>>>>> have to go VLIW, and would prefer it greatly if i actually
>>>>> knew what had and hadn't failed in this space :)
>>>>>
>>>> Multiflow
>>>> Cydrome
>>>> I860
>>>
>>> Only 2 verbs per instruction group.
>>>
>>>> Trimedia
>>>> SHARC
>>>
>>> SHARC/HammerSHARC are not VLIW. One can argue that they are LIW.
>>> Another ADI architecture, TigerSHARC, is VLIW, but uncharacteristically
>>> narrow one.
>>>
>> If one respects the LIW/VLIW distinction, than LIW machines (2 or 3 wide
>> with groups of 1 to 3 RISC-like instructions able to be flagged to
>> execute in parallel) likely far outweigh "actual" VLIW machines in terms
>> of use (eg: 6 or 8 wide, often with a fixed-size / densely packed bundle
>> format).
>>
>>
>> So, likely, things Hexagon and Tensilica/Xtensa would more likely fall
>> under the LIW camp in this sense.
>>>> Itanic
>>>
>>> It lacks one of the key characteristics of VLIW - exposed pipeline.
>>>
>> If you mean the property that trying to use a result before it is ready
>> will cause the pipeline to be delayed until the result is ready (like
>> RISC's and most other non-VLIW ISAs), rather than give a stale value
>> (many other VLIWs).
>>
>>
>> Then, yes, my BJX2 ISA also has this property FWIW.
> <
> The former (stall) or the later (stale) ??

It will stall the "front end" of the pipeline until the former
instructions have completed.

So, dependencies between bundles will be resolved using pipeline stalls
much like sequential instructions in a more traditional architecture
(and scheduling for latency is mostly used to avoid wasting clock-cycles
via pipeline stalls).

>>
>> There is also an imposed restraint that bundled instructions will be
>> required to give the same results as-if the instructions had been
>> executed sequentially on a serial machine.
> <
> This tenet prevents the use of stale.

Yes.

Stale results will not be visible within any well-formed instruction
sequence.

Bundles which attempt to modify an register and then reference it as an
input within the same bundle could potentially see stale values but are
not allowed (except in cases where predication makes the instructions
mutually exclusive; effectively preventing any stale results from being
possible).

So:
ADD R4, 1, R5 | SUB R5, 1, R6
Is invalid.

But:
ADD?T R4, 1, R5 | SUB?F R5, 1, R6
Is allowed, as these instructions are mutually exclusive.

Technically, ill-formed bundles which violate the above rules may result
in stale data (in the verilog implementation). However, my emulator has
a lint feature to detect these cases and turn them into breakpoints, and
they are still considered as invalid as per the ISA spec.

Since my emulator is used quite extensively in my testing, code which
has such bundles (such as by poorly written ASM or compiler bugs) is
unlikely to go unnoticed.

For a wider VLIW, it would be "more compelling" to relax some of these
rules, but "there be dragons here..."

So, current plan remains to, if a wider implementation is needed, to
likely go over to an OoO strategy instead (likely leaving 3 as the
"canonical width" even if the underlying machine is wider).

>>
>> Though, this still does leave the matter of instructions which can't
>> really be implemented on a 1-wide implementation, like MOV.X (which
>> requires at least a 4R2W register file to pull off; or alternatively a
>> mechanism to break it apart into multiple logical instructions, *).
>>
> I disagree (in the small) I still consider my 66100 to be a 1-wide machine
> even when using CARRY spread across several serial instructions. This
> may appear as 4R2W but the µArchitecture has a Carry-Loop which
> provides 1R1W without consuming RF ports (right then and there).
> {{On the low end machines, CARRY itself supplies the 1R, after the
> Carry-Shadow, forwarding supplies the 1R, and sooner or later there
> will be an instruction without a result and Carry can steal that port on
> this cycle. Higher end machines have many more options and this is
> seldom an issue.}}

My pipeline is naive:
There is a 1:1 mapping between instructions/bundles and the pipeline;
Any instruction can be executed needs all the register ports to serve
the instruction in question;
There is not currently any mechanism to "decompose" any instructions;
....

It is possible that an "instruction splitter" could be added to the ID2
stage. The most likely option would be to require any such instructions
to be "scalar only", and then use the Lanes 2/3 signals to encode the steps.

Say:
Executes Lane 3 op first (if not NOP);
Executes Lane 2 op second (if not NOP);
Then lets Lane 1 op pass through.
With the Lane 2/3 ops being forwarded via Lane 1.

In this case, multi-stage ops would be handled similar to multi-lane ops
in the decoder (but with different control bits).

ID2 would keep the "front-end" stages stalled while this is happening.

>>
>> *: I have noted that by the time one pays for a larger register file
>> (and associated decode-path machinery), they almost may as well throw in
>> another ALU and have a lane there (the cost of the register ports being
>> seemingly more significant than the cost difference of adding/removing
>> an ALU and similar).
> <
> The area footprint of an ALU is smaller that the area footprint delta of
> adding 1 more read port to an already 3 read ported file. The ALU
> footprint is way smaller than adding a second write port to a 1W RF.
> So, the ALU is "almost free". In many of my machines, the forwarding
> logic was bigger than the integer ALU. In my 6-wide and 8-wide designs
> we simply threw an ALU on the front of every (but 1) function unit.
> <
> AGEN units can do integer additions and have integer shifters (we
> typically call aligners).
> FADD is so big you can hardly see an integer ALU pasted on the front.
> FMAC is even bigger than FADD....
> *CMP IS an integer ALU (both integer and FP with a few special checks)
> ....

My lanes are slightly asymmetric:
Lane 1, does everything;
Lane 2, does some stuff:
ALU, Shift, FPU (if Lane 1 is not FPU);
Lane 2 ALU and Shift can combine with Lane 1 for 128-bit ops;
Similar for FPU;
...
Lane 3, does ALU ops and maybe Shift.
Basically nothing else though.

Lane 3 justifies the 6R register file, and the extra ALU is sometimes
useful for stuff.

Much of the cost of the core is due to "features" (mostly in Lane 1
FUs), rather than due to it being 3 wide (since, as noted, Lane 3 lacks
most of the "fancy" FUs).

To what extent "fancy" features exist in Lane 2, it is mostly because
the required plumbing also needed to exist:
Lane 2 gets FPU mostly because I already needed Lane 2 plumbed into the
FPU for 128-bit SIMD ops (and it doesn't add much cost to allow normal
requests to also be issued from Lane 2).

The low-precision SIMD unit can also allow a potential feature of
co-issuing 2x Binary32 SIMD ops (since this isn't too far off from how
128-bit SIMD works already with this unit).

So, I am debating whether to officially allow things like:
PADD.F R23, R21, R25 | PADD.F R27, R29, R31

Since, technically, the SIMD unit can already do this, just it requires
effectively confirming that, yes, the dedicated SIMD unit "actually
exists" (otherwise, it is ambiguous; the main FPU can also do SIMD, just
it takes 10 clock-cycles to do each SIMD op; vs 3 cycles with the
dedicated unit).

However, it would be a little ambiguous, as this co-issuing would only
be possible for 2x Binary32 SIMD ops, and in certain matching
combinations (can't co-issue Binary16 or Binary64 ops; or mix/match).

Theoretically, could potentially allow mixing SIMD with Scalar-FPU ops
in this case, say:
PADD.H ... | FMUL ...
Since, with the dedicated SIMD unit enabled, these are technically two
different FUs.

On Tuesday, August 29, 2023 at 3:42:17 AM UTC-5, BGB wrote:
> On 8/28/2023 2:18 PM, MitchAlsup wrote:
> >> Then, yes, my BJX2 ISA also has this property FWIW.
> > <
> > The former (stall) or the later (stale) ??
> It will stall the "front end" of the pipeline until the former
> instructions have completed.
>
> So, dependencies between bundles will be resolved using pipeline stalls
> much like sequential instructions in a more traditional architecture
> (and scheduling for latency is mostly used to avoid wasting clock-cycles
> via pipeline stalls).
<
Under the nonNeumann paradigm:: Realistically, there are only 2 choices
a) stall before issue
b) stall after issue (in instruction queueing mechanism)
<
> >>
> >> There is also an imposed restraint that bundled instructions will be
> >> required to give the same results as-if the instructions had been
> >> executed sequentially on a serial machine.
> > <
> > This tenet prevents the use of stale.
> Yes.
>
> Stale results will not be visible within any well-formed instruction
> sequence.
>
> Bundles which attempt to modify an register and then reference it as an
> input within the same bundle could potentially see stale values but are
> not allowed (except in cases where predication makes the instructions
> mutually exclusive; effectively preventing any stale results from being
> possible).
<
There are a variety of ways around this, but basically the operand register
consumes a result register and you can mark the operand register so it
knows which result to consume within the instruction issue width.
<
In Mc 88120 we expanded the 5-bit register specifiers to 6-bits.
bit<5> == 0 -> reg[bits<4..0>]
bit<5> == 1 -> slot[bits<3..0>]
doing this saves register porting in normal code ! since once you get
great and big 80%+ of register operands arrive on the forwarding bus
and you don't, then, need to read a register file port.
<
Without this marking you basically n×(n-1) 5-bit comparators to determine
intra-width DECODE register forwarding. {{And in fact, this is what gives
you said markings for the next time(s).}}
>
> So:
> ADD R4, 1, R5 | SUB R5, 1, R6
> Is invalid.
<
But::
ADD R4,1,R5 | SUB S0,1,R6
is !!
>
> But:
> ADD?T R4, 1, R5 | SUB?F R5, 1, R6
> Is allowed, as these instructions are mutually exclusive.
>
>
> Technically, ill-formed bundles which violate the above rules may result
> in stale data (in the verilog implementation). However, my emulator has
> a lint feature to detect these cases and turn them into breakpoints, and
> they are still considered as invalid as per the ISA spec.
<
marking eliminates this--but marking either requires a deeper DECODE pipeline
or it requires storage in the Instruction Cache. A Trace or Packet Cache organ-
ization provides this space at low cost.
>
<snip>
> > I disagree (in the small) I still consider my 66100 to be a 1-wide machine
> > even when using CARRY spread across several serial instructions. This
> > may appear as 4R2W but the µArchitecture has a Carry-Loop which
> > provides 1R1W without consuming RF ports (right then and there).
> > {{On the low end machines, CARRY itself supplies the 1R, after the
> > Carry-Shadow, forwarding supplies the 1R, and sooner or later there
> > will be an instruction without a result and Carry can steal that port on
> > this cycle. Higher end machines have many more options and this is
> > seldom an issue.}}
> My pipeline is naive:
> There is a 1:1 mapping between instructions/bundles and the pipeline;
> Any instruction can be executed needs all the register ports to serve
> the instruction in question;
> There is not currently any mechanism to "decompose" any instructions;
Nor recompose.....
> ...
><snip>
> My lanes are slightly asymmetric:
> Lane 1, does everything;
> Lane 2, does some stuff:
> ALU, Shift, FPU (if Lane 1 is not FPU);
> Lane 2 ALU and Shift can combine with Lane 1 for 128-bit ops;
> Similar for FPU;
> ...
> Lane 3, does ALU ops and maybe Shift.
> Basically nothing else though.
<
This reminds me of the 2-wide superscalar Mc 88110 (and 860)
<
But I got rid of all association between an instruction in the IStream
and which FU it gets routed to. Mc 88120 had 6 FUs {3×AGEN, FADD,
FMUL, CND}. Where we went different, is that the ICache used pre-
routed instructions with annotated registers above so all instructions
in a "packet" could issue (so long as the window was not full.)
<
The inst in slot[j] is performed by FU in slot[j], and uses slot[j] result bus;
It gets its renamed result[j] from history[j] and writes PRF[history[j]] when
complete.
>

On 8/26/2023 12:33 PM, MitchAlsup wrote:

snipped discussion of very high memory bandwidth system proposal.

> My hope would be that it would not melt when operating at full throughput.

Of course, it is a custom one-off, and likely would be very expensive, but

https://www.tomshardware.com/news/intel-demoes-8-core-528-thread-puma-chip-with-1-tbs-silicon-photonics

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

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 8/24/2023 12:02 PM, MitchAlsup wrote:
>>> On Tuesday, August 22, 2023 at 6:04:34?PM UTC-5, Paul A. Clayton wrote:
>> OK, I will ask. If you were trying to create a marvelous vector
>> supercomputer CPU, how would it be different from MY66000?
>
> Mitch already answered, just one remark...
>
> Today's supercomputing is mainly about graphics cards, for those
> workloads where this is an advantage.

With one interesting exception: Fugaku. It's still #2 in the TOP500
list, and uses 512-bit wide SVE. I'd guess that without having to
generate code for some GPU, it should be a lot easier to access all
that performance.

Andrew.

On Wednesday, September 6, 2023 at 10:53:47 AM UTC+1, a...@littlepinkcloud.invalid wrote:

> With one interesting exception: Fugaku. It's still #2 in the TOP500
> list, and uses 512-bit wide SVE. I'd guess that without having to
> generate code for some GPU, it should be a lot easier to access all
> that performance.

cough all you'd now have to do is access efficiently the SVE instructions
Qty-6-to-7000 cough :)

@begin caveat(big generalisation)
GPUs when used for Scientific Compute are no more "efficient"
than a CPU which has corresponding memory and back-end ALU
capacity. it's only when you target *3D* workloads that you find
"whoops they have hard-wired texture opcodes and etc. etc."
and performance/watt shoots up 4x over Supercomputing CPUs
@end caveat

appreciate the insight / exception Andrew.

l.