On Sunday, July 18, 2021 at 11:44:39 AM UTC-6, Anton Ertl wrote:

> It seems to me that Oracle was quite patient with SPARC, which had
> been losing ground to Intel and AMD for a long time.

And, from the article cited, while it has reassured its customers that
they won't have to switch from SPARC until at least 2034, it looks as
if Oracle is going to do a Unisys - future SPARC mainframes of theirs
will just use x86 processors using advanced JIT emulation to allow
legacy workloads to persist.

John Savard

On Sunday, July 18, 2021 at 9:36:30 AM UTC-6, Stephen Fuld wrote:
> On 7/18/2021 7:53 AM, Quadibloc wrote:

> > Wouldn't saving all the registers to memory on each clock cycle
> > defeat the purpose of hiding memory latency?

> Perhaps you are misunderstanding how the Tera MTA worked.

That wasn't the problem.

The point I was making was that the use of the term "context switch"
was extremely confusing. A context switch is what happens on a
computer when there's an interrupt or a subroutine is called: the
registers all get saved to memory.

What happens not only on the Tera MTA, but on any Intel processor
with Hyper-Threading, is quite different; the processor moves from
one thread to another thread, switching to the alternate set of registers
allocated to that thread.

The old thread retains its context for the next time the processor
goes back to it.

So even if, technically, the switching between register sets in a
multithreaded processor could be considered a _form_ of
context switch, using that phrase to describe it will create an
erroneous picture in people's minds, causing confusion.

John Savard

On Sunday, July 18, 2021 at 3:58:26 PM UTC-5, Quadibloc wrote:
> On Sunday, July 18, 2021 at 10:49:32 AM UTC-6, MitchAlsup wrote:
> > On Sunday, July 18, 2021 at 9:53:37 AM UTC-5, Quadibloc wrote:
>
> > > Wouldn't saving all the registers to memory on each clock cycle
> > > defeat the purpose of hiding memory latency?
>
> > It has room for all threads in the register file, so no saving is necessary.
> Yes, which means that whatever it's doing every cycle isn't a
> "context switch" in the sense with which I am familiar.
<
It is an entirely different thread, with different privilege, using different
MMU pointers and tables, and running in its own isolated environment.
What more does a context switch need to fit your model ?
>
> John Savard

On Sunday, July 18, 2021 at 4:05:50 PM UTC-5, Quadibloc wrote:
> On Sunday, July 18, 2021 at 9:36:30 AM UTC-6, Stephen Fuld wrote:
> > On 7/18/2021 7:53 AM, Quadibloc wrote:
>
> > > Wouldn't saving all the registers to memory on each clock cycle
> > > defeat the purpose of hiding memory latency?
>
> > Perhaps you are misunderstanding how the Tera MTA worked.
> That wasn't the problem.
>
> The point I was making was that the use of the term "context switch"
> was extremely confusing. A context switch is what happens on a
> computer when there's an interrupt or a subroutine is called: the
> registers all get saved to memory.
<
I am going to go with "Errrrrrr nooooo"
<
A context is an application program, a memory area, protected from
itself (privilege) and others (memory isolation and translation) that
has open files, sockets, .... and there are multiple unique and independent
ones.
<
A context switch is a change of control from within one context to
within another context. This DOES NOT NECESSARILY require
{Interrupts, context save, scheduling, context restore} Those are
vestiments to single threaded mono-processors of the past and
wholly unnecessary going forward.
>

>
> John Savard

On 2021-07-18, Quadibloc wrote:
> On Sunday, July 18, 2021 at 9:36:30 AM UTC-6, Stephen Fuld wrote:
>> On 7/18/2021 7:53 AM, Quadibloc wrote:
>
>>> Wouldn't saving all the registers to memory on each clock cycle
>>> defeat the purpose of hiding memory latency?
>
>> Perhaps you are misunderstanding how the Tera MTA worked.
>
> That wasn't the problem.
>
> The point I was making was that the use of the term "context switch"
> was extremely confusing. A context switch is what happens on a
> computer when there's an interrupt or a subroutine is called: the
> registers all get saved to memory.

In the Tera MTA the act of saving/restoring registers is "hardware
accelerated" so that it can switch threads on every clock cycle. From
the user program execution context perspective it's the exact same thing
as interrupt + save-state-A + restore-state-B + return-from-interrupt,
except it's handled in hardware instead of in software, so no interrupts
are needed.

>
> What happens not only on the Tera MTA, but on any Intel processor
> with Hyper-Threading, is quite different; the processor moves from
> one thread to another thread, switching to the alternate set of registers
> allocated to that thread.
>

I may be wrong, but I was under the impression that Hyper-Threading /
SMT is slightly different: Two threads are executed /simultaneously/.
In other words: The two thread execution contexts (i.e. their register
files, program counters etc) run concurrently during the same clock
cycle, with the intention of maximizing EU usage in a wide issue
machine.

Switching threads in a typical x86 SMT CPU is still done in software
(via kernel interrupts), as on a non-SMT, single-threaded CPU.

> The old thread retains its context for the next time the processor
> goes back to it.
>
> So even if, technically, the switching between register sets in a
> multithreaded processor could be considered a _form_ of
> context switch, using that phrase to describe it will create an
> erroneous picture in people's minds, causing confusion.
>
> John Savard
>

On 7/18/2021 10:35 PM, Marcus wrote:
> On 2021-07-18, Quadibloc wrote:
>> On Sunday, July 18, 2021 at 9:36:30 AM UTC-6, Stephen Fuld wrote:
>>> On 7/18/2021 7:53 AM, Quadibloc wrote:
[...]
> I may be wrong, but I was under the impression that Hyper-Threading /
> SMT is slightly different: Two threads are executed /simultaneously/.
> In other words: The two thread execution contexts (i.e. their register
> files, program counters etc) run concurrently during the same clock
> cycle, with the intention of maximizing EU usage in a wide issue
> machine.
[...]

Argh! This brings back memories of the 64k aliasing issue in early
HyperThreading from good ol' Intel. It could cause massive false sharing
issues...

On 7/19/2021 12:35 AM, Marcus wrote:
> On 2021-07-18, Quadibloc wrote:
>> On Sunday, July 18, 2021 at 9:36:30 AM UTC-6, Stephen Fuld wrote:
>>> On 7/18/2021 7:53 AM, Quadibloc wrote:
>>
>>>> Wouldn't saving all the registers to memory on each clock cycle
>>>> defeat the purpose of hiding memory latency?
>>
>>> Perhaps you are misunderstanding how the Tera MTA worked.
>>
>> That wasn't the problem.
>>
>> The point I was making was that the use of the term "context switch"
>> was extremely confusing. A context switch is what happens on a
>> computer when there's an interrupt or a subroutine is called: the
>> registers all get saved to memory.
>
> In the Tera MTA the act of saving/restoring registers is "hardware
> accelerated" so that it can switch threads on every clock cycle. From
> the user program execution context perspective it's the exact same thing
> as interrupt + save-state-A + restore-state-B + return-from-interrupt,
> except it's handled in hardware instead of in software, so no interrupts
> are needed.
>

Seems to make sense.

Limiting factor though is likely that with rapid cycling (barrel
processing), presumably the CPU needs to have a register file big enough
to hold all of the active threads.

The access patterns would not be viable for use as a conventional cache
(the bandwidth required for streaming the register banks to/from memory
would be a few orders of magnitude beyond what I would consider
"plausible").

This would in effect put a limit on the number of threads for which it
is viable to use hardware threading (and/or limit each thread to a
relatively small number of registers).

Though, I can note that I did use a vaguely similar approach to this for
implementing FM synthesis in my case, where as opposed to having lots of
parallel logic for each MIDI channel, it just sort of cycles between all
of them (and completes a full rotation 64k times per second). Though,
there is only about 256 bits of state per channel in this case.

>>
>> What happens not only on the Tera MTA, but on any Intel processor
>> with Hyper-Threading, is quite different; the processor moves from
>> one thread to another thread, switching to the alternate set of registers
>> allocated to that thread.
>>
>
> I may be wrong, but I was under the impression that Hyper-Threading /
> SMT is slightly different: Two threads are executed /simultaneously/.
> In other words: The two thread execution contexts (i.e. their register
> files, program counters etc) run concurrently during the same clock
> cycle, with the intention of maximizing EU usage in a wide issue
> machine.
>
> Switching threads in a typical x86 SMT CPU is still done in software
> (via kernel interrupts), as on a non-SMT, single-threaded CPU.
>

Elsewhere, I went and looked it up, and noted that apparently, hardware
multithreading which involves rapidly cycling between a group of threads
is referred to as TMT (Temporal Multi-Threading), where SMT refers more
specifically to implementations which execute both threads in parallel
within the same clock cycle (more like Hyperthreading does AFAIK).

>> The old thread retains its context for the next time the processor
>> goes back to it.
>>
>> So even if, technically, the switching between register sets in a
>> multithreaded processor could be considered a _form_ of
>> context switch, using that phrase to describe it will create an
>> erroneous picture in people's minds, causing confusion.
>>
>> John Savard
>>
>

On 2021-07-19 08:23, BGB wrote:
> On 7/19/2021 12:35 AM, Marcus wrote:
>> On 2021-07-18, Quadibloc wrote:
>>> On Sunday, July 18, 2021 at 9:36:30 AM UTC-6, Stephen Fuld wrote:
>>>> On 7/18/2021 7:53 AM, Quadibloc wrote:
>>>
>>>>> Wouldn't saving all the registers to memory on each clock cycle
>>>>> defeat the purpose of hiding memory latency?
>>>
>>>> Perhaps you are misunderstanding how the Tera MTA worked.
>>>
>>> That wasn't the problem.
>>>
>>> The point I was making was that the use of the term "context switch"
>>> was extremely confusing. A context switch is what happens on a
>>> computer when there's an interrupt or a subroutine is called: the
>>> registers all get saved to memory.
>>
>> In the Tera MTA the act of saving/restoring registers is "hardware
>> accelerated" so that it can switch threads on every clock cycle. From
>> the user program execution context perspective it's the exact same thing
>> as interrupt + save-state-A + restore-state-B + return-from-interrupt,
>> except it's handled in hardware instead of in software, so no interrupts
>> are needed.
>>
>
> Seems to make sense.
>
>
> Limiting factor though is likely that with rapid cycling (barrel
> processing), presumably the CPU needs to have a register file big enough
> to hold all of the active threads.
>

Yes. You need one register file slice per HW thread, so for 128 threads
with 32 64-bit GPR:s (as in the Threadstorm), that's a whooping 32 KiB
of register state (only counting the GPR:s). That should even be
possible on an FPGA (especially if you aim slightly lower).

I think that one of the consequences of using that many HW threads is
that cache locality suffers, and the whole idea of this particular
design is to hide long latency memory accesses (due to cache misses)
anyway, so the cache is probably not as important - thus it makes sense
to trade some cache area for register file area instead.

The really cool part is that you can do random memory access and random
branches - "for free" - without having advanced branch predictors and
deep cache hierarchies - /and/ you can make your pipeline almost
arbitrarily long.

> The access patterns would not be viable for use as a conventional cache
> (the bandwidth required for streaming the register banks to/from memory
> would be a few orders of magnitude beyond what I would consider
> "plausible").
>

Precisely.

>
> This would in effect put a limit on the number of threads for which it
> is viable to use hardware threading (and/or limit each thread to a
> relatively small number of registers).
>
> Though, I can note that I did use a vaguely similar approach to this for
> implementing FM synthesis in my case, where as opposed to having lots of
> parallel logic for each MIDI channel, it just sort of cycles between all
> of them (and completes a full rotation 64k times per second). Though,
> there is only about 256 bits of state per channel in this case.
>
>
>>>
>>> What happens not only on the Tera MTA, but on any Intel processor
>>> with Hyper-Threading, is quite different; the processor moves from
>>> one thread to another thread, switching to the alternate set of
>>> registers
>>> allocated to that thread.
>>>
>>
>> I may be wrong, but I was under the impression that Hyper-Threading /
>> SMT is slightly different: Two threads are executed /simultaneously/.
>> In other words: The two thread execution contexts (i.e. their register
>> files, program counters etc) run concurrently during the same clock
>> cycle, with the intention of maximizing EU usage in a wide issue
>> machine.
>>
>> Switching threads in a typical x86 SMT CPU is still done in software
>> (via kernel interrupts), as on a non-SMT, single-threaded CPU.
>>
>
> Elsewhere, I went and looked it up, and noted that apparently, hardware
> multithreading which involves rapidly cycling between a group of threads
> is referred to as TMT (Temporal Multi-Threading), where SMT refers more
> specifically to implementations which execute both threads in parallel
> within the same clock cycle (more like Hyperthreading does AFAIK).
>
>
>>> The old thread retains its context for the next time the processor
>>> goes back to it.
>>>
>>> So even if, technically, the switching between register sets in a
>>> multithreaded processor could be considered a _form_ of
>>> context switch, using that phrase to describe it will create an
>>> erroneous picture in people's minds, causing confusion.
>>>
>>> John Savard
>>>
>>
>

On Sunday, July 18, 2021 at 3:13:41 PM UTC-6, MitchAlsup wrote:

> A context switch is a change of control from within one context to
> within another context. This DOES NOT NECESSARILY require
> {Interrupts, context save, scheduling, context restore} Those are
> vestiments to single threaded mono-processors of the past and
> wholly unnecessary going forward.

I can point to some *really old* computers that had one set of
registers for application programs, and a second set for the
operating system.

It is certainly true that switching to another set of registers
is a simpler way to let an interrupt routine get going faster;
but the term "context switch" at least makes me think of what
a single thread does to change to another context - the threads
in multi-threaded processors are so completely separate that
switching the context takes place outside the code.

John Savard

Quadibloc wrote:
> On Sunday, July 18, 2021 at 3:13:41 PM UTC-6, MitchAlsup wrote:
>
>> A context switch is a change of control from within one context to
>> within another context. This DOES NOT NECESSARILY require
>> {Interrupts, context save, scheduling, context restore} Those are
>> vestiments to single threaded mono-processors of the past and
>> wholly unnecessary going forward.
>
> I can point to some *really old* computers that had one set of
> registers for application programs, and a second set for the
> operating system.
>
> It is certainly true that switching to another set of registers
> is a simpler way to let an interrupt routine get going faster;
> but the term "context switch" at least makes me think of what
> a single thread does to change to another context - the threads
> in multi-threaded processors are so completely separate that
> switching the context takes place outside the code.

The first machines I have personally used with this feature was the
Norsk Data ND10 and ND100, they had 15 interrupt levels on top of the
user state (level 0), each with a full complement of registers.

This meant that they could take a HW interrupt from some kind of
periferal (like a process monitoring sensor) and switch to the
corresponding task in a single (or even zero?) cycle(s), do whatever was
required and then switch back.

This worked wonderfully for the initial target which was process
monitoring & control, they sold a bunch of these machines to CERN.

Terje

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

On 7/19/2021 1:22 AM, Terje Mathisen wrote:
> Quadibloc wrote:
>> On Sunday, July 18, 2021 at 3:13:41 PM UTC-6, MitchAlsup wrote:
>>
>>> A context switch is a change of control from within one context to
>>> within another context. This DOES NOT NECESSARILY require
>>> {Interrupts, context save, scheduling, context restore} Those are
>>> vestiments to single threaded mono-processors of the past and
>>> wholly unnecessary going forward.
>>
>> I can point to some *really old* computers that had one set of
>> registers for application programs, and a second set for the
>> operating system.
>>
>> It is certainly true that switching to another set of registers
>> is a simpler way to let an interrupt routine get going faster;
>> but the term "context switch" at least makes me think of what
>> a single thread does to change to another context - the threads
>> in multi-threaded processors are so completely separate that
>> switching the context takes place outside the code.
>
> The first machines I have personally used with this feature was the
> Norsk Data ND10 and ND100, they had 15 interrupt levels on top of the
> user state (level 0), each with a full complement of registers.
>
> This meant that they could take a HW interrupt from some kind of
> periferal (like a process monitoring sensor) and switch to the
> corresponding task in a single (or even zero?) cycle(s), do whatever was
> required and then switch back.
>
> This worked wonderfully for the initial target which was process
> monitoring & control, they sold a bunch of these machines to CERN.
>
> Terje
>
>

For a while they also ran the telephone system of PRC.

On 7/19/2021 12:17 AM, Quadibloc wrote:
> On Sunday, July 18, 2021 at 3:13:41 PM UTC-6, MitchAlsup wrote:
>
>> A context switch is a change of control from within one context to
>> within another context. This DOES NOT NECESSARILY require
>> {Interrupts, context save, scheduling, context restore} Those are
>> vestiments to single threaded mono-processors of the past and
>> wholly unnecessary going forward.
>
> I can point to some *really old* computers that had one set of
> registers for application programs, and a second set for the
> operating system.

Of course, the Univac 1100 had, and still has exactly that, another full
set of registers for the OS, but they were used only for fast interrupt
handling. Most of the OS ran in the user set (so most of the OS could
be interrupted for higher priority work).

And my original ARM Architecture Reference shows a duplicate set of
registers R8-14 for Fast Interrupt mode.

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

On 19 Jul 2021, Quadibloc wrote
(in article<b114b534-ea0a-4399-b601-26263e323a25n@googlegroups.com>):

> On Sunday, July 18, 2021 at 3:13:41 PM UTC-6, MitchAlsup wrote:
>
> > A context switch is a change of control from within one context to
> > within another context. This DOES NOT NECESSARILY require
> > {Interrupts, context save, scheduling, context restore} Those are
> > vestiments to single threaded mono-processors of the past and
> > wholly unnecessary going forward.
>
> I can point to some *really old* computers that had one set of
> registers for application programs, and a second set for the
> operating system.

I can point to a really old computer that had a separate set of
48 registers for each of the 4 apps it could run concurrently:

<http://www.findlayw.plus.com/KDF9/The%20Hardware%20of%20the%20KDF9.pdf>

--
Bill Findlay

On Saturday, July 17, 2021 at 3:39:16 PM UTC-4, MitchAlsup wrote:
[snip]
> The register file size is multiplied by the degree of SMT-ness.

Even for SMT, this is not necessarily entirely true. POWER7's SMT4
seems to reasonably count as 4-way SMT but requires no
additional register storage than SMT2. It uses the replication
of the register file for extra read ports to provide twice as
many threads with the limit that each pair of threads is limited
by the number of read ports in a cluster. (This might not quite
count as doubling SMT thread count since it is similar to
splitting the inside of the core into two half-internal-core parts,
i.e., the execution units are coupled with the register files. Aside:
This coupling *might* facilitate some power saving from having
fewer active forwarding paths.)

With additional registers for renaming not scaling with thread
count (one of the advantages of MT is hiding latencies), the
actual increase in register count will typically not scale with
the number of threads. (With a clustered register file, it might
also be practical to store some dead-if-speculation-is-correct
values in only one part, possibly doing moves during periods
of low port use. I am skeptical such would provide much
benefit.)

It might also be practical to reduce register file port count via
banking under MT. More ILP/latency tolerance implies more
choice in when to read from a centralized register file (probably
with some added buffering).

With fine-grained or SoEMT (not SMT), the 3D register file technique
(Marc Tremblay et al., "A Three Dimensional Register File For
Superscalar Processors", 1995 — 30% array area overhead
claimed for 8 'temporal banks' (Andy Glew's term) for 7 read,
3 write ported file) used by Itanium 2 Montecito (Eric S. Fetzer
et al., "The Multi-Threaded, Parity-Protected 128-Word Register
Files on a Dual-Core Itanium-Family Processor", 2005) largely
hiding storage area overhead given wiring constraints for highly
ported register files. With cycle-granular temporal banking
applied with traditional (spatial) banking, thread B could read
from spatial bank 0 while thread A read from bank 1, so the
area savings might be applied to an SMT design (though
requiring all the ports used by a thread to be in the same bank/
group of banks given a large number ports [to save significant
area] seems problematic).

These seem reasonable footnotes to apply to the statement
"register file size is multiplied by the degree of SMT-ness".

On Saturday, July 17, 2021 at 5:34:02 PM UTC-4, MitchAlsup wrote:
> On Saturday, July 17, 2021 at 4:06:50 PM UTC-5, Quadibloc wrote:
[snip]
>> https://www.nextplatform.com/2017/09/18/m8-last-hurrah-oracle-sparc/
[snip]
> Notice that they doubled the ICache and kept the DCache the same.
> Servers need larger I relative to D while application processors go the
> other direction.

Well, the L2 Icache (shared by four cores) remained the same size.
There is presumably some optimum L1 Icache size based on inter-thread
code sharing, temporal locality at a given code 'working set', L2 contention
avoidance, etc. While not as critical under multithreading (though M8 also
sought higher single-threaded performance), data cache access latency
tends, I think, to be more critical (BTBs can provide accurate fetch
prediction but load address prediction is harder).

> Secondly, 20nm still is cheaper per transistor than 14nm, 10nm, 7nm or 5nm.

Really (in 2021)? Obviously, it depends on volume (NRE is significant)
and chip size (dicing overhead/pad limits), less scaling transistors (I/O),
wiring constraints (SRAMs might be relatively cheaper, i.e., scaling better),
and probably other factors, but I thought I had read that Intel claimed
its 14nm was cheaper per transistor than its 20nm (not that Intel lacked
motivation to fudge figures).

Are power and transistors per die the only benefits then of 14nm?

On Tuesday, July 20, 2021 at 12:57:07 PM UTC-6, Paul A. Clayton wrote:
> On Saturday, July 17, 2021 at 3:39:16 PM UTC-4, MitchAlsup wrote:
> [snip]
> > The register file size is multiplied by the degree of SMT-ness.

> Even for SMT, this is not necessarily entirely true. POWER7's SMT4
> seems to reasonably count as 4-way SMT but requires no
> additional register storage than SMT2. It uses the replication
> of the register file for extra read ports to provide twice as
> many threads with the limit that each pair of threads is limited
> by the number of read ports in a cluster.

So if you use the 4-way SMT, you do without the extra read
ports...

Still, you do need four copies of the register file, so this is only
an exception because of a technicality: they found some use
for the extra copies when SMT was not in effect.

John Savard

On Tuesday, July 20, 2021 at 1:31:00 PM UTC-6, Paul A. Clayton wrote:
> On Saturday, July 17, 2021 at 5:34:02 PM UTC-4, MitchAlsup wrote:

> > Secondly, 20nm still is cheaper per transistor than 14nm, 10nm, 7nm or 5nm.
>
> Really (in 2021)?

Well, the year that matters is 2015, since that's when the SPARC M7 came out.

The SPARC M8 could still be on 20nm even if the economics of manufacture
have changed since then for a couple of reasons:

- Oracle seems to have lost interest in the SPARC architecture. It promises their
customers they'll have until 2034 to change, but it's likely that future SPARC
systems will be based on current x86 hardware with JIT SPARC emulation
software.

Therefore, they didn't want to invest the time and effort changing over their design
for the M7 to a 14nm process; instead, they may have just took the existing design,
added some baked in microcode for database operations and a little extra cache.

- Due to the current chip shortage that's made it hard to get one's hands on the
latest graphics cards and so on, Oracle found it easier to get some 20nm foundry
capacity than any 14nm foundry capacity.

John Savard

https://www.youtube.com/watch?v=MbtkL5_f6-4

On Tuesday, July 20, 2021 at 3:31:00 PM UTC-4, Paul A. Clayton wrote:
> On Saturday, July 17, 2021 at 5:34:02 PM UTC-4, MitchAlsup wrote:
[snip]
>> Secondly, 20nm still is cheaper per transistor than 14nm, 10nm, 7nm or 5nm.
>
> Really (in 2021)? Obviously, it depends on volume (NRE is significant)
> and chip size (dicing overhead/pad limits), less scaling transistors (I/O),
> wiring constraints (SRAMs might be relatively cheaper, i.e., scaling better),
> and probably other factors, but I thought I had read that Intel claimed
> its 14nm was cheaper per transistor than its 20nm (not that Intel lacked
> motivation to fudge figures).
>
> Are power and transistors per die the only benefits then of 14nm?

Doh. There are obviously also some direct performance benefits
(switching speed and less wire delay?). SRAM price per transistor
would also benefit from the lower cost of redundancy compared to
"random logic", so a higher defect rate of a smaller process would
increase "random logic" cost per transistor more than the cost for
SRAM.

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>On Tuesday, July 20, 2021 at 3:31:00 PM UTC-4, Paul A. Clayton wrote:
>> On Saturday, July 17, 2021 at 5:34:02 PM UTC-4, MitchAlsup wrote:
>[snip]
>>> Secondly, 20nm still is cheaper per transistor than 14nm, 10nm, 7nm or 5nm.
>>
>> Really (in 2021)? Obviously, it depends on volume (NRE is significant)
>> and chip size (dicing overhead/pad limits), less scaling transistors (I/O),
>> wiring constraints (SRAMs might be relatively cheaper, i.e., scaling better),
>> and probably other factors, but I thought I had read that Intel claimed
>> its 14nm was cheaper per transistor than its 20nm (not that Intel lacked
>> motivation to fudge figures).
>>
>> Are power and transistors per die the only benefits then of 14nm?

If you look at Intel, they had their difficulties with the 14nm
processes, but they have produced their mainstream CPUs on 14nm since
~2016 (Skylake was still scarce in 2015, so I guess they did not
produce that many at that time); they produced (server) CPUs with more
transistors in 22nm, so the reason for mainstream 14nm was not
transistors per die.

Both the 4770 (22nm, 65W TDP) and 6700 (14nm, 65W TDP) have 3.4GHz
base clock, so they are probably comparable in power consumption for a
given clock rate (although admittedly the Skylake has more IPC and
more transistors, so it's not an apples-to-apples comparison; Haswell
vs. Broadwell would be better, but Broadwell seemed to suffer from
Intel's 14nm woes, and the 5775C (14nm, 65W TDP) has 3.3GHz base
clock, lower than either). So it's not power, either, at least at
first.

And looking at the maximum clock rates (4790K: 4400MHZ, 6700K:
4200MHz), it was not the clock rate, either.

So I guess it's the cost per transistor. If 14nm was not at least
competetive in cost, Intel would have produced year after year of
Haswell respins (and maybe a Skylake backport to 22nm), like they did
with Skylake when 10nm made even more problems than 14nm (and like
Rocket Lake is a 14nm backport of Ice Lake).

>Doh. There are obviously also some direct performance benefits
>(switching speed and less wire delay?).

An avid reader of this newsgroup knows that switching speed has become
more and more irrelevant since 90nm or so (wire delay dominates), and
that wire delay does not improve; what you win in shorter wires, you
lose in slower signals. What newer processes do provide is more
layers. Makes me wonder how well older processes with more layers
would work.

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

On Wednesday, July 21, 2021 at 6:06:57 PM UTC+3, Anton Ertl wrote:
> "Paul A. Clayton" <paaron...@gmail.com> writes:
> >On Tuesday, July 20, 2021 at 3:31:00 PM UTC-4, Paul A. Clayton wrote:
> >> On Saturday, July 17, 2021 at 5:34:02 PM UTC-4, MitchAlsup wrote:
> >[snip]
> >>> Secondly, 20nm still is cheaper per transistor than 14nm, 10nm, 7nm or 5nm.
> >>
> >> Really (in 2021)? Obviously, it depends on volume (NRE is significant)
> >> and chip size (dicing overhead/pad limits), less scaling transistors (I/O),
> >> wiring constraints (SRAMs might be relatively cheaper, i.e., scaling better),
> >> and probably other factors, but I thought I had read that Intel claimed
> >> its 14nm was cheaper per transistor than its 20nm (not that Intel lacked
> >> motivation to fudge figures).
> >>
> >> Are power and transistors per die the only benefits then of 14nm?
> If you look at Intel, they had their difficulties with the 14nm
> processes, but they have produced their mainstream CPUs on 14nm since
> ~2016 (Skylake was still scarce in 2015, so I guess they did not
> produce that many at that time); they produced (server) CPUs with more
> transistors in 22nm, so the reason for mainstream 14nm was not
> transistors per die.
>
> Both the 4770 (22nm, 65W TDP) and 6700 (14nm, 65W TDP) have 3.4GHz
> base clock, so they are probably comparable in power consumption for a
> given clock rate (although admittedly the Skylake has more IPC and
> more transistors, so it's not an apples-to-apples comparison; Haswell
> vs. Broadwell would be better, but Broadwell seemed to suffer from
> Intel's 14nm woes, and the 5775C (14nm, 65W TDP) has 3.3GHz base
> clock, lower than either). So it's not power, either, at least at
> first.
>

D-1541 (Broadwell) vs E5-1428L v3 (Haswell)
Broadwell runs both faster and cooler.
It's not exactly apple2apple because E5 is higher end product with 3 memory channels vs 2 and 20MB LLC vs 12 MB,
but still, the difference in Watt per GHz is rather bigger than can be attributed to this factors.

> And looking at the maximum clock rates (4790K: 4400MHZ, 6700K:
> 4200MHz), it was not the clock rate, either.
>
> So I guess it's the cost per transistor. If 14nm was not at least
> competetive in cost, Intel would have produced year after year of
> Haswell respins (and maybe a Skylake backport to 22nm), like they did
> with Skylake when 10nm made even more problems than 14nm (and like
> Rocket Lake is a 14nm backport of Ice Lake).
> >Doh. There are obviously also some direct performance benefits
> >(switching speed and less wire delay?).
> An avid reader of this newsgroup knows that switching speed has become
> more and more irrelevant since 90nm or so (wire delay dominates), and
> that wire delay does not improve; what you win in shorter wires, you
> lose in slower signals. What newer processes do provide is more
> layers. Makes me wonder how well older processes with more layers
> would work.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>On Wednesday, July 21, 2021 at 6:06:57 PM UTC+3, Anton Ertl wrote:
>> "Paul A. Clayton" <paaron...@gmail.com> writes:
>> >On Tuesday, July 20, 2021 at 3:31:00 PM UTC-4, Paul A. Clayton wrote:
>> >> On Saturday, July 17, 2021 at 5:34:02 PM UTC-4, MitchAlsup wrote:
>> >[snip]
>> >>> Secondly, 20nm still is cheaper per transistor than 14nm, 10nm, 7nm or 5nm.
>> >>
>> >> Really (in 2021)? Obviously, it depends on volume (NRE is significant)
>> >> and chip size (dicing overhead/pad limits), less scaling transistors (I/O),
>> >> wiring constraints (SRAMs might be relatively cheaper, i.e., scaling better),
>> >> and probably other factors, but I thought I had read that Intel claimed
>> >> its 14nm was cheaper per transistor than its 20nm (not that Intel lacked
>> >> motivation to fudge figures).
>> >>
>> >> Are power and transistors per die the only benefits then of 14nm?
>> If you look at Intel, they had their difficulties with the 14nm
>> processes, but they have produced their mainstream CPUs on 14nm since
>> ~2016 (Skylake was still scarce in 2015, so I guess they did not
>> produce that many at that time); they produced (server) CPUs with more
>> transistors in 22nm, so the reason for mainstream 14nm was not
>> transistors per die.
>>
>> Both the 4770 (22nm, 65W TDP) and 6700 (14nm, 65W TDP) have 3.4GHz
>> base clock, so they are probably comparable in power consumption for a
>> given clock rate (although admittedly the Skylake has more IPC and
>> more transistors, so it's not an apples-to-apples comparison; Haswell
>> vs. Broadwell would be better, but Broadwell seemed to suffer from
>> Intel's 14nm woes, and the 5775C (14nm, 65W TDP) has 3.3GHz base
>> clock, lower than either). So it's not power, either, at least at
>> first.
>>
>
>D-1541 (Broadwell) vs E5-1428L v3 (Haswell)
>Broadwell runs both faster and cooler.
>It's not exactly apple2apple because E5 is higher end product with 3 memory channels vs 2 and 20MB LLC vs 12 MB,
>but still, the difference in Watt per GHz is rather bigger than can be attributed to this factors.

But then, when I look at the E5-2609 v4 with 20MB cache and 8 cores, I
see that it has a higher TDP and a lower clock rate than the E5-1428L
v3. And when I look at the E5-2608L v4 (also with 20MB), it has a
slightly lower TDP (50W vs. 60W), but roughly proportionally less
clock rate (1.6GHz base, 1.7GHz Turbo). And there's the E5-2630L v3
with 55W TDP, 1.8GHz base and 2.9GHz Turbo, while the E5-2428L v3 has
the same TDP and only 1.8GHz base without turbo.

I guess if we want to learn something about Intel processes, we need
to look at the top-end CPUs for a given TDP. Looking at CPUs like the
E5-1428L v3 and E5-2428L v3 is misleading. And even that should be
taken with a grain of salt, because for some TDPs, Intel may not offer
the maximum that's technically possible.

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

On Wednesday, July 21, 2021 at 2:27:02 AM UTC-4, Quadibloc wrote:
> On Tuesday, July 20, 2021 at 12:57:07 PM UTC-6, Paul A. Clayton wrote:
[snip]
>> Even for SMT, this is not necessarily entirely true. POWER7's SMT4
>> seems to reasonably count as 4-way SMT but requires no
>> additional register storage than SMT2. It uses the replication
>> of the register file for extra read ports to provide twice as
>> many threads with the limit that each pair of threads is limited
>> by the number of read ports in a cluster.
> So if you use the 4-way SMT, you do without the extra read
> ports...

(Extra read ports *per thread*. In theory, since the demand on
write ports would be split in SMT4 mode between clusters,
available port count might be increased. If half of the write
ports could be made into read/write ports at reasonable
cost, a pair of 6 read, 4 write, and 2 read/write register arrays
might support four 2-read, 1-write instructions without
forwarding per cluster. With forwarding and 1-read operations
being fairly common, even high execution width could be
supported.)

(Another interesting technique was using three storage arrays
composed of two banks and an array with the XOR of the
entries from the other banks. This allows the alternate bank
and XOR copy to be read when there would otherwise be a
bank conflict. I would have to search for the paper.)
> Still, you do need four copies of the register file, so this is only
> an exception because of a technicality: they found some use
> for the extra copies when SMT was not in effect.

Yes, it is a footnote, but (I think) a significant one. Maybe not
quite as significant as "accessing a storage array N times per
cycle involves providing N access ports* (*banking can be used,
especially with large storage capacity that naturally uses
multiple arrays [with the issue of conflicts], replication can be used
to multiply read ports, phased access can be used for longer
clock periods, etc.)"

I want to write a longer post about some issues with MTA,
mentioning memory interface issues (width given minimum
burst length, e.g.,), niche market vs. commodity effects,
for HPC ability to use lower thread count SMT/FGMT sharing
one or more compute threads with one or more "latency"
threads, and caching (I think first MTA only had instruction
caching, which makes sense for extremely non-cache friendly
code but introduces a bandwidth as well as latency issue; 64-bit
cache blocks could be used at the cost of relatively high tag
overhead). I am something of an MT fanboi, but my
recent productivity has been very low.

On 7/22/2021 8:49 AM, Paul A. Clayton wrote:
> On Wednesday, July 21, 2021 at 2:27:02 AM UTC-4, Quadibloc wrote:
>> On Tuesday, July 20, 2021 at 12:57:07 PM UTC-6, Paul A. Clayton wrote:
> [snip]
>>> Even for SMT, this is not necessarily entirely true. POWER7's SMT4
>>> seems to reasonably count as 4-way SMT but requires no
>>> additional register storage than SMT2. It uses the replication
>>> of the register file for extra read ports to provide twice as
>>> many threads with the limit that each pair of threads is limited
>>> by the number of read ports in a cluster.
>> So if you use the 4-way SMT, you do without the extra read
>> ports...
>
> (Extra read ports *per thread*. In theory, since the demand on
> write ports would be split in SMT4 mode between clusters,
> available port count might be increased. If half of the write
> ports could be made into read/write ports at reasonable
> cost, a pair of 6 read, 4 write, and 2 read/write register arrays
> might support four 2-read, 1-write instructions without
> forwarding per cluster. With forwarding and 1-read operations
> being fairly common, even high execution width could be
> supported.)
>
> (Another interesting technique was using three storage arrays
> composed of two banks and an array with the XOR of the
> entries from the other banks. This allows the alternate bank
> and XOR copy to be read when there would otherwise be a
> bank conflict. I would have to search for the paper.)

RAIR (Redundant Array of Independent Registers) :-)

I don't understand. While that could increase read throughput, all
writes would have to be to all three banks. If you are going to require
that, why do the XOR as opposed to just having three banks with
identical values? I must be missing something.

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

On Thursday, July 22, 2021 at 12:17:42 PM UTC-4, Stephen Fuld wrote:
> On 7/22/2021 8:49 AM, Paul A. Clayton wrote:
[snip]
>> (Another interesting technique was using three storage arrays
>> composed of two banks and an array with the XOR of the
>> entries from the other banks. This allows the alternate bank
>> and XOR copy to be read when there would otherwise be a
>> bank conflict. I would have to search for the paper.)
> RAIR (Redundant Array of Independent Registers) :-)
>
> I don't understand. While that could increase read throughput, all
> writes would have to be to all three banks. If you are going to require
> that, why do the XOR as opposed to just having three banks with
> identical values? I must be missing something.

I think part of the idea (I do not remember) was that writes can be
delayed (with forwarding/caching) and bank conflicts tend to
average out over time. A single write has to go to two of the three
arrays. For reads (with storage arrays A, B, and X), two reads that
would access A twice (or B twice) can instead read from A (or B)
and B (or A) and X.

The duplication method of adding read ports, results in N/2 read ports
and M write ports in two arrays of R entries. The XOR method results in
N/2 read ports and M/2 write ports in three arrays of R/2 entries.
(If the XOR array does not have twice as many write ports, it would have
to be banked, I guess.)

I suspect with high access count, write buffering, and dynamic scheduling
(with read buffering — operand capture and read scheduling separate from
operation scheduling) ordinary banking would work well enough. I vaguely
recall that the paper was not satisfying, but I do not remember why.