Is Vax addressing sane today?

I am not talking indirect addressing, that is stupid.

It has been determined from trusted sources that add from memory and add to memory as used in x86 are sane, and not much of a problem.

But Vax allows all three arguments to be in memory with different pointers.

Is this sane, just a natural progression if you allow memory operands?

Packing three offsets in an instruction that can be decoded reasonably is a whole other problem…

Heads and tails encoding could actually do this reasonably, and the code density would be actually be better than most competitors. Heads and tails
is not that easy, but it’s not x86 difficult.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brett <[email protected]> writes:

Is Vax addressing sane today?

By what definition of sanity? The question doesn't make sense.

I am not talking indirect addressing, that is stupid.

That seems rather judgmental. Although you may wish to further
define 'indirect addressing' to make clear exactly what you're
referring to (PDP-8 style, with auto-increment? B3500 style
where there is potentially infinite indirection? x86 where
indirection through a register is common?)

They may not make sense in the context of a modern RISC processor,
but that doesn't make them "stupid".

It has been determined from trusted sources that add from memory and add to >memory as used in x86 are sane, and not much of a problem.

"Sanity" isn't an attribute associated with hardware architecture.

But Vax allows all three arguments to be in memory with different pointers.

That's not an addressing issue, it is simply a natural form of
three-operand instruction when the processor supports memory to
memory instructions.

Now, you may reframe your question as to the desirability
of memory-to-memory instructions vis a vis performance and or
optimal code, and there you might find various opinions.

I think the folks on this group spend an inordinate amount of
time discussing minutia such has how many address/offset bits
can be encoded in an instruction, or code density, which in the
real world with modern high-performance processors aren't
particularly significant or interesting to the typical
programmer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vbd6b9$g147$[email protected]>, [email protected] (Brett) wrote:

It has been determined from trusted sources that add from memory
and add to memory as used in x86 are sane, and not much of a problem.

But Vax allows all three arguments to be in memory with different
pointers.

Is this sane, just a natural progression if you allow memory
operands?

Memory-to-memory instructions, in general, are hard to get to run fast
with today's processors and memory, simply because memory access times
are long enough for many register-to-register instructions to execute. A
lot of that time can be hidden with good caches and prefetchers, but if
your memory access patterns are complicated, those speedups can fail to
work.

One reason for memory-to-memory instructions was to avoid the need to
dedicate registers to operands, but that's not much of a problem these
days, since we have space in the CPU for lots of registers and rename
systems for them.

VAX was designed when heavy use of microcoding seemed like a good idea to
make a CPU at an economical price, and memory wasn't much slower than registers. It was a backward-looking design in some ways, being a much
better computer for the 1970s, rather than looking ahead to new concepts.
VMS was the last large operating system written in assembly language (and Bliss, which is somewhat higher-level, bit not much).

DEC spent a lot of time and money trying to keep VAX competitive and took
too long to accept that was impractical. That was one of the seeds of
their downfall.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 5 Sep 2024 21:03:37 +0000, Brett wrote:

Is Vax addressing sane today?

I am not talking indirect addressing, that is stupid.

It has been determined from trusted sources that add from memory and add
to memory as used in x86 are sane, and not much of a problem.

But Vax allows all three arguments to be in memory with different
pointers.

With modern compiler technology 88% of instructions need only 1
constant--thus VAX provides too many, along with providing address
modes that require sequential decoding.

Most ISAs do not provide "enough" constants, VAX provides too many.
Where "enough" covers::

SLA R9,#1,R17 // this is 1 instruction
DIV R9,#24,R17 // ibid
FDIV R8,#3.14159265358928,R17

Is this sane, just a natural progression if you allow memory operands?

Having watching this in real time:: in 1970 we needed more/better
constants, then PDP-11 came around and we liked it, then at the end
of the decade VAX cam along and we loved it, only later recognizing
that it had fallen for the second system syndrome--becoming overly
complicated without benefit--the address space was definitely needed
the address modes no so much.

Packing three offsets in an instruction that can be decoded reasonably
is a whole other problem…

Realistically, modern compilers have advanced to the point where
anything more than 1` constant per instruction is overkill--
harder to build and delivering no more performance.

Heads and tails encoding could actually do this reasonably, and the code density would be actually be better than most competitors. Heads and
tails is not that easy, but it’s not x86 difficult.

Another encoding scheme is segmenting the OpCode into 2 components
1) goes to the function unit to convey the kind of calculation
to be performed,
2) goes to the forwarding logic to convey how to route bits into
calculation.

Some might consider the concatenation of both to the be OpCode
but that obscures what to do with when to do it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 5 Sep 2024 22:55 +0100 (BST), John Dallman wrote:

VMS was the last large operating system written in assembly language
(and Bliss, which is somewhat higher-level, bit not much).

Bliss could, I think, have been just as portable as C. But it mainly found favour inside DEC.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 05 Sep 2024 21:15:20 GMT, Scott Lurndal wrote:

"Sanity" isn't an attribute associated with hardware architecture.

Says someone posting to a group full of hardware experts ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brett <[email protected]> writes:

But Vax allows all three arguments to be in memory with different pointers.

Is this sane, just a natural progression if you allow memory operands?

In combination with supporting unaligned accesses (but excluding
indirect addressing), it means that an instruction can access 6 pages,
and so the TLB (and/or TLB loader) has to be designed to support that. Likewise, the OS has to be designed to load all 6 pages into physical
RAM without evicting one of these pages again. So this kind of
architecture increases the design complexity. And I don't see a
benefit from this design.

Heads and tails encoding could actually do this reasonably, and the code >density would be actually be better than most competitors.

Would it? Please present empirical data. Certainly people claim that instruction sets with one-memory-address load-and-op and
read-modify-write instructions have better code density, but when you
look at the data, there are load-store instruction sets with better
code density (and by quite a lot). From <[email protected]>:

bash grep gzip
595204 107636 46744 armhf 16 regs load/store 32-bit
599832 101102 46898 riscv64 32 regs load/store 64-bit
796501 144926 57729 amd64 16 regs ld-op ld-op-st 64-bit
829776 134784 56868 arm64 32 regs load/store 64-bit
853892 152068 61124 i386 8 regs ld-op ld-op-st 32-bit
891128 158544 68500 armel 16 regs load/store 32-bit
892688 168816 64664 s390x 16 regs ld-op ld-op-st 64-bit
1020720 170736 71088 mips64el 32 regs load/store 64-bit
1168104 194900 83332 ppc64el 32 regs load/store 64-bit

What is "heads and tails encoding"?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 06 Sep 2024 06:05:35 GMT, Anton Ertl wrote:

... they failed to stick to VAX for the few more years until
they would have developed an OoO implementation, which would have
leveled the playing field again (see Pentium Pro).

It takes a whole lot of extra transistors (and consequent die area) to
keep a CISC architecture comparable in performance to RISC. Back about
when Intel finally caught up with PowerPC, I remember their chip packages
were huge -- about the size of a VHS videocassette.

Intel were probably spending 10× what Apple-IBM-Motorola were putting into each generation of chip development. But then, the x86 world had 10× the revenue coming in, so Intel could afford it. That’s how they regained the lead over RISC.

Nowadays, I don’t think the revenue advantage is quite what it once was. That, and the even greater increases in chip complexity (and hence
development cost), has tilted the playing field more in favour of RISC architectures, notably ARM and RISC-V.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (John Dallman) writes:

Memory-to-memory instructions, in general, are hard to get to run fast
with today's processors and memory, simply because memory access times
are long enough for many register-to-register instructions to execute.

Given modern OoO technology, even VAX can fly. It does not matter
whether, say,

*a++ = *b++ + *c++;

is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

In recent years a number of implementations have 0-cycle store-to-load forwarding, so the misconception that a memory operand is as cheap as
a register operand if only the instruction set has memory operands of
operate instructions is a little bit closer to reality. It is still a misconception, because such an implementation can read and write
several times as many registers per cycle as memory operands.

A
lot of that time can be hidden with good caches and prefetchers, but if
your memory access patterns are complicated, those speedups can fail to
work.

Whether operate instructions in an instruction set have 0, 1, or 3
memory operands makes little difference in that case.

One reason for memory-to-memory instructions was to avoid the need to >dedicate registers to operands, but that's not much of a problem these
days, since we have space in the CPU for lots of registers and rename
systems for them.

That may have been a consideration in the NOVA or the 6800, but in
case of the VAX with its 16 registers, that corresponds to a load/store-architecture with 18 registers, so for the VAX this is just
a minor issue.

Some time ago I thought a bit about which kind of architecture to
design with the transistor budget of the 6502, but with the RISC
lessons under the belt. One problem with a big RISC-like register set
is the instruction bandwidth. You really want to stick to 8-bit
instructions if you only have an 8-bit data bus. With a register
architecture that means 2-bits for register operands, and that means
you would need a lot of loads and stores in a load/store architecture.
So the narrow instruction word almost forces you to use implicit
register operands or at small special-purpose register sets (e.g., 2 accumulators and 4 index registers, as in the 6809) rather than
general-purpose registers.

However, the VAX 11/780 does not have these restrictions. It has a
wider memory bus and it has a cache.

DEC spent a lot of time and money trying to keep VAX competitive and took
too long to accept that was impractical. That was one of the seeds of
their downfall.

Either that, or they failed to stick to VAX for the few more years
until they would have developed an OoO implementation, which would
have leveled the playing field again (see Pentium Pro). The Alpha
came out in 1992, the Pentium Pro in 1995, so if DEC has stuck to the
VAX and managed a timely OoO implementation, they would have needed to
survive just 3 years. And it seems that they lost a lot of customers
in the transition from VAX to Alpha.

Of course, the question is if the customers would have stayed with DEC
if they had continued with the VAX. The vibe at the time was that
CISCs are doomed. OTOH, Intel stuck with IA-32 and won with the P6,
and IBM stuck with the S390. But VAX customers are not S390
customers, and maybe they would have defected to Intel even if the VAX
had been there.

From what I read, the VAX 9000 was a big nail in the DEC coffin. In
hindsight they should have canceled the project early, but that does
not mean that they could not have continued with VAX (they could even
have competed with the IBM mainframes, which took quite long to gain superscalar and OoO implementations).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 05 Sep 2024 21:15:20 GMT, Scott Lurndal wrote:

"Sanity" isn't an attribute associated with hardware architecture.

Says someone posting to a group full of hardware experts ...

That someone has been doing architecture since 1983; from
mainframes to high-end SoCs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl <[email protected]> wrote:

Brett <[email protected]> writes:

But Vax allows all three arguments to be in memory with different pointers. >>
Is this sane, just a natural progression if you allow memory operands?

In combination with supporting unaligned accesses (but excluding
indirect addressing), it means that an instruction can access 6 pages,
and so the TLB (and/or TLB loader) has to be designed to support that. Likewise, the OS has to be designed to load all 6 pages into physical
RAM without evicting one of these pages again. So this kind of
architecture increases the design complexity. And I don't see a
benefit from this design.

The memory system is pipelined, once you load the first of the three
values, you do not care if that cache line is evicted while you load the second.

Caches are 16 way today, one does not worry about cache line evictions, it
just works.

Heads and tails encoding could actually do this reasonably, and the code
density would be actually be better than most competitors.

Would it? Please present empirical data. Certainly people claim that instruction sets with one-memory-address load-and-op and
read-modify-write instructions have better code density, but when you
look at the data, there are load-store instruction sets with better
code density (and by quite a lot). From <[email protected]>:

bash grep gzip
595204 107636 46744 armhf 16 regs load/store 32-bit
599832 101102 46898 riscv64 32 regs load/store 64-bit
796501 144926 57729 amd64 16 regs ld-op ld-op-st 64-bit
829776 134784 56868 arm64 32 regs load/store 64-bit
853892 152068 61124 i386 8 regs ld-op ld-op-st 32-bit
891128 158544 68500 armel 16 regs load/store 32-bit
892688 168816 64664 s390x 16 regs ld-op ld-op-st 64-bit
1020720 170736 71088 mips64el 32 regs load/store 64-bit
1168104 194900 83332 ppc64el 32 regs load/store 64-bit

What is "heads and tails encoding"?

128 bit or larger packets with the fixed size opcodes on the front, and the variable sized data and offsets packing in from the end. You get variable length instruction density with easier faster wide decoding. And also using memory operands give you another density bonus on top.

The down side is that it makes your one and two wide implementations
bigger.

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 <[email protected]> wrote:

On Thu, 5 Sep 2024 21:03:37 +0000, Brett wrote:

Is Vax addressing sane today?

I am not talking indirect addressing, that is stupid.

It has been determined from trusted sources that add from memory and add
to memory as used in x86 are sane, and not much of a problem.

But Vax allows all three arguments to be in memory with different
pointers.

With modern compiler technology 88% of instructions need only 1 constant--thus VAX provides too many, along with providing address
modes that require sequential decoding.

Most ISAs do not provide "enough" constants, VAX provides too many.
Where "enough" covers::

SLA R9,#1,R17 // this is 1 instruction
DIV R9,#24,R17 // ibid
FDIV R8,#3.14159265358928,R17

In C++ game code there are places where you are loading from two structures
and storing into a third structure. Three offsets are needed and used.

Most commonly you need two offsets as you are building a new structure from
the old one. The example being building the polygon display lists
structures from your source structures which contain X,Y,Z and R,G,B,A and weights, and other info.

The benchmarks you are using are out of date, using arrays instead of structures. Arrays are rare in game code, it’s all structures.

Not Fortran arrays, C++ structure spaghetti.

Is this sane, just a natural progression if you allow memory operands?

Having watching this in real time:: in 1970 we needed more/better
constants, then PDP-11 came around and we liked it, then at the end
of the decade VAX cam along and we loved it, only later recognizing
that it had fallen for the second system syndrome--becoming overly complicated without benefit--the address space was definitely needed
the address modes no so much.

Packing three offsets in an instruction that can be decoded reasonably
is a whole other problem…

Realistically, modern compilers have advanced to the point where
anything more than 1` constant per instruction is overkill--
harder to build and delivering no more performance.

Heads and tails encoding could actually do this reasonably, and the code
density would be actually be better than most competitors. Heads and
tails is not that easy, but it’s not x86 difficult.

Another encoding scheme is segmenting the OpCode into 2 components
1) goes to the function unit to convey the kind of calculation
to be performed,
2) goes to the forwarding logic to convey how to route bits into
calculation.

Some might consider the concatenation of both to the be OpCode
but that obscures what to do with when to do it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 6 Sep 2024 6:05:35 +0000, Anton Ertl wrote:

[email protected] (John Dallman) writes:

Memory-to-memory instructions, in general, are hard to get to run fast
with today's processors and memory, simply because memory access times
are long enough for many register-to-register instructions to execute.

Given modern OoO technology, even VAX can fly. It does not matter
whether, say,

*a++ = *b++ + *c++;

is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

In recent years a number of implementations have 0-cycle store-to-load forwarding, so the misconception that a memory operand is as cheap as
a register operand if only the instruction set has memory operands of
operate instructions is a little bit closer to reality. It is still a misconception, because such an implementation can read and write
several times as many registers per cycle as memory operands.

A
lot of that time can be hidden with good caches and prefetchers, but if >>your memory access patterns are complicated, those speedups can fail to >>work.

Whether operate instructions in an instruction set have 0, 1, or 3
memory operands makes little difference in that case.

One reason for memory-to-memory instructions was to avoid the need to >>dedicate registers to operands, but that's not much of a problem these >>days, since we have space in the CPU for lots of registers and rename >>systems for them.

That may have been a consideration in the NOVA or the 6800, but in
case of the VAX with its 16 registers, that corresponds to a load/store-architecture with 18 registers, so for the VAX this is just
a minor issue.

Some time ago I thought a bit about which kind of architecture to
design with the transistor budget of the 6502, but with the RISC
lessons under the belt. One problem with a big RISC-like register set
is the instruction bandwidth. You really want to stick to 8-bit
instructions if you only have an 8-bit data bus. With a register architecture that means 2-bits for register operands, and that means
you would need a lot of loads and stores in a load/store architecture.
So the narrow instruction word almost forces you to use implicit
register operands or at small special-purpose register sets (e.g., 2 accumulators and 4 index registers, as in the 6809) rather than general-purpose registers.

However, the VAX 11/780 does not have these restrictions. It has a
wider memory bus and it has a cache.

DEC spent a lot of time and money trying to keep VAX competitive and took >>too long to accept that was impractical. That was one of the seeds of
their downfall.

Either that, or they failed to stick to VAX for the few more years
until they would have developed an OoO implementation, which would
have leveled the playing field again (see Pentium Pro). The Alpha
came out in 1992, the Pentium Pro in 1995, so if DEC has stuck to the
VAX and managed a timely OoO implementation, they would have needed to survive just 3 years. And it seems that they lost a lot of customers
in the transition from VAX to Alpha.

Of course, the question is if the customers would have stayed with DEC
if they had continued with the VAX. The vibe at the time was that
CISCs are doomed. OTOH, Intel stuck with IA-32 and won with the P6,
and IBM stuck with the S390. But VAX customers are not S390
customers, and maybe they would have defected to Intel even if the VAX
had been there.

In my opinion, DEC was caught at an ugly time for them. They did not
have the transistor budget for a GBOoO implementation at exactly the
time they also needed a clean transition to 64-bits (even more trans-
istors). DEC did have the transistors for a medium OoO implementation
but unlikely the 64-bit transition.

From what I read, the VAX 9000 was a big nail in the DEC coffin. In hindsight they should have canceled the project early, but that does
not mean that they could not have continued with VAX (they could even
have competed with the IBM mainframes, which took quite long to gain superscalar and OoO implementations).

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 6 Sep 2024 5:38:01 +0000, Anton Ertl wrote:

From
<[email protected]>:

bash grep gzip
595204 107636 46744 armhf 16 regs load/store 32-bit
599832 101102 46898 riscv64 32 regs load/store 64-bit
796501 144926 57729 amd64 16 regs ld-op ld-op-st 64-bit
829776 134784 56868 arm64 32 regs load/store 64-bit
853892 152068 61124 i386 8 regs ld-op ld-op-st 32-bit
891128 158544 68500 armel 16 regs load/store 32-bit
892688 168816 64664 s390x 16 regs ld-op ld-op-st 64-bit
1020720 170736 71088 mips64el 32 regs load/store 64-bit
1168104 194900 83332 ppc64el 32 regs load/store 64-bit

Is there source code freely available so these could be compiled
in My 66000 ISA and placed in the list ??

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brett <[email protected]> wrote:

Anton Ertl <[email protected]> wrote:

Here is a PDF on heads and tails:

http://scale.eecs.berkeley.edu/papers/hat-cases2001.pdf

They went for maximum density, which is stupid. The timing critical part is
the source registers, and in a wide implementation the dest registers are
also critical. Opcodes and data/offsets only matter far later in the
pipeline.

I would do three registers and enough opcode bits to get an idea of opcode
type and size. For one and two register instructions you pack in more
opcode.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (MitchAlsup1) writes:

On Fri, 6 Sep 2024 5:38:01 +0000, Anton Ertl wrote:

From
<[email protected]>:

bash grep gzip
595204 107636 46744 armhf 16 regs load/store 32-bit
599832 101102 46898 riscv64 32 regs load/store 64-bit
796501 144926 57729 amd64 16 regs ld-op ld-op-st 64-bit
829776 134784 56868 arm64 32 regs load/store 64-bit
853892 152068 61124 i386 8 regs ld-op ld-op-st 32-bit
891128 158544 68500 armel 16 regs load/store 32-bit
892688 168816 64664 s390x 16 regs ld-op ld-op-st 64-bit
1020720 170736 71088 mips64el 32 regs load/store 64-bit
1168104 194900 83332 ppc64el 32 regs load/store 64-bit

Is there source code freely available so these could be compiled
in My 66000 ISA and placed in the list ??

Yes. I measured the binaries of the Debian packages
bash_5.2.21-2_$arch.deb, grep_3.11-4~exp1_$arch.deb, and
gzip_1.12-1_$arch.deb (sometimes with an extra suffix: bash_5.2.21-2+b1_$arch.deb gzip_1.12-1+b2_$arch.deb). So look up
these packages, and then get the corresponding source packages.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (MitchAlsup1) writes:

In my opinion, DEC was caught at an ugly time for them. They did not
have the transistor budget for a GBOoO implementation at exactly the
time they also needed a clean transition to 64-bits (even more trans- >istors). DEC did have the transistors for a medium OoO implementation
but unlikely the 64-bit transition.

For the K8 the switch from 32-bit to 64-bit was reported to have cost
5%. You were there. Are the reports wrong?

The Pentium Pro has a die size of 306mm^2 in 0.5um and 196mm^2 in
0.35um according to <https://de.wikipedia.org/wiki/Intel_Pentium_Pro>
(it's interesting that Intel produced a 0.6um, 0.5um, and 0.35um
version; apparently their lock into a specific process for a chip came
only later).

The 64-bit OoO R10000 has a die size of 298mm^2 in 0.35um (but it was
a RISC).

DEC could fabricate the 299mm^2 21164 in 0.5um, and then the 21164a
with 209mm^2 in 0.35um (in 1996), and the 21264 with 314mm^2 in 0.35um
(in 1998).

An OoO VAX should be possible in 0.35um, maybe not 4-wide as the
R10000 and the 21264, but supporting three simple or three uops from
one complex instruction per cycle like the Pentium Pro.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brett <[email protected]> writes:

Anton Ertl <[email protected]> wrote:

Brett <[email protected]> writes:

But Vax allows all three arguments to be in memory with different pointers. >>>
Is this sane, just a natural progression if you allow memory operands?

In combination with supporting unaligned accesses (but excluding
indirect addressing), it means that an instruction can access 6 pages,
and so the TLB (and/or TLB loader) has to be designed to support that.
Likewise, the OS has to be designed to load all 6 pages into physical
RAM without evicting one of these pages again. So this kind of
architecture increases the design complexity. And I don't see a
benefit from this design.

The memory system is pipelined, once you load the first of the three
values, you do not care if that cache line is evicted while you load the >second.

Caches are 16 way today, one does not worry about cache line evictions, it >just works.

I did not write about caches, but yes, for TLBs a (the?) solution is
to have the ITLB to be at least 6-way.

It's unclear how pipelining should help. The VAX 11/780 was not much
pipelined and can also do the memory accesses one after the other;
this did not protect it from the complexity coming from x memory
accesses in a single instruction. E.g., all the pages accessed by an instruction have to be in physical memory, or maybe support
interruptable instructions; in any case, there is complexity.

Heads and tails encoding could actually do this reasonably, and the code >>> density would be actually be better than most competitors.

...

What is "heads and tails encoding"?

128 bit or larger packets with the fixed size opcodes on the front, and the >variable sized data and offsets packing in from the end. You get variable >length instruction density with easier faster wide decoding. And also using >memory operands give you another density bonus on top.

The only reason for VAX-style instructions is if you want to implement
the VAX instruction set, because you want to run software for the VAX
(and that reason started to vanish three decades ago and is now almost
gone). Also, decoding variable-length instructions is a solved
problem: Intel's P-cores and AMD's Zen-Zen5 cores solve it with
microcode caches, and Intel's recent E-cores (Tremont, Gracemont,
Chrestmont, Skymont) solve it by having 2-3 3-wide decoders.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 07 Sep 2024 05:04:34 GMT, Anton Ertl wrote:

[email protected] (MitchAlsup1) writes:

Is there source code freely available so these could be compiled in My >>66000 ISA and placed in the list ??

So look up these packages, and then get the corresponding source
packages.

Debian provides the “apt-get source” command for this purpose.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (Anton Ertl) writes:

[email protected] (MitchAlsup1) writes:

In my opinion, DEC was caught at an ugly time for them. They did not
have the transistor budget for a GBOoO implementation at exactly the
time they also needed a clean transition to 64-bits (even more trans- >>istors). DEC did have the transistors for a medium OoO implementation
but unlikely the 64-bit transition.

For the K8 the switch from 32-bit to 64-bit was reported to have cost
5%. You were there. Are the reports wrong?

In addition, VAX is a 32-bit architecture. It was not necessary to
extend it to 64 bits and do OoO at the same time. IBM stuck with its
31-bit addresses in s390 until 2000 when it was extended to the 64-bit z/Architecture (and the first implementation, the z900 was scalar, not
even in-order superscalar; they got superscalar in the z990 in 2003
and apparently out-of-order with the z196 in 2011; but then, IBM's
customers are probably less performance-sensitive than DEC's customers
used to be). Intel only delivered Merced (IA-64) in 2002 and
delivered Nocona (AMD64) in 2004.

Sure, there was marketing pressure to deliver 64-bit architectures
early, but I think that a competetive 32-bit OoO VAX in 1996 with an announcement of a future 64-bit extension would have been fine
wrt. marketing. And a 0.25um 64-bit VAX in 1999 or 2000 (they shrank
the 21264 to 0.25um in 1999) would have certainly made good on that
promise.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>, [email protected] (Anton Ertl) wrote:

Sure, there was marketing pressure to deliver 64-bit architectures
early, but I think that a competetive 32-bit OoO VAX in 1996 with an announcement of a future 64-bit extension would have been fine
wrt. marketing. And a 0.25um 64-bit VAX in 1999 or 2000 (they
shrank the 21264 to 0.25um in 1999) would have certainly made good
on that promise.

VAX had initially been very successful for the late 1970s and early 1980s
in technical computing, because it was performance-competitive and had a
better operating system than any of the other superminis of the time.

Then multiple RISCs with Unix came along, which were cheaper, had equal
or better performance, and a satisfactory operating system. Those ate
DEC's technical computing market quite fast, but its business IT market
lasted longer.

The technical computing market was /much/ more interested in 64-bit than
the business IT market. When I got involved at a software supplier for technical computing in 1995, VAX was not performance-competitive and was
on the way out, but Alpha was the fastest thing around until Pentium Pro, stayed competitive for a couple more years, and didn't die out completely
until 2002 or so.

DEC seem to have concluded in 1988 that they could not keep VAX
performance competitive with the RISCs of the time at a competitive price. Also, 64-bit ASAP was necessary to retain their part of the technical
computing market and try to win some of it back.

Trying to hold on with VAX, in the hope technology would emerge that
would make it practical, without a clear idea of when or what that would
be is not something that shareholders will tolerate for very long.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (John Dallman) writes:

In article <[email protected]>, >[email protected] (Anton Ertl) wrote:

Sure, there was marketing pressure to deliver 64-bit architectures
early, but I think that a competetive 32-bit OoO VAX in 1996 with an
announcement of a future 64-bit extension would have been fine
wrt. marketing. And a 0.25um 64-bit VAX in 1999 or 2000 (they
shrank the 21264 to 0.25um in 1999) would have certainly made good
on that promise.

VAX had initially been very successful for the late 1970s and early 1980s
in technical computing, because it was performance-competitive and had a >better operating system than any of the other superminis of the time.

Then multiple RISCs with Unix came along, which were cheaper, had equal
or better performance, and a satisfactory operating system. Those ate
DEC's technical computing market quite fast, but its business IT market >lasted longer.

The technical computing market was /much/ more interested in 64-bit than
the business IT market. When I got involved at a software supplier for >technical computing in 1995, VAX was not performance-competitive and was
on the way out, but Alpha was the fastest thing around until Pentium Pro, >stayed competitive for a couple more years, and didn't die out completely >until 2002 or so.

DEC seem to have concluded in 1988 that they could not keep VAX
performance competitive with the RISCs of the time at a competitive price.

Not really. They were still burning lots of money on the VAX 9000, a
dead end.

They stopped doing new VAX designs after the NVAX/NVAX+ was introduced
in 1991 (Alpha was introduced in 1992). There was the NVAX++ shrink
that improved the clock rate.

Also, 64-bit ASAP was necessary to retain their part of the technical >computing market and try to win some of it back.

Trying to hold on with VAX, in the hope technology would emerge that
would make it practical, without a clear idea of when or what that would
be is not something that shareholders will tolerate for very long.

They tolerated it for Intel and for IBM. Ok, IBM introduced Power for
the technical market, maybe that would have been the way to go for
DEC: continue with MIPS for the technical market, and continue with
VAX for the business market.

The Alpha with VMS and with translation to run VAX (and DecStation)
software sounds plausible, but somehow it did not work, neither for
keeping the technical nor the business customers, even though Alpha
was very competetive until the late 1990s.

Maybe the business customers would not have defected without the
VAX->Alpha transition, or maybe they would still have defected (they
were DEC customers instead of IBM customers for a reason).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (Anton Ertl) writes:

Brett <[email protected]> writes:

I did not write about caches, but yes, for TLBs a (the?) solution is
to have the ITLB to be at least 6-way.

It's unclear how pipelining should help. The VAX 11/780 was not much >pipelined and can also do the memory accesses one after the other;
this did not protect it from the complexity coming from x memory
accesses in a single instruction. E.g., all the pages accessed by an >instruction have to be in physical memory, or maybe support
interruptable instructions; in any case, there is complexity.

MOVC3/MOVC5 were interruptable; specifically to handle page faults
(and to reduce interrupt latency).

Given the arguments were in registers, interruptibility in that case
was just "restart with current register values". Similer to x86
REP string instructions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

Given modern OoO technology, even VAX can fly. It does not matter
whether, say,

*a++ = *b++ + *c++;

is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

It is my impression that unwinding all the side effects if the reference to "c" causes a
page fault was painful. Particularly keeping in mind that b and c could be the same
register, and if the code were this:

*a++ = *b++ - *b++

the order of increments and fetches matters.

If you split it into four ARM instructions, a fault just has to restart one of those
instructions which will have at most one register to fix up.

It is my impression that even when the Vax was designed, it was already becoming evident
that the Vax's super dense super encoded instruction set was not going to be a long term
winner. The IBM 801 project was well along in 1975 when they started designing the Vax.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 07 Sep 2024 16:37:00 GMT, Scott Lurndal wrote:

MOVC3/MOVC5 were interruptable ...

Given the arguments were in registers ...

The operands were in the perfectly general descriptor format, same as with nearly every other instruction.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 6 Sep 2024 6:05:35 +0000, Anton Ertl wrote:

[email protected] (John Dallman) writes:

Memory-to-memory instructions, in general, are hard to get to run fast
with today's processors and memory, simply because memory access times
are long enough for many register-to-register instructions to execute.

Given modern OoO technology, even VAX can fly. It does not matter
whether, say,

*a++ = *b++ + *c++;

is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

When I faced a similar set of desires, I had my movememory MM
instruction do::

for( control_register = 0,
control_register < Rs3,
control+register+=size )
rd[control_register] = rs1[control_register];

where size is determined by alignment, memory type (from PTE).
Thus, when a page fault or interrupt cuts the instruction in
the middle I don't have to recover any of the registers.

This also allows the instruction to be thrown over to the
Memory Function Unit and be performed in parallel with other
calculation instructions.

Getting back to the originating:: It is faster these days to
write::
a[i] = b[i] + c[i];i++;
than the pre/post increment/decrement style of PDP-11.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 8 Sep 2024 00:52:25 +0000, MitchAlsup1 wrote:

Getting back to the originating:: It is faster these days to write::
a[i] = b[i] + c[i];i++;
than the pre/post increment/decrement style of PDP-11.

That’s how I normally write the code in a high-level language, and have
done so since the 1980s.

I figured any decent compiler would be able to attend to the details I couldn’t be bothered thinking about. ;)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

According to Anton Ertl <[email protected]>:

Given modern OoO technology, even VAX can fly. It does not matter
whether, say,

*a++ = *b++ + *c++;

is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7 >>RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

It is my impression that unwinding all the side effects if the
reference to "c" causes a page fault was painful.

Yes, that was certainly a problem when using the implementation
techniques of the day. With an OoO implementation, if any of the
operations of the instruction causes an exception, none of the
results of any of the operations are commited. Problem solved.

Or almost: I expect that it's more complex to implement a reorder
buffer that deals with such monster instructions than one that deals
just with RISC-V instructions.

Particularly
keeping in mind that b and c could be the same register, and if the
code were this:

*a++ = *b++ - *b++

the order of increments and fetches matters.

Yes, but the decoder produces operations as defined by the
architecture. I don't know how VAX specifies the order, but a simple translation could be

# at the start, b is in p1, and a is in p6
p0 = *p1 #*b
p2 = p1+4 #b++
p3 = *p2 #*b
p4 = p2+4 #b++
p5 = p2-p4
*p6= p5 #*a = ...
p7 = p6+4 #a++
#at the end, b is in p4 and a is in p7

where p0..p7 are physical registers. If there is an exception in any
of the operations, b stays in p1 and a stays in p6.

It is my impression that even when the Vax was designed, it was
already becoming evident that the Vax's super dense super encoded
instruction set was not going to be a long term winner. The IBM 801
project was well along in 1975 when they started designing the Vax.

The question is how much was known about the IBM 801 at the time.
According to <https://en.wikipedia.org/wiki/OpenVMS>, the VAX project
started in April 1975. Data General's Fountainhead project (FHP)
started in July 1975. Intel started the iAPX 432 in 1975 or 1976,
Zilog started the Z8000 after recruiting Bernard Peuto in March 1976 <https://thechipletter.substack.com/p/captain-zilog-crushed-the-story-of>. Motorola started the 68000 project in late 1976, and National
Semiconductor obviously knew about the VAX when they designed the
32016 (they originally wanted to implement the VAX instruction set,
but in the end did something incompatible for legal reasons). All
these projects used CISCy designs rather than RISCy designs. FHP was
a bit special in making the writable control store an architectural
feature (so it did not have just one instruction set); the thinking
behind it is the "closing the semantic gap" idea that gave us
architectures like the VAX.

The first commercial RISCs were delivered in 1986 (including from IBM
itself). Apparently the industry took that long to absorb the ideas
from the IBM 801 and turn them into a commercial product.

It would be interesting to take a time machine to, say, 1976, to go to
any of these companies and try to convince them to do a RISCy CPU.
How hard would it be to convince them? Would technical arguments be sufficient, or would one have to wave with money (as a customer or
investor)? And how would such a CPU do in the marketplace?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The problem with VAX was NOT that one could not put a lot of
work in a single instruction;

no,

The problem with VAX is that it made putting too much work
in a single instruction easy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl <[email protected]> wrote:

John Levine <[email protected]> writes:

According to Anton Ertl <[email protected]>:

Given modern OoO technology, even VAX can fly. It does not matter
whether, say,

*a++ = *b++ + *c++;

is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

It is my impression that unwinding all the side effects if the
reference to "c" causes a page fault was painful.

Yes, that was certainly a problem when using the implementation
techniques of the day. With an OoO implementation, if any of the
operations of the instruction causes an exception, none of the
results of any of the operations are commited. Problem solved.

Or almost: I expect that it's more complex to implement a reorder
buffer that deals with such monster instructions than one that deals
just with RISC-V instructions.

Particularly
keeping in mind that b and c could be the same register, and if the
code were this:

*a++ = *b++ - *b++

the order of increments and fetches matters.

Yes, but the decoder produces operations as defined by the
architecture. I don't know how VAX specifies the order, but a simple translation could be

# at the start, b is in p1, and a is in p6
p0 = *p1 #*b
p2 = p1+4 #b++
p3 = *p2 #*b
p4 = p2+4 #b++
p5 = p2-p4
*p6= p5 #*a = ...
p7 = p6+4 #a++
#at the end, b is in p4 and a is in p7

where p0..p7 are physical registers. If there is an exception in any
of the operations, b stays in p1 and a stays in p6.

It is my impression that even when the Vax was designed, it was
already becoming evident that the Vax's super dense super encoded
instruction set was not going to be a long term winner. The IBM 801
project was well along in 1975 when they started designing the Vax.

The question is how much was known about the IBM 801 at the time.
According to <https://en.wikipedia.org/wiki/OpenVMS>, the VAX project
started in April 1975. Data General's Fountainhead project (FHP)
started in July 1975. Intel started the iAPX 432 in 1975 or 1976,
Zilog started the Z8000 after recruiting Bernard Peuto in March 1976 <https://thechipletter.substack.com/p/captain-zilog-crushed-the-story-of>. Motorola started the 68000 project in late 1976, and National
Semiconductor obviously knew about the VAX when they designed the
32016 (they originally wanted to implement the VAX instruction set,
but in the end did something incompatible for legal reasons). All
these projects used CISCy designs rather than RISCy designs. FHP was
a bit special in making the writable control store an architectural
feature (so it did not have just one instruction set); the thinking
behind it is the "closing the semantic gap" idea that gave us
architectures like the VAX.

The first commercial RISCs were delivered in 1986 (including from IBM itself). Apparently the industry took that long to absorb the ideas
from the IBM 801 and turn them into a commercial product.

It would be interesting to take a time machine to, say, 1976, to go to
any of these companies and try to convince them to do a RISCy CPU.
How hard would it be to convince them? Would technical arguments be sufficient, or would one have to wave with money (as a customer or
investor)? And how would such a CPU do in the marketplace?

The IBM 801 was boring and did not have a patent moat protecting it.

We have talent, we can build something more complex that keeps out
competition that does not have our talent.

They had no idea that complexity doubling every two years was going to
crush all those complex ideas. Instead they thought more transistors would
keep letting them add ever more complex features.

They had no idea that they would crash into the clock speed wall, and if
they did that argues for more complexity in the same clock time to get more done.

They had no idea that they would be building eight wide designs.
This is the critical idea that made RISC popular. They figured out that
they had been too smart for their own good.

We are post RISC now and adding complexity that gets more work done per operation, with less tracking. Three sources and two destinations will be
the rule. Load with address update, add with shift, three way add with
logical operations is next. The FPU already has MAC.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 8 Sep 2024 19:15:25 -0000 (UTC), Brett wrote:

We are post RISC now and adding complexity that gets more work done per operation, with less tracking. Three sources and two destinations will
be the rule. Load with address update, add with shift, three way add
with logical operations is next. The FPU already has MAC.

Does sound rather like another variant on Ivan Sutherland’s Wheel of Reincarnation, doesn’t it?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 8 Sep 2024 20:20:26 +0000, Thomas Koenig wrote:

Brett <[email protected]> schrieb:

[VAX]

They had no idea that they would be building eight wide designs.
This is the critical idea that made RISC popular.

Nope.

The early RISC designs aimed for one instruction per cycle, achieved
maybe 0.7.

But they were competing against processors with 4+ clocks per
instruction.

S.E.L 32/87 had an IBM 360-like ISA and also achieved 0.7 I/C largely
because it was NOT microcoded for 95% of the instructions executed,
but well pipelined. When it encountered an instruction that required
microcode to complete, the HW did the first cycle and then let micro-
code take over, and was ready to switch back to HW-control without
wasting a clock.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 8 Sep 2024 17:56:55 +0000, MitchAlsup1 wrote:

The problem with VAX was NOT that one could not put a lot of work in a
single instruction;

no,

The problem with VAX is that it made putting too much work in a single instruction easy.

Perhaps there is also the issue of the wildly-variable instruction length.
A single VAX operand descriptor could be up to 6 bytes; I think the
instruction with the most general-format operands could have 6 of them:
so, plus opcode, such an instruction could be 37 bytes long.

While the shortest instruction could be just 1 byte.

Even those who are talking about “post-RISC” are, I think, still in favour of RISC-style fixed instruction lengths.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brett <[email protected]> schrieb:

[VAX]

They had no idea that they would be building eight wide designs.
This is the critical idea that made RISC popular.

Nope.

The early RISC designs aimed for one instruction per cycle, achieved
maybe 0.7.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 8 Sep 2024 21:09:39 +0000, Lawrence D'Oliveiro wrote:

On Sun, 8 Sep 2024 17:56:55 +0000, MitchAlsup1 wrote:

The problem with VAX was NOT that one could not put a lot of work in a
single instruction;

no,

The problem with VAX is that it made putting too much work in a single
instruction easy.

Perhaps there is also the issue of the wildly-variable instruction
length.
A single VAX operand descriptor could be up to 6 bytes; I think the instruction with the most general-format operands could have 6 of them:
so, plus opcode, such an instruction could be 37 bytes long.

I have not heard an argument that the complex things in VAX ISA are
a) desirable
b) performance helpful

I (sort of) think VAX ISA as a grown up PDP-11, ignoring all the
dastardly complicated instructions it inflicted upon itself. AND
it did inflict those things upon itself.

Restricting a new-VAX-like ISA to 1-2-3 Operand and 1-result with
at most 1 exception would result in a MUCH cleaner and easier to
build machine.

While the shortest instruction could be just 1 byte.

Even those who are talking about “post-RISC” are, I think, still in favour of RISC-style fixed instruction lengths.

I, for the record, are in favor of fixed length instruction-specifier
followed by constants the entirety is the instruction, while the
former minimizes your ability of shooting yourself in the foot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig <[email protected]> wrote:

Brett <[email protected]> schrieb:

[VAX]

They had no idea that they would be building eight wide designs.
This is the critical idea that made RISC popular.

Nope.

The early RISC designs aimed for one instruction per cycle, achieved
maybe 0.7.

The next step up for a CPU has one ALU and one load/store unit, giving
above one IPC. This is what one of the PlayStation CPU’s did.

The yellow brick road to eight way was apparent with the first RISC architecture, even if not fully implemented due to time and die size.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 9 Sep 2024 04:38:42 -0000 (UTC), Brett wrote:

Thomas Koenig <[email protected]> wrote:

The early RISC designs aimed for one instruction per cycle, achieved
maybe 0.7.

The next step up for a CPU has one ALU and one load/store unit, giving
above one IPC. This is what one of the PlayStation CPU’s did.

Those were the ones using PowerPC chips in the 1990s, I think it was.
IBM’s POWER claimed superscalar performance right from its launch in, what was it, 1989.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Mon, 9 Sep 2024 04:38:42 -0000 (UTC), Brett wrote:

The next step up for a CPU has one ALU and one load/store unit, giving
above one IPC. This is what one of the PlayStation CPU’s did.

Those were the ones using PowerPC chips in the 1990s, I think it was.

The first PlayStation used a 33MHz R3000 (single-issue).

The PS2 released in 2000 used a 299MHz MIPS R5900-based core, two-way in-order superscalar.

The PS3 released in 2006 used the PowerPC-based Cell broadband engine.

IBM’s POWER claimed superscalar performance right from its launch in, what >was it, 1989.

1990.

It's interesting that it took so long to go to dual-issue with the
same number of functional units. I guess that the early RISCs were bandwidth-limited, and only once the L1 cache(s) came on-chip, was
there enough bandwidth to make superscalarity actually pay off.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

Perhaps there is also the issue of the wildly-variable instruction length.
A single VAX operand descriptor could be up to 6 bytes; I think the >instruction with the most general-format operands could have 6 of them:
so, plus opcode, such an instruction could be 37 bytes long.

The regularity of the VAX operand formats may actually help build the
decoder: Decode your byte stream as possible operands, and then let
the instruction decoder pick the real operands from the potential
operands.

Even those who are talking about “post-RISC” are, I think, still in favour >of RISC-style fixed instruction lengths.

Even among the RISCs, fixed instruction lengths are not universal: ARM
T32 has two widths, as has RV64GC (and RISC-V has provisions for
additional lengths, but AFAIK nobody uses them yet); there was also
ROMP and MIPS16.

Interestingly, despite their ample experience with T32, ARM went
fixed-length with A64, but then the market for A64 is probably not as
code-size sensitive as that for T32.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 09 Sep 2024 08:03:00 GMT
[email protected] (Anton Ertl) wrote:

Interestingly, despite their ample experience with T32, ARM went
fixed-length with A64, but then the market for A64 is probably not as code-size sensitive as that for T32.

- anton

ARMv9-M is still T32 which probably should tell us something.
Or, may be, not.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 09 Sep 2024 08:03:00 GMT, Anton Ertl wrote:

... ARM T32 has two widths, as has RV64GC (and RISC-V has provisions for additional lengths, but AFAIK nobody uses them yet); there was also ROMP
and MIPS16.

That’s all very well. But none of them go to the extremes that VAX did:
37:1, remember.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> writes:

ARMv9-M is still T32 which probably should tell us something.

It tells me that ARM sees a market (covered by the M profile) where
4GB of address space is sufficient and where code size is relevant.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 09 Sep 2024 11:33:37 GMT
[email protected] (Anton Ertl) wrote:

Michael S <[email protected]> writes:

ARMv9-M is still T32 which probably should tell us something.

It tells me that ARM sees a market (covered by the M profile) where
4GB of address space is sufficient and where code size is relevant.

- anton

I think that the sad (for Arm) truth is that ARMv8-M was unnecessary
except for tiny niches and ARMv9-M even more so. ARMv7-M works fine for overwhelming majority of user.
So even if they somehow invent fixed-width 32-bit architecture that
matches T32 in code density and then implement it in core that matches Cortex-M4 in performance per clock, but occupies 10% smaller area
clocks 10% faster on the same process, their major licensees (STMicro,
TI, NXP) wouldn't be willing to pay 1 cent more for that core than what
they are currently paying for M4.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 <[email protected]> wrote:

On Sun, 8 Sep 2024 21:09:39 +0000, Lawrence D'Oliveiro wrote:

On Sun, 8 Sep 2024 17:56:55 +0000, MitchAlsup1 wrote:

The problem with VAX was NOT that one could not put a lot of work in a
single instruction;

no,

The problem with VAX is that it made putting too much work in a single
instruction easy.

Perhaps there is also the issue of the wildly-variable instruction
length.
A single VAX operand descriptor could be up to 6 bytes; I think the
instruction with the most general-format operands could have 6 of them:
so, plus opcode, such an instruction could be 37 bytes long.

I have not heard an argument that the complex things in VAX ISA are
a) desirable
b) performance helpful

Speaking of complex things, have you looked at Swift output, as it checks
all operations for overflow?

You could add an exception type for that, saving huge numbers of correctly predicted branch instructions.

The future of programming languages is type safe with checks, you need to
get on that bandwagon early.

I (sort of) think VAX ISA as a grown up PDP-11, ignoring all the
dastardly complicated instructions it inflicted upon itself. AND
it did inflict those things upon itself.

Restricting a new-VAX-like ISA to 1-2-3 Operand and 1-result with
at most 1 exception would result in a MUCH cleaner and easier to
build machine.

While the shortest instruction could be just 1 byte.

Even those who are talking about “post-RISC” are, I think, still in
favour of RISC-style fixed instruction lengths.

I, for the record, are in favor of fixed length instruction-specifier followed by constants the entirety is the instruction, while the
former minimizes your ability of shooting yourself in the foot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

Lawrence D'Oliveiro <[email protected]d> writes:

Perhaps there is also the issue of the wildly-variable instruction length. >>A single VAX operand descriptor could be up to 6 bytes; I think the >>instruction with the most general-format operands could have 6 of them:
so, plus opcode, such an instruction could be 37 bytes long.

The regularity of the VAX operand formats may actually help build the >decoder: Decode your byte stream as possible operands, and then let
the instruction decoder pick the real operands from the potential
operands.

Urrgh. Some of those bogus operands are indirect indexed auto-increment, so you are going to be throwing away a whole lot of work.

Compare that to zSeries, where even after 50 years of sticking new instructions into the holes in the S/360 instruction set, it can still tell the length of the
instruction from the first two bits and the operands from the first byte.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 9 Sep 2024 19:38:52 +0000, Brett wrote:

MitchAlsup1 <[email protected]> wrote:

On Sun, 8 Sep 2024 21:09:39 +0000, Lawrence D'Oliveiro wrote:

On Sun, 8 Sep 2024 17:56:55 +0000, MitchAlsup1 wrote:

The problem with VAX was NOT that one could not put a lot of work in a >>>> single instruction;

no,

The problem with VAX is that it made putting too much work in a single >>>> instruction easy.

Perhaps there is also the issue of the wildly-variable instruction
length.
A single VAX operand descriptor could be up to 6 bytes; I think the
instruction with the most general-format operands could have 6 of them:
so, plus opcode, such an instruction could be 37 bytes long.

I have not heard an argument that the complex things in VAX ISA are
a) desirable
b) performance helpful

Speaking of complex things, have you looked at Swift output, as it
checks
all operations for overflow?

You could add an exception type for that, saving huge numbers of
correctly predicted branch instructions.

Unlike RISC-V and may others; My 66000 has maskable integer exceptions.
An exception can be routed directly to a signal handler of the current application (without a trip through GuestOS). GuestOS just has to
configure where exceptions are delivered.

The future of programming languages is type safe with checks, you need
to get on that bandwagon early.

This would/will happen faster when type-safe with checks are well
represented in benchmarks used to measure various architectural
things, and the exceptions and checks are actually utilized showing
performance degradation of lesser endowed architectures.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Brett <[email protected]> writes:

Speaking of complex things, have you looked at Swift output, as it checks
all operations for overflow?

You could add an exception type for that, saving huge numbers of correctly >predicted branch instructions.

The future of programming languages is type safe with checks, you need to
get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on
signed overflow) in addition to addu (which performs modulo
arithmetic). It has been abandoned and replaced by RISC-V several
years ago.

Alpha got on that bandwagon early. It's a descendent of MIPS, but it
renamed add into addv, and addu into add. It has been canceled around
the year 2000.

RISC-V, another descendent of MIPS, has an add instruction that
corresponds to MIPS' addu, and no instruction that corresponds to
MIPS' add. They obviously don't think that there's a bandwagon. Note
that RISC-V was designed after Swift was introduced.

IA-32 got on that bandwagon early. It has a single-byte instruction
trapv that traps if the overflow flag is set. The AMD64 instruction
set is very similar to the IA-32 instruction set, but one of the few differences is that the trapv instruction was eliminated, and the
encoding replaced with a REX prefix. The AMD64 architects obviously
don't think that there is a bandwagon.

Apple has been designing their own silicon for a while, and they have introduced Swift as their language in 2010. Yet they have not
switched to an architecture like MIPS or Alpha, nor have they designed
their own architecture or architecture extension that includes
instructions like Alpha's addv or IA-32's trapv. Instead, they
switched to ARM A64, which does not have such features, after
introducing Swift in 2010. They obviously don't think that there is
such a bandwagon, either.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-09-09 23:44, MitchAlsup1 wrote:

On Mon, 9 Sep 2024 19:38:52 +0000, Brett wrote:

[snip]

The future of programming languages is type safe with checks, you need
to get on that bandwagon early.

This would/will happen faster when type-safe with checks are well
represented in benchmarks used to measure various architectural
things, and the exceptions and checks are actually utilized showing performance degradation of lesser endowed architectures.

Not all the type-safe, checking languages are equal in that respect. In
some languages, and I am thinking of Ada, the language design and the
favored programming styles work to reduce the number of run-time checks required.

In the Ada case, the ability to declare array types with
programmer-chosen index types with bounded range, such as range-bounded integers or enumerations, means that the compiler can avoid indexing
checks when the (sub)type of the index is known at compile time to fit
within the index range of the array.

It is also helpful that loop counters in Ada are also (sub)typed in the
same way, which provides compile-time information on their range with
respect to the index range of arrays accessed in the loop, even if the
bounds of the range are not known at compile time.

As a result of these language features, the matching programming styles,
and the attention paid to these issues by the compilers, the number of
run-time checks executed by an Ada program and their effect on execution
time are often surprisingly small.

So, to demonstrate the usefulness of HW support for checks, the
benchmarks should use languages that require checks but do not have the features that let programmers reduce the number of checks by suitable programming styles. If Ada were used for the benchmarks, the programmers
would have to use an abnormal, pessimal style that defeats the
compiler's ability to elide checks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

According to Anton Ertl <[email protected]>:

The regularity of the VAX operand formats may actually help build the >>decoder: Decode your byte stream as possible operands, and then let
the instruction decoder pick the real operands from the potential
operands.

Urrgh. Some of those bogus operands are indirect indexed auto-increment, so you
are going to be throwing away a whole lot of work.

Yes, AFAIK that's how multi-instruction decoding for variable-width
instruction sets works these days: Decode at every potential
instruction start, then select those decoded instructions that are at
actual instruction boundaries, and throw the others away.

Compare that to zSeries, where even after 50 years of sticking new instructions
into the holes in the S/360 instruction set, it can still tell the length of the
instruction from the first two bits and the operands from the first byte.

Good for sequential decoding, and maybe it makes parallel decoding
cheaper (but OTOH, the first superscalar S/360 descendent came out in
2000, 7 years after the superscalar Pentium, and the first OoO S/360
descendent lagged the Pentium Pro by 14 years or so), but as the IIRC
6-wide decoder of Alder Lake demonstrates, hardware designers are able
to deal with instruction sets that do not have such nice properties:
an AMD64 instruction can have a large number of prefixes, and I think
that the encoding of indexed addressing is not announced in the first non-prefix instruction byte, either.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 07:43:53 GMT
[email protected] (Anton Ertl) wrote:

Brett <[email protected]> writes:

Speaking of complex things, have you looked at Swift output, as it
checks all operations for overflow?

You could add an exception type for that, saving huge numbers of
correctly predicted branch instructions.

The future of programming languages is type safe with checks, you
need to get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on
signed overflow) in addition to addu (which performs modulo
arithmetic).

Trapping variants were deprecated in Release 6 of MIPS ISA.

It has been abandoned and replaced by RISC-V several

years ago.

I don't think that "replaced by RISC-V" is a correct description of proceedings.

Alpha got on that bandwagon early. It's a descendent of MIPS, but it
renamed add into addv, and addu into add. It has been canceled around
the year 2000.

RISC-V, another descendent of MIPS, has an add instruction that
corresponds to MIPS' addu, and no instruction that corresponds to
MIPS' add. They obviously don't think that there's a bandwagon. Note
that RISC-V was designed after Swift was introduced.

IA-32 got on that bandwagon early. It has a single-byte instruction
trapv that traps if the overflow flag is set. The AMD64 instruction
set is very similar to the IA-32 instruction set, but one of the few differences is that the trapv instruction was eliminated, and the
encoding replaced with a REX prefix. The AMD64 architects obviously
don't think that there is a bandwagon.

Apple has been designing their own silicon for a while, and they have introduced Swift as their language in 2010. Yet they have not
switched to an architecture like MIPS or Alpha, nor have they designed
their own architecture or architecture extension that includes
instructions like Alpha's addv or IA-32's trapv. Instead, they
switched to ARM A64, which does not have such features, after
introducing Swift in 2010. They obviously don't think that there is
such a bandwagon, either.

- anton

How does Intel MPX fit in your picture?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 08:05:07 GMT
[email protected] (Anton Ertl) wrote:

John Levine <[email protected]> writes:

Compare that to zSeries, where even after 50 years of sticking new >instructions into the holes in the S/360 instruction set, it can
still tell the length of the instruction from the first two bits and
the operands from the first byte.

Good for sequential decoding, and maybe it makes parallel decoding
cheaper (but OTOH, the first superscalar S/360 descendent came out in
2000, 7 years after the superscalar Pentium, and the first OoO S/360 descendent lagged the Pentium Pro by 14 years or so),

Wikipedia says that ES/9000 Model 900 had superscalar OoO CPU in 1991.
This line was abandoned in favor of simpler 'CMOS' line in mid 90s, but according to the same Wiki article, CMOS line didn't matched Model 900
in performance until 9672-RY5 near the end of 1997.

but as the IIRC
6-wide decoder of Alder Lake demonstrates, hardware designers are able
to deal with instruction sets that do not have such nice properties:
an AMD64 instruction can have a large number of prefixes, and I think
that the encoding of indexed addressing is not announced in the first non-prefix instruction byte, either.

- anton

1. The longest AMD64 instruction is much shorter than the longest VAX instruction
2. On AMD64 instruction length information is continuous. Yes, there
could be multiple prefixes and it makes things ugly, but I would think
that in practice you very rarely need to look at more than 5 leading
bytes in order to figure out the length of the tail. And in practice
it's probably o.k. when instructions with more than 3 prefixes decoded
slowly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> writes:

On Tue, 10 Sep 2024 08:05:07 GMT
[email protected] (Anton Ertl) wrote:

Good for sequential decoding, and maybe it makes parallel decoding
cheaper (but OTOH, the first superscalar S/360 descendent came out in
2000, 7 years after the superscalar Pentium

Correction: The first superscalar CMOS S/360 descendent, the z990 came
out in 2003, a decade after the Pentium, but see below about bipolar
CPUs.

and the first OoO S/360
descendent lagged the Pentium Pro by 14 years or so),

Wikipedia says that ES/9000 Model 900 had superscalar OoO CPU in 1991.

Reading up on this, the article says even more:

|models 900 and 820 had full out-of-order execution for both integer
|and floating-point units, with precise exception handling, and a fully |superscalar pipeline.

So these are probably the first proper OoO processors (while the
360-91 was an interesting prototype, it was too limited to count as
proper OoO CPU). The 900 ran at 111MHz, and the 1994-vintage 9X2 ran
at 141MHz and was rated at 468MIPS (for 10 CPUs), i.e. each 141MHz CPU
at 47MIPS. So that would be an IPC of 1/3, which is somewhat
disappointing even for an early superscalar OoO machine. But then I
don't know how IBM produces its MIPS ratings.

This line was abandoned in favor of simpler 'CMOS' line in mid 90s, but >according to the same Wiki article, CMOS line didn't matched Model 900
in performance until 9672-RY5 near the end of 1997.

A single-issue in-order CPU running at 370MHz with comparable per-CPU performance (and also 1-10CPUs); apparently 49MIPS for one CPU and
447MIPS for 10. Again, the IPC seems abysmal, but who knows how IBM
measures MIPS. Still, I expect that a contemporaneous Pentium II
outperforms this 9672 by a lot on, say, SPEC95, just because of the
basic technology and clock rate.

It seems that during the late 1990s, IBM was not particularly
interested in mainframe per-CPU performance.

1. The longest AMD64 instruction is much shorter than the longest VAX >instruction
2. On AMD64 instruction length information is continuous. Yes, there
could be multiple prefixes and it makes things ugly, but I would think
that in practice you very rarely need to look at more than 5 leading
bytes in order to figure out the length of the tail. And in practice
it's probably o.k. when instructions with more than 3 prefixes decoded >slowly.

Yes, you can always choose to take slow paths on rare cases, but you
can also do that for a VAX decoder. I don't expect that the 37 bytes
(or whatever it is) is the common case.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> writes:

On Tue, 10 Sep 2024 07:43:53 GMT
[email protected] (Anton Ertl) wrote:

Brett <[email protected]> writes:

Speaking of complex things, have you looked at Swift output, as it
checks all operations for overflow?

You could add an exception type for that, saving huge numbers of
correctly predicted branch instructions.

The future of programming languages is type safe with checks, you
need to get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on
signed overflow) in addition to addu (which performs modulo
arithmetic).

Trapping variants were deprecated in Release 6 of MIPS ISA.

Interesting. So they abandoned the supposed bandwagon in 2014, after
Swift was introduced.

What they did add in the same release are branch instructions that
check whether the sum of two signed integers overflows. That's useful
for languages with arbitrarily large integers (also knowns as Big
Integers or Bignums), while the trapping adds are too cumbersome for
that purpose.

And it seems to me that Swift with its trapping arithmetic is a blast
from the past (with Algol, Pascal etc. usually erroring out on
overflow, and Ada raising an exception (with famously explosive
consequences for the Ariane 5)), and that the trend in safe languages
is to eliminate integer overflow by allowing arbitrarily large
integers.

It has been abandoned and replaced by RISC-V several

years ago.

I don't think that "replaced by RISC-V" is a correct description of >proceedings.

I don't know anything about the proceedings, just what Wikipedia tells
me:

|In March 2021, MIPS announced that the development of the MIPS
|architecture had ended as the company is making the transition to
|RISC-V.

Sounds like a replacement to me.

How does Intel MPX fit in your picture?

I don't know anything about MPX beyond what Wikipedia says, which
includes:

|In practice, there have been too many flaws discovered in the design
|for it to be useful, and support has been deprecated or removed from
|most compilers and operating systems.

Maybe a less flawed concept would have been more successful, but
apparently MPX has had no such successor.

Overall, languages that perform bounds checking seem on the rise,
unlike languages that trap on signed integer overflow, so the window
of opportunity for architectural support gets bigger.

However, the question is if there is architectural support that is significantly better than what can be done with the current
architectural features. SPARC has architectural tagging support for
LISP, yet a comp.arch poster who worked on a major LISP implementation
(Franz LISP IIRC) reported that their LISP implementation does not use
these instructions.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-09-10 18:42, Anton Ertl wrote:

And it seems to me that Swift with its trapping arithmetic is a
blast from the past

The dominance of C and its descendants has corrupted the world of
programming on this point. :-(

Fortunately, among up-and-coming new languages Rust is in the
overflow-checking camp, at least in DEBUG-mode compilations.

(with Algol, Pascal etc. usually erroring out on
overflow, and Ada raising an exception (with famously explosive
consequences for the Ariane 5)),

A bit misleading, as so often when the Ariane 501 incident is brought up.

The Ariane 501 failure was a HW trap on an instruction converting a floating-point value into a 16-bit integer, not an Ada exception.

As I understand it, the analogous C code could have used the same
instruction and failed in the same way (an example of Undefined Behavior)

The original designers of that Ada SW had carefully analysed the
possible ranges of the numbers and correctly concluded that an overflow
could not happen if the HW operated correctly. Correctly, that is, for
the Ariane 4, but not for the Ariane 5 where the SW was sloppily reused
through multiple process skimps and failures.

Several other similar conversions were protected with programmed range
checks and suitable alternative code paths, but the analysis showed that
this particular conversion did not need such checks for the Ariane 4.

One of the process failures was that the SW was never tested with the
Ariane 5 launch trajectory, which would have revealed the error.

If the SW had really used Ada exceptions (difficult as the processor was
quite maxed out) a reasonable SW designer would have added an exception
handler and could have made this part of the SW fail gracefully. But
the mission would probably not have been saved because the failure investigation found other potentially fatal flaws in the systems,
pointing to more process failures.

and that the trend in safe languages is to eliminate integer overflow
by allowing arbitrarily large integers.

That is not practical in a real-time, resource-limited context, at least
not without a large over-provision of computing resources. And sending
the resulting over-large integer to a HW register will still fail in
some way if the value is too large for the HW to accept.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 16:32:05 GMT, Anton Ertl wrote:

It seems that during the late 1990s, IBM was not particularly interested
in mainframe per-CPU performance.

Mainframes were never about CPU performance. They were about high I/O throughput for efficient batch operations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 07:43:53 GMT, Anton Ertl wrote:

[MIPS] has been abandoned and replaced by RISC-V several years ago.

I’m not so sure the MIPS architecture has been “abandoned”. Last I heard, it was still shipping hundreds of millions of chips per year. Also those Chinese supers run LoongArch, which is some sort of MIPS derivative.

It is true that there is no more money to be made from licensing any “MIPS IP”, which is why Imagination Tech, the inheritors of whatever was left of MIPS the commercial operation, have switched to being a RISC-V-centric
company now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 11:13:11 +0300, Niklas Holsti wrote:

Not all the type-safe, checking languages are equal in that respect. In
some languages, and I am thinking of Ada, the language design and the
favored programming styles work to reduce the number of run-time checks required.

True, and this was also demonstrated with Pascal before Ada.

It’s a point that those who are accustomed to program in C seem to find it difficult to appreciate.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It appears that Anton Ertl <[email protected]> said:

The future of programming languages is type safe with checks, you need to >>get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on
signed overflow) in addition to addu (which performs modulo
arithmetic). It has been abandoned and replaced by RISC-V several
years ago.

S/360 had signed and unsigned adds in the 1960s, with optional
trapping for signed overflow. OS/360 let you catch the traps and z
still does but it is not my impression that many programs did or do.


--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> schrieb:

It appears that Anton Ertl <[email protected]> said:

The future of programming languages is type safe with checks, you need to >>>get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on
signed overflow) in addition to addu (which performs modulo
arithmetic). It has been abandoned and replaced by RISC-V several
years ago.

S/360 had signed and unsigned adds in the 1960s, with optional
trapping for signed overflow. OS/360 let you catch the traps and z
still does but it is not my impression that many programs did or do.

With trapping, I understand. Without trapping - what is the
difference on a two's complement machine?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig <[email protected]> writes:

John Levine <[email protected]> schrieb:

S/360 had signed and unsigned adds in the 1960s, with optional
trapping for signed overflow. OS/360 let you catch the traps and z
still does but it is not my impression that many programs did or do.

With trapping, I understand. Without trapping - what is the
difference on a two's complement machine?

Possibly in the flags set. The S/360 has a pretty perverse flags
architecture.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 15:42:25 GMT
[email protected] (Anton Ertl) wrote:

Michael S <[email protected]> writes:

How does Intel MPX fit in your picture?

I don't know anything about MPX beyond what Wikipedia says, which
includes:

|In practice, there have been too many flaws discovered in the design
|for it to be useful, and support has been deprecated or removed from
|most compilers and operating systems.

Maybe a less flawed concept would have been more successful, but
apparently MPX has had no such successor.

Overall, languages that perform bounds checking seem on the rise,
unlike languages that trap on signed integer overflow, so the window
of opportunity for architectural support gets bigger.

Yes, I posted my questions without sufficient thinking.
Intel MPX is about array bound checks which is a separate issue from
catching signed overflow.
The only commonality is that in both cases there is a potential for
significant saving in code size if checks are handled by exception
instead of conditional branch.

However, the question is if there is architectural support that is significantly better than what can be done with the current
architectural features. SPARC has architectural tagging support for
LISP, yet a comp.arch poster who worked on a major LISP implementation
(Franz LISP IIRC) reported that their LISP implementation does not use
these instructions.

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Sep 2024 23:51:20 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Tue, 10 Sep 2024 07:43:53 GMT, Anton Ertl wrote:

[MIPS] has been abandoned and replaced by RISC-V several years ago.

I’m not so sure the MIPS architecture has been “abandoned”. Last I heard, it was still shipping hundreds of millions of chips per year.

Care to point to the source of this claim? Two main suppliers of MIPS
silicon in this century are Microchip and Cavium (now owned by Marvell).

According to my understanding Microchip's MIPS-based PIC32 line was
never as popular as their other offerings.

In case of Marvell, I no longer see MIPS-based Octeon III chips in the
product section of their Web site. Which, I'd guess, means that in order
to buy one you has to be an existing customer. Since the market that
Octeon III was playing in, is rather dynamic, I don't expect that those existing customers buy very old chips in tens of millions. Likely not
even in single-digit millions.

Also those Chinese supers run LoongArch, which is some sort of MIPS derivative.

Sort of.
And majority of my FPGA designs run Nios2 soft cores that are also
'sort of MIPS'. But they are *not* MIPS.

It is true that there is no more money to be made from licensing any
“MIPS IP”, which is why Imagination Tech, the inheritors of whatever
was left of MIPS the commercial operation, have switched to being a RISC-V-centric company now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/09/2024 10:54, Michael S wrote:

On Tue, 10 Sep 2024 23:51:20 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Tue, 10 Sep 2024 07:43:53 GMT, Anton Ertl wrote:

[MIPS] has been abandoned and replaced by RISC-V several years ago.

I’m not so sure the MIPS architecture has been “abandoned”. Last I
heard, it was still shipping hundreds of millions of chips per year.

Care to point to the source of this claim? Two main suppliers of MIPS
silicon in this century are Microchip and Cavium (now owned by Marvell).

According to my understanding Microchip's MIPS-based PIC32 line was
never as popular as their other offerings.

IMHO a major reason for that is Microchip's insane licensing policy for
their development tools - although their compilers are just a minor modification of standard gcc, you have to pay huge amounts if you want
to use the full features of the compiler. (At least now you can enable
/some/ optimisation without a paid license.) It is not even possible to
see from the release notes or documentation what version of gcc is
provided, though my guess is that it is pretty old (the documentation
describes "-std" options up to C++14).

The other reason, of course, was the name - "PIC" is associated with
brain-dead microcontrollers with terrible C tools and which many people
program in assembly. They are also renowned for being very solid,
coming in relatively amateur-friendly packages, and for never going out
of production.

For some time now, Microchip's PIC32 line has all had ARM Cortex-M cores
in new devices, based on SAM parts they got when they purchased Atmel.
But they still sell the existing MIPS microcontrollers.

Sort of.
And majority of my FPGA designs run Nios2 soft cores that are also
'sort of MIPS'. But they are *not* MIPS.

I thought the NIOS 2 was more "MIPS inspired" than "sort of MIPS". (And
the original NIOS was "SPARC inspired.) They have now jumped to NIOS V,
which is RISC-V (actual RISC-V).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Tue, 10 Sep 2024 16:32:05 GMT, Anton Ertl wrote:

It seems that during the late 1990s, IBM was not particularly interested
in mainframe per-CPU performance.

Mainframes were never about CPU performance.

The S/360 Model 91 and the Model 195 certainly were about the maximum
CPU performance. And I doubt that IBM would have spent all the effort
with ECL and a superscalar OoO implementation for some of the ES/9000
machines if CPU performance was considered unimportant at the time.

It's an interesting question why they did not follow up their
superscalar OoO ECL implementations with a superscalar OoO CMOS
implementation in addition to the scalar in-order 9672. Here are
three speculations of what happened:

1) They had such a project and it did not work out, and the "never
about CPU performance" spin is a sour-grapes type rationalization of
the result.

2) They expected their mainframe market to be eaten up by the Unix
and/or WNT markets, and did not want to invest a lot into the
development of mainframe CPUs. Again, the "never about CPU
performance" spin is a sour-grapes type rationalization of the result.

3) They had decided that they had a captive market in the mainframes,
with software that was written for lower-powered CPUs, that the rapid
CMOS advances in the 1990s would give them enough of a performance
push to satisfy the needs of this software, so no more sophisticated
CPU designs that the 9672 was necessary (and the G5 and G6 of the 9672
indeed gave them more CPU power than ever). The "never about CPU
performance" reflected their position at the time and also served to
placate anyone who pointed out that the per-CPU performance was
inferior to that of other CPUs of the time, including IBM's own
RS/6000 line.

Eventually they seem to have decided that per-CPU performance is
important after all, with the superscalar z990 in 2003 and the OoO
z196 in 2010. But of course Dennart scaling was slowing down around
2003, so they needed to increase IPC to increase per-CPU performance.
And even if they don't need more per-CPU performance than other
architectures, they apparently do need advances over earlier
generations of their own machines and maybe to discourage competition
from emulators or startups.

They were about high I/O
throughput for efficient batch operations.

Batch operations? I wonder how much CPU time on mainframes in the
1990s and today is spent on that compared to interactive applications
such as online transaction processing.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/11/2024 2:24 AM, Anton Ertl wrote:

Thomas Koenig <[email protected]> writes:

John Levine <[email protected]> schrieb:

S/360 had signed and unsigned adds in the 1960s, with optional
trapping for signed overflow. OS/360 let you catch the traps and z
still does but it is not my impression that many programs did or do.

With trapping, I understand. Without trapping - what is the
difference on a two's complement machine?

Possibly in the flags set. The S/360 has a pretty perverse flags architecture.

In the EC PSW from my yellow card
bit 20 fixed-point overflow mask
bit 21 decimal overflow mask
bit 22 exponent overflow mask
bit 23 significance mask

BC mode was bits 36 thru 39.

Joe Seigh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Thomas Koenig <[email protected]>:

John Levine <[email protected]> schrieb:

It appears that Anton Ertl <[email protected]> said:

The future of programming languages is type safe with checks, you need to >>>>get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on >>>signed overflow) in addition to addu (which performs modulo
arithmetic). It has been abandoned and replaced by RISC-V several
years ago.

S/360 had signed and unsigned adds in the 1960s, with optional
trapping for signed overflow. OS/360 let you catch the traps and z
still does but it is not my impression that many programs did or do.

With trapping, I understand. Without trapping - what is the
difference on a two's complement machine?

Different condition codes. Signed add:

0 Sum is zero
1 Sum is less than zero
2 Sum is greater than zero
3 Overflow

Unsigned add:

0 Sum is zero (no carry)
1 Sum is not zero (no carry)
2 Sum is zero (carry)
3 Sum is not zero (carry)

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

Lawrence D'Oliveiro <[email protected]d> writes:

On Tue, 10 Sep 2024 16:32:05 GMT, Anton Ertl wrote:

It seems that during the late 1990s, IBM was not particularly interested >>> in mainframe per-CPU performance.

Mainframes were never about CPU performance.

The S/360 Model 91 and the Model 195 certainly were about the maximum
CPU performance. And I doubt that IBM would have spent all the effort
with ECL and a superscalar OoO implementation for some of the ES/9000 >machines if CPU performance was considered unimportant at the time.

It's an interesting question why they did not follow up their
superscalar OoO ECL implementations with a superscalar OoO CMOS >implementation in addition to the scalar in-order 9672. ...

IBM definitely cared about maximum performance in the 1950s and early 1960s.

The goal of STRETCH was specifically to make the fastest possible computer. It sort of
succeeded, late and over budget and not as fast as they hoped, but still the fastest
computer in the world for a while. It was a success in that they reused a lot of the
technology like the fast core memory in later computers.

The 360/91 was also intended to be the fastest possible computer, which again it sort of
was, late and over budget. One thing that STRETCH and the /91 shared was that they were
extremely complicated. STRETCH had variable sized bytes and and addressing modes that I
never entirely figured out. The /91 had an instruction queue with loop mode and out of
order operations and register renaming and imprecise interrupts. When the CDC 6600 came
out, a much simpler design from a tiny company that was nonetheless faster than the /91,
they knew they had a problem. The /95 and /195 were minor upgrades of the /91 but that was
the end of their supercomputer efforts.

The point of a mainframe is balanced performance. The CPU of a 360/30 was extremely slow
but it was fast enough to drive a disk or two and a printer and card read/punch and get a
lot of useful work done. Mainframes have had channels since the 709 in the late 1950s so
they have a lot of I/O capacity. Modern ones have terabytes of RAM and exabyte of disk.

They also care deeply about reliability. Modern mainframes have multiple kinds of error
checking and standby CPUs that can take over from a failed CPU, restart a failed
instruction, and the program doesn't notice. I think you'll find a pattern since the
CDC shock of making CPUs fast enough to keep the RAM and I/O devices busy while having
the error checking and recovery features so the systems keep running for years at a time.



--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl <[email protected]> wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Tue, 10 Sep 2024 16:32:05 GMT, Anton Ertl wrote:

It seems that during the late 1990s, IBM was not particularly interested >>> in mainframe per-CPU performance.

Mainframes were never about CPU performance.

The S/360 Model 91 and the Model 195 certainly were about the maximum
CPU performance. And I doubt that IBM would have spent all the effort
with ECL and a superscalar OoO implementation for some of the ES/9000 machines if CPU performance was considered unimportant at the time.

It's an interesting question why they did not follow up their
superscalar OoO ECL implementations with a superscalar OoO CMOS implementation in addition to the scalar in-order 9672. Here are
three speculations of what happened:

1) They had such a project and it did not work out, and the "never
about CPU performance" spin is a sour-grapes type rationalization of
the result.

2) They expected their mainframe market to be eaten up by the Unix
and/or WNT markets, and did not want to invest a lot into the
development of mainframe CPUs. Again, the "never about CPU
performance" spin is a sour-grapes type rationalization of the result.

3) They had decided that they had a captive market in the mainframes,
with software that was written for lower-powered CPUs, that the rapid
CMOS advances in the 1990s would give them enough of a performance
push to satisfy the needs of this software, so no more sophisticated
CPU designs that the 9672 was necessary (and the G5 and G6 of the 9672
indeed gave them more CPU power than ever). The "never about CPU performance" reflected their position at the time and also served to
placate anyone who pointed out that the per-CPU performance was
inferior to that of other CPUs of the time, including IBM's own
RS/6000 line.

IBM had huge caches the PC’s could not match and smart IO processors to handle much of the load, that PC’s had to handle with the CPU because they were cheap.

You could go into this as my knowledge is mostly SWAG based off marketing
bull and what little I know.

Then there is the issue of cheap PC’s that fail, and a mainframes have a higher level of redundancy and failover. Failed business transactions can
cost millions, more than the machine is worth, so saving pennies on
hardware is stupid.

Eventually they seem to have decided that per-CPU performance is
important after all, with the superscalar z990 in 2003 and the OoO
z196 in 2010. But of course Dennart scaling was slowing down around
2003, so they needed to increase IPC to increase per-CPU performance.
And even if they don't need more per-CPU performance than other architectures, they apparently do need advances over earlier
generations of their own machines and maybe to discourage competition
from emulators or startups.

They were about high I/O
throughput for efficient batch operations.

Batch operations? I wonder how much CPU time on mainframes in the
1990s and today is spent on that compared to interactive applications
such as online transaction processing.

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Brown <[email protected]> schrieb:

On 11/09/2024 10:54, Michael S wrote:

On Tue, 10 Sep 2024 23:51:20 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Tue, 10 Sep 2024 07:43:53 GMT, Anton Ertl wrote:

[MIPS] has been abandoned and replaced by RISC-V several years ago.

I’m not so sure the MIPS architecture has been “abandoned”. Last I >>> heard, it was still shipping hundreds of millions of chips per year.

Care to point to the source of this claim? Two main suppliers of MIPS
silicon in this century are Microchip and Cavium (now owned by Marvell).

According to my understanding Microchip's MIPS-based PIC32 line was
never as popular as their other offerings.

IMHO a major reason for that is Microchip's insane licensing policy for
their development tools - although their compilers are just a minor modification of standard gcc, you have to pay huge amounts if you want
to use the full features of the compiler. (At least now you can enable /some/ optimisation without a paid license.) It is not even possible to
see from the release notes or documentation what version of gcc is
provided, though my guess is that it is pretty old (the documentation describes "-std" options up to C++14).

Sounds like a violation of the GPL. Do they provide the sources?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Stephen Fuld <[email protected]d>:

IBM definitely cared about maximum performance in the 1950s and early

1960s.

Yes. And remember, one of the goals of S/360 was to provide an
architecture that could handle both scientific (i.e. compute bound) and >business (i.e. I/O bound) workloads.

I don't think anyone would have forseen how quickly scientific computing
moved to mini and micro computers with fast CPUs and weak peripherals.
Perhaps once the RAM is big enough to hold all the data the I/O performance
is not a big deal.

they knew they had a problem. The /95 and /195 were minor upgrades of

the /91 but that was the end of their supercomputer efforts.

Mostly true, except for the 3090 vector facility.

I suppose. A review from the USDOE said:

The IBM 3090 with Vector Facility is an extremely interesting machine
because it combines very good scaler performance with enhanced vector
and multitasking performance. For many IBM installations with a large
scientific workload, the 3090/vector/MTF combination may be an ideal
means of increasing throughput at minimum cost. However, neither the
vector nor multitasking capabilities are sufficiently developed to
make the 3090 competitive with our current worker machines for our
large-scale scientific codes.

https://www.osti.gov/biblio/5039931

instruction, and the program doesn't notice. I think you'll find a

pattern since the

CDC shock of making CPUs fast enough to keep the RAM and I/O devices

busy while having

the error checking and recovery features so the systems keep running

for years at a time.

Yes, but they also have to keep producing faster and faster CPUs so they
can entice current customers to upgrade and thus meet their revenue goals.

The memories and disks keep getting bigger so it's not totally silly to
think that the CPUs need to get faster, too. They keep increasing the
number of CPUs, with z16 topping out at 200, all sharing up to 40TB of RAM.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/11/2024 9:21 AM, John Levine wrote:

According to Anton Ertl <[email protected]>:

Lawrence D'Oliveiro <[email protected]d> writes:

On Tue, 10 Sep 2024 16:32:05 GMT, Anton Ertl wrote:

It seems that during the late 1990s, IBM was not particularly

interested

in mainframe per-CPU performance.

Mainframes were never about CPU performance.

The S/360 Model 91 and the Model 195 certainly were about the maximum
CPU performance. And I doubt that IBM would have spent all the effort
with ECL and a superscalar OoO implementation for some of the ES/9000
machines if CPU performance was considered unimportant at the time.

It's an interesting question why they did not follow up their
superscalar OoO ECL implementations with a superscalar OoO CMOS
implementation in addition to the scalar in-order 9672. ...

IBM definitely cared about maximum performance in the 1950s and early

1960s.

Yes. And remember, one of the goals of S/360 was to provide an
architecture that could handle both scientific (i.e. compute bound) and business (i.e. I/O bound) workloads.

The goal of STRETCH was specifically to make the fastest possible

computer. It sort of

succeeded, late and over budget and not as fast as they hoped, but

still the fastest

computer in the world for a while. It was a success in that they

reused a lot of the

technology like the fast core memory in later computers.

The 360/91 was also intended to be the fastest possible computer,

which again it sort of

was, late and over budget. One thing that STRETCH and the /91 shared

was that they were

extremely complicated. STRETCH had variable sized bytes and and

addressing modes that I

never entirely figured out. The /91 had an instruction queue with

loop mode and out of

order operations and register renaming and imprecise interrupts. When

the CDC 6600 came

out, a much simpler design from a tiny company that was nonetheless

faster than the /91,

they knew they had a problem. The /95 and /195 were minor upgrades of

the /91 but that was

the end of their supercomputer efforts.

Mostly true, except for the 3090 vector facility.

The point of a mainframe is balanced performance. The CPU of a 360/30

was extremely slow

but it was fast enough to drive a disk or two and a printer and card

read/punch and get a

lot of useful work done. Mainframes have had channels since the 709

in the late 1950s so

they have a lot of I/O capacity. Modern ones have terabytes of RAM

and exabyte of disk.

Yes.

They also care deeply about reliability. Modern mainframes have

multiple kinds of error

checking and standby CPUs that can take over from a failed CPU,

restart a failed

instruction, and the program doesn't notice. I think you'll find a

pattern since the

CDC shock of making CPUs fast enough to keep the RAM and I/O devices

busy while having

the error checking and recovery features so the systems keep running

for years at a time.

Yes, but they also have to keep producing faster and faster CPUs so they
can entice current customers to upgrade and thus meet their revenue goals.



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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/09/2024 19:02, Thomas Koenig wrote:

David Brown <[email protected]> schrieb:

On 11/09/2024 10:54, Michael S wrote:

On Tue, 10 Sep 2024 23:51:20 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Tue, 10 Sep 2024 07:43:53 GMT, Anton Ertl wrote:

[MIPS] has been abandoned and replaced by RISC-V several years ago.

I’m not so sure the MIPS architecture has been “abandoned”. Last I >>>> heard, it was still shipping hundreds of millions of chips per year.

Care to point to the source of this claim? Two main suppliers of MIPS
silicon in this century are Microchip and Cavium (now owned by Marvell). >>>
According to my understanding Microchip's MIPS-based PIC32 line was
never as popular as their other offerings.

IMHO a major reason for that is Microchip's insane licensing policy for
their development tools - although their compilers are just a minor
modification of standard gcc, you have to pay huge amounts if you want
to use the full features of the compiler. (At least now you can enable
/some/ optimisation without a paid license.) It is not even possible to
see from the release notes or documentation what version of gcc is
provided, though my guess is that it is pretty old (the documentation
describes "-std" options up to C++14).

Sounds like a violation of the GPL. Do they provide the sources?

Yes.

It's perfectly fine to take the gcc sources, add in some code that
checks for a paid license of some sort, and distribute that as a binary
- as long as you also provide the source for it. So you /could/ take
the source and compile it yourself (or just get the original gcc source,
or another binary build of gcc MIPS).

But the license for their header files, SDKs, libraries, IDE (which,
IIRC, was basically NetBeans) and other tools says you can only use them
with an unmodified binary that they provide. And writing your own
header files for a big microcontroller is not a quick and easy job.

I believe there was no legal violation of the GPL, but there was no
doubt that it was trashing the spirit of it.

And as far as I could see from a look at their website, they are still
at the same game (though you can now enable /some/ optimisations), now
with the ARM core PIC32 devices as well.

Every other ARM or RISC V based microcontroller manufacturer I have seen provides free gcc and/or clang tools, along with a free IDE (Eclipse or
MS Code). They will also provide support for paid tools like ARM's
development tools, or IAR, or maybe Green Hills - these are expensive,
but that's fair enough. What is not fair, even if it is legal, is
taking something that they get for free and charging multiple
kilodollars for people to use it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/11/2024 10:50 AM, John Levine wrote:

According to Stephen Fuld <[email protected]d>:

IBM definitely cared about maximum performance in the 1950s and early

1960s.

Yes. And remember, one of the goals of S/360 was to provide an
architecture that could handle both scientific (i.e. compute bound) and
business (i.e. I/O bound) workloads.

I don't think anyone would have forseen how quickly scientific computing moved to mini and micro computers with fast CPUs and weak peripherals.

Agreed, plus the development of CDC/Cray supercomputers that took the
high end scientific market away from IBM.

Perhaps once the RAM is big enough to hold all the data the I/O performance is not a big deal.

they knew they had a problem. The /95 and /195 were minor upgrades of

the /91 but that was the end of their supercomputer efforts.

Mostly true, except for the 3090 vector facility.

I suppose. A review from the USDOE said:

The IBM 3090 with Vector Facility is an extremely interesting machine
because it combines very good scaler performance with enhanced vector
and multitasking performance. For many IBM installations with a large
scientific workload, the 3090/vector/MTF combination may be an ideal
means of increasing throughput at minimum cost. However, neither the
vector nor multitasking capabilities are sufficiently developed to
make the 3090 competitive with our current worker machines for our
large-scale scientific codes.

https://www.osti.gov/biblio/5039931

I didn't claim that the 3090VF was successful, just that IBM was
interested enough in the scientific market to spend money developing it
after the 370/195.

instruction, and the program doesn't notice. I think you'll find a

pattern since the

CDC shock of making CPUs fast enough to keep the RAM and I/O devices

busy while having

the error checking and recovery features so the systems keep running

for years at a time.

Yes, but they also have to keep producing faster and faster CPUs so they
can entice current customers to upgrade and thus meet their revenue goals.

The memories and disks keep getting bigger so it's not totally silly to
think that the CPUs need to get faster, too.

Agreed, of course.



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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/11/2024 2:32 AM, Anton Ertl wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

snip

They were about high I/O
throughput for efficient batch operations.

Batch operations? I wonder how much CPU time on mainframes in the
1990s and today is spent on that compared to interactive applications
such as online transaction processing.

Perhaps it would have been better stated as being about balanced
performance (CPU and I/O) for business applications, which at the time
were primarily batch, but have migrated over time to transactions, but
which still are more I/O bound than scientific workloads.



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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> schrieb:

According to Stephen Fuld <[email protected]d>:

IBM definitely cared about maximum performance in the 1950s and early >>1960s.

Yes. And remember, one of the goals of S/360 was to provide an >>architecture that could handle both scientific (i.e. compute bound) and >>business (i.e. I/O bound) workloads.

I don't think anyone would have forseen how quickly scientific computing moved to mini and micro computers with fast CPUs and weak peripherals. Perhaps once the RAM is big enough to hold all the data the I/O performance is not a big deal.

they knew they had a problem. The /95 and /195 were minor upgrades of >>the /91 but that was the end of their supercomputer efforts.

Don't forget the ACS.

Looking at (if that is to be believed) https://people.computing.clemson.edu/~mark/acs_performance.html
this seems to have been quite an amazing machine for its time,
with projected 160 MFlops and around five concurrent instructions
using OoO.

Had this been realized, it would havbe been as fast as the Cray-I.
But it never reached the market, so...

Mostly true, except for the 3090 vector facility.

I suppose. A review from the USDOE said:

We had that in our IBM 3090 at the computer center. Compared to the
Fujitsu VP machine sitting next to it, it was not impressive at
all (which can also be read in the report you youted).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Sep 2024 9:32:04 +0000, Anton Ertl wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Tue, 10 Sep 2024 16:32:05 GMT, Anton Ertl wrote:

It seems that during the late 1990s, IBM was not particularly interested >>> in mainframe per-CPU performance.

Mainframes were never about CPU performance.

The S/360 Model 91 and the Model 195 certainly were about the maximum
CPU performance. And I doubt that IBM would have spent all the effort
with ECL and a superscalar OoO implementation for some of the ES/9000 machines if CPU performance was considered unimportant at the time.

91 was Current-Mode-Logic CML. Don't know about 195.
CML had all of the speed and all of the electrical and all of the heat
problems ECK had.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Sep 2024 16:21:19 +0000, John Levine wrote:

According to Anton Ertl <[email protected]>:

Lawrence D'Oliveiro <[email protected]d> writes:

The 360/91 was also intended to be the fastest possible computer, which
again it sort of
was, late and over budget. One thing that STRETCH and the /91 shared was
that they were
extremely complicated. STRETCH had variable sized bytes and and
addressing modes that I
never entirely figured out. The /91 had an instruction queue with loop
mode and out of
order operations and register renaming and imprecise interrupts. When
the CDC 6600 came
out, a much simpler design from a tiny company that was nonetheless
faster than the /91,
they knew they had a problem. The /95 and /195 were minor upgrades of
the /91 but that was
the end of their supercomputer efforts.

You forgot to mention /91 had a 60ns clock while 6600 had a 100 ns
clock.
Here was a case where parallelism beat out pipelining.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig <[email protected]> writes:

John Levine <[email protected]> schrieb:

According to Stephen Fuld <[email protected]d>:

IBM definitely cared about maximum performance in the 1950s and early >>>1960s.

Yes. And remember, one of the goals of S/360 was to provide an >>>architecture that could handle both scientific (i.e. compute bound) and >>>business (i.e. I/O bound) workloads.

I don't think anyone would have forseen how quickly scientific computing
moved to mini and micro computers with fast CPUs and weak peripherals.
Perhaps once the RAM is big enough to hold all the data the I/O performance >> is not a big deal.

they knew they had a problem. The /95 and /195 were minor upgrades of >>>the /91 but that was the end of their supercomputer efforts.

Don't forget the ACS.

Looking at (if that is to be believed) >https://people.computing.clemson.edu/~mark/acs_performance.html
this seems to have been quite an amazing machine for its time,
with projected 160 MFlops and around five concurrent instructions
using OoO.

The (cancelled) Burroughs Scientific Processor was as fast as
a Cray-I.

The Burroughs Scientific Processor (BSP), a high-performance
computer system, performed the Department of Energy LLL loops
at roughly the speed of the CRAY-1. The BSP combined parallelism
and pipelining, performing memory-to-memory operations. Seventeen
memory units and two crossbar switch data alignment networks
provided conflict-free access to most indexed arrays. Fast linear
recurrence algorithms provided good performance on constructs that
some machines execute serially. A system manager computer ran the
operating system and a vectorizing Fortran compiler. An MOS file
memory system served as a high bandwidth secondary memory.

https://ieeexplore.ieee.org/document/1676014 https://en.wikipedia.org/wiki/Parallel_Element_Processing_Ensemble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/11/2024 9:21 AM, John Levine wrote:

I think you'll find a pattern since the
CDC shock of making CPUs fast enough to keep the RAM and I/O devices busy while having
the error checking and recovery features so the systems keep running for years at a time.

So do these systems not require security patches?
Or do they apply PTFs to the running system? (reliably?)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Lars Poulsen <[email protected]>:

On 9/11/2024 9:21 AM, John Levine wrote:

I think you'll find a pattern since the
CDC shock of making CPUs fast enough to keep the RAM and I/O devices busy while having
the error checking and recovery features so the systems keep running for years at a time.

So do these systems not require security patches?
Or do they apply PTFs to the running system? (reliably?)

They don't just update the software, they swap out entire hardware subsystems while the
overall system keeps running.
--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Sep 2024 11:36:46 -0700, Stephen Fuld wrote:

Perhaps it would have been better stated as being about balanced
performance (CPU and I/O) for business applications, which at the time
were primarily batch, but have migrated over time to transactions, but
which still are more I/O bound than scientific workloads.

Depending on the kind of transactions: online interactive stuff requires
low latencies as opposed to high throughput. Mainframes are optimized for
high throughput.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Sep 2024 16:39:23 -0000 (UTC), Brett wrote:

Then there is the issue of cheap PC’s that fail, and a mainframes have a higher level of redundancy and failover. Failed business transactions
can cost millions, more than the machine is worth, so saving pennies on hardware is stupid.

You solve that by having multiple units of the cheap machines to achieve
the same level of redundancy, or even more. That ends up being more cost- effective than the mainframe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Sep 2024 21:12:34 +0000, MitchAlsup1 wrote:

91 was Current-Mode-Logic CML. ...
CML had all of the speed and all of the electrical and all of the heat problems ECK had.

IBM over-promising and under-delivering, again.

The ’90, or was it the ’91, or the ‘92, was the machine IBM promised to deliver to those customers who were looking to buy a CDC machine. It
remained vapourware for close to two years I think it was, and was underwhelming when it did finally appear. But it still managed to cost CDC
a lot of sales in the meantime.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Sep 2024 16:21:19 -0000 (UTC), John Levine wrote:

They also care deeply about reliability. Modern mainframes have multiple kinds of error checking and standby CPUs that can take over from a
failed CPU, restart a failed instruction, and the program doesn't
notice.

This “mainframe reliability” seems to be a persistent myth. There is a document at Bitsavers, dating from 1986, which says that, if you want to
turn daylight saving on or off on an IBM mainframe, you really should
reboot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 02:05:14 -0000 (UTC), John Levine wrote:

They don't just update the software, they swap out entire hardware
subsystems while the overall system keeps running.

Xen Orchestra (open-source) can do that on commodity PC hardware.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

IBM definitely cared about maximum performance in the 1950s and early

1960s.

Yes. And remember, one of the goals of S/360 was to provide an
architecture that could handle both scientific (i.e. compute bound) and
business (i.e. I/O bound) workloads.

I don't think anyone would have forseen how quickly scientific computing moved to mini and micro computers with fast CPUs and weak peripherals. Perhaps once the RAM is big enough to hold all the data the I/O performance is not a big deal.

Back around 1986 or so I stated that all programming tasks will migrate
down to the lowest/cheapest architecture which is large enough to handle
the task. This meant that I was sure both minis and mainframes would go
away, so I was in fact only 99.9% correct. :-)

Terje

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 12 Sep 2024 02:05:14 -0000 (UTC), John Levine wrote:

They don't just update the software, they swap out entire hardware
subsystems while the overall system keeps running.

Xen Orchestra (open-source) can do that on commodity PC hardware.

The 3leaf hypervisor supported hot-plug memory, hot-plug CPU
hot-plug PCI 15 years ago with commodity linux guests.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Wed, 11 Sep 2024 16:21:19 -0000 (UTC), John Levine wrote:

They also care deeply about reliability. Modern mainframes have multiple
kinds of error checking and standby CPUs that can take over from a
failed CPU, restart a failed instruction, and the program doesn't
notice.

This “mainframe reliability” seems to be a persistent myth.

Where do you come up with this nonsense?

Have you not heard of Tandem, or Stratus?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/11/24 4:40 AM, David Brown wrote:

The other reason, of course, was the name - "PIC" is associated with brain-dead microcontrollers with terrible C tools and which many people program in assembly.  They are also renowned for being very solid,
coming in relatively amateur-friendly packages, and for never going out
of production.

After having written code for a PIC I agree with "brain-dead". The small
sized memory pages were bad enough but the total lack of an add with
carry instruction drove me mad.

So I swore them off and the introduction of a MIPS based system did
nothing to change that.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Lawrence D'Oliveiro <[email protected]d>:

On Wed, 11 Sep 2024 16:39:23 -0000 (UTC), Brett wrote:

Then there is the issue of cheap PC’s that fail, and a mainframes have a >> higher level of redundancy and failover. Failed business transactions
can cost millions, more than the machine is worth, so saving pennies on
hardware is stupid.

You solve that by having multiple units of the cheap machines to achieve
the same level of redundancy, or even more. That ends up being more cost- >effective than the mainframe.

That's fine for workloads that work that way.

Airline reservation systems historically ran on mainframes because when they were invented
that's all there was (original SABRE ran on two 7090s) and they are business critical so
they need to be very reliable.

About 30 years ago some guys at MIT realized that route and fare search, which are some of
the most demanding things that CRS do, are easy to parallelize and don't have to be
particularly reliable -- if your search system crashes and restarts and reruns the search
and the result is a couple of seconds late, that's OK. So they started ITA software which
used racks of PC servers running parallel applications written in Lisp (they were from
MIT) and blew away the competition.

However, that's just the search part. Actually booking the seats and selling tickets stays
on a mainframe or an Oracle system because double booking or giving away free tickets would
be really bad.

There's also a rule of thumb about databases that says one system of performance 100 is
much better than 100 systems of performance 1 because those 100 systems will spend all
their time contending for database locks.




--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 20:10:43 -0000 (UTC), John Levine wrote:

Actually booking the seats and
selling tickets stays on a mainframe or an Oracle system because double booking or giving away free tickets would be really bad.

Fun fact: double-booking happens all the time.

I don’t think either mainframes or Oracle are still dominant in this sort
of business. After all, Paul Graham’s Orbitz was doing this sort of thing over 20 years ago ... in LISP.

<https://paulgraham.com/carl.html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine wrote:

According to Lawrence D'Oliveiro <[email protected]d>:

On Wed, 11 Sep 2024 16:39:23 -0000 (UTC), Brett wrote:

Then there is the issue of cheap PC’s that fail, and a mainframes have a
higher level of redundancy and failover. Failed business transactions
can cost millions, more than the machine is worth, so saving pennies on
hardware is stupid.

You solve that by having multiple units of the cheap machines to achieve
the same level of redundancy, or even more. That ends up being more cost-
effective than the mainframe.

That's fine for workloads that work that way.

Airline reservation systems historically ran on mainframes because when they were invented
that's all there was (original SABRE ran on two 7090s) and they are business critical so
they need to be very reliable.

About 30 years ago some guys at MIT realized that route and fare search, which are some of
the most demanding things that CRS do, are easy to parallelize and don't have to be
particularly reliable -- if your search system crashes and restarts and reruns the search
and the result is a couple of seconds late, that's OK. So they started ITA software which
used racks of PC servers running parallel applications written in Lisp (they were from
MIT) and blew away the competition.

However, that's just the search part. Actually booking the seats and selling tickets stays
on a mainframe or an Oracle system because double booking or giving away free tickets would
be really bad.

You could replicate much of that part as well, for most of the time, by setting aside chunks of seats to parallel servers, so that they can
book/sell within that chunk until they start to run out. This way the expensive system is mostly needed only when the front ends run out?

There's also a rule of thumb about databases that says one system of performance 100 is
much better than 100 systems of performance 1 because those 100 systems will spend all
their time contending for database locks.

10-15 years ago I talked to another speaker at a conference, he told me
that he was working on high-end open source LDAP software using _very_
large memory DBs: Their system allowed one US cell phone company to keep
every SIM card (~100M) on a single system, while a similar-size
competitor had been forced to fall back on 17-way sharding (presumably
using a hash of the SIM id).

Terje

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Scott Lurndal wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 12 Sep 2024 02:05:14 -0000 (UTC), John Levine wrote:

They don't just update the software, they swap out entire hardware
subsystems while the overall system keeps running.

Xen Orchestra (open-source) can do that on commodity PC hardware.

The 3leaf hypervisor supported hot-plug memory, hot-plug CPU
hot-plug PCI 15 years ago with commodity linux guests.

Novell's System Fault Tolerant NetWare 386 (around 1990) supported two
complete servers acting like one, so that any hardware component could
fail and the system would keep running, with nothing noticed by the
clients, even those that were in the middle of an update/write request.

Worked with a private high-speed link between the two servers, so that
all requests were mirrored from master to slave. This way the slave
would do the requested operation in sync with the master, maintaining
the exact same state so it was ready to take over at any point.

BTW, since the pair naturally had separate network connections, they
could also be connected to separate LAN segments, and this worked
transparently because every server (single or SFT) maintained a LAN
segment inside the server: This way the two server connections just
looked like redundant routing paths.

Terje

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

According to Lawrence D'Oliveiro <[email protected]d>:

You solve that by having multiple units of the cheap machines to achieve >>the same level of redundancy, or even more. That ends up being more cost- >>effective than the mainframe.

That's fine for workloads that work that way.

Airline reservation systems historically ran on mainframes because
when they were invented that's all there was (original SABRE ran on
two 7090s) and they are business critical so they need to be very
reliable.

About 30 years ago some guys at MIT realized that route and fare
search, which are some of the most demanding things that CRS do, are
easy to parallelize and don't have to be particularly reliable -- if
your search system crashes and restarts and reruns the search and the
result is a couple of seconds late, that's OK. So they started ITA
software which used racks of PC servers running parallel applications
written in Lisp (they were from MIT) and blew away the competition.

However, that's just the search part. Actually booking the seats and
selling tickets stays on a mainframe or an Oracle system because
double booking or giving away free tickets would be really bad.

Booking flights or seats can easily be distributed: each flight is
assigned to one computer. To avoid double booking or free tickets
even in case of a computer crash, you use the usual transaction
processing approach, and report completion of the booking only when
the booking has reached persistent memory. For persistent memory you
use SSDs with power-loss protection.

These SSDs, ECC RAM, RAID-1, redundant power supplies and UPSs protect
against most hardware failures, but availability is still a concern
(e.g., motherboard or CPU failure; that normally does not affect data
integrity if the other measures are taken, but it affects
availability). To increase availability, you can use e.g., DRBD
(distributed replicated block device) to get the data on multiple
machines.

Concerning "real bad": Airlines overbook their flights as a matter of
policy to increase their revenue. If they had a booking system that double-booked, say, 1ppm of all bookings, they probably would not even
notice, and would deal with it in the same way they deal with the
cases when the overbooking actually results in too many passengers
arriving for the flight. Likewise, free tickets are not an issue if
they occur rarely enough. Do they want to spend a million on a
mainframe to avoid a revenue loss of $100k? But in any case, that's
not the problem with cheap hardware.

The problems are: When the persistent storage fails, you lose all
transactions since the latest backup. To avoid that, RAID-1 helps, or
a redundant distributed storage like DRBD, or a redundant distributed transaction system. You may also want more availability than a single
system with RAID-1 (with a spare system standing by) provides, then
you have to go for one of the redundant distributed approaches.

However, my impression from booking flights online is that reliability
of the booking platform is not at all a concern for the airlines. And
as a customer, I find little difference between the booking front-end
erroring out or the transaction back-end being unavailable.

There's also a rule of thumb about databases that says one system of >performance 100 is much better than 100 systems of performance 1
because those 100 systems will spend all their time contending for
database locks.

If you handle each flight on one system, the contention for locks is
only within that one system. And I expect that there is not that much contention. How many people book the same flight within the same
millisecond (or however long the lock is held)?

Concerning performance 100 vs. performance 1, about what systems are
you thinking? z17 will have 32*8=256 cores (of unknown performance
that is likely to be disappointing, or IBM would not disallow
publishing benchmark results), compared to similar numbers of cores on
servers with AMD or Intel CPUs, or 16-24 cores on systems based on
desktop chips (with Intel you pay a heavy premium these days if you
want ECC memory, however).

Interestingly, with increasing number of cores per socket in recent
years, the number of sockets is going down. E.g., the successor for
the HPE Superdome Flex with up to 32 sockets (up to 32*28=896 cores)
is the HPE Compute Scale-Up Server 3200 with up to 16 sockets
(16*60=960 cores). Either there is little demand for single systems
with more cores, or there are technical difficulties (probably both).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 09:15:52 +0200, Terje Mathisen wrote:

Novell's System Fault Tolerant NetWare 386 (around 1990) supported two complete servers acting like one, so that any hardware component could
fail and the system would keep running, with nothing noticed by the
clients, even those that were in the middle of an update/write request.

Just so long as it wasn’t the network connection between them that failed.

See also, “CAP Theorem”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 20:10:43 -0000 (UTC)
John Levine <[email protected]> wrote:

According to Lawrence D'Oliveiro <[email protected]d>:

On Wed, 11 Sep 2024 16:39:23 -0000 (UTC), Brett wrote:

Then there is the issue of cheap PC’s that fail, and a mainframes
have a higher level of redundancy and failover. Failed business
transactions can cost millions, more than the machine is worth, so
saving pennies on hardware is stupid.

You solve that by having multiple units of the cheap machines to
achieve the same level of redundancy, or even more. That ends up
being more cost- effective than the mainframe.

That's fine for workloads that work that way.

Airline reservation systems historically ran on mainframes because
when they were invented that's all there was (original SABRE ran on
two 7090s) and they are business critical so they need to be very
reliable.

About 30 years ago some guys at MIT realized that route and fare
search, which are some of the most demanding things that CRS do, are
easy to parallelize and don't have to be particularly reliable -- if
your search system crashes and restarts and reruns the search and the
result is a couple of seconds late, that's OK. So they started ITA
software which used racks of PC servers running parallel applications
written in Lisp (they were from MIT) and blew away the competition.

However, that's just the search part. Actually booking the seats and
selling tickets stays on a mainframe or an Oracle system because
double booking or giving away free tickets would be really bad.

There's also a rule of thumb about databases that says one system of performance 100 is much better than 100 systems of performance 1
because those 100 systems will spend all their time contending for
database locks.

How many transactions per minute does world's biggest company need at
peak hours? Is not this number small relatively to capabilities of
even 15 y.o. dual-Xeon server with few dozens of spinning rust disks?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro wrote:

On Fri, 13 Sep 2024 09:15:52 +0200, Terje Mathisen wrote:

Novell's System Fault Tolerant NetWare 386 (around 1990) supported two
complete servers acting like one, so that any hardware component could
fail and the system would keep running, with nothing noticed by the
clients, even those that were in the middle of an update/write request.

Just so long as it wasn’t the network connection between them that failed.

See also, “CAP Theorem”.

If that failed, normal network routing would apply and the master-slave traffic would go out and back in over the normal network cards, but of
course giving slighlty reduced performance.

Terje

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terje Mathisen <[email protected]> schrieb:

10-15 years ago I talked to another speaker at a conference, he told me
that he was working on high-end open source LDAP software using _very_
large memory DBs: Their system allowed one US cell phone company to keep every SIM card (~100M) on a single system, while a similar-size
competitor had been forced to fall back on 17-way sharding (presumably
using a hash of the SIM id).

Keeping databases in memory is definitely a thing now... see SAP HANA.

Any architectural implications for this?

Browsing through the SAP pages, it seems they used Intel's Optane
persistent memory, but that is no longer manufactured (?). But
having fast, persistent storage is definitely an advantage for
databases.

Large memory: Of course.

On the ISA level... these databases run on x86, so that seems to
be good enough.

Anything else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 11:20:06 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:

Terje Mathisen <[email protected]> schrieb:

10-15 years ago I talked to another speaker at a conference, he
told me that he was working on high-end open source LDAP software
using _very_ large memory DBs: Their system allowed one US cell
phone company to keep every SIM card (~100M) on a single system,
while a similar-size competitor had been forced to fall back on
17-way sharding (presumably using a hash of the SIM id).

Keeping databases in memory is definitely a thing now... see SAP HANA.

Any architectural implications for this?

Browsing through the SAP pages, it seems they used Intel's Optane
persistent memory, but that is no longer manufactured (?). But
having fast, persistent storage is definitely an advantage for
databases.

Large memory: Of course.

On the ISA level... these databases run on x86, so that seems to
be good enough.

Anything else?

Another thing that SAP HANA seems to use more intensely than anybody
else is Intel TSX. TSX (at least RTM part, I am not sure about HLE
part) still present in the latest Xeon generation, but is strongly de-emphasized.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>, [email protected] (Michael S) wrote:

How many transactions per minute does world's biggest company need
at peak hours?

One very painful case is credit card spending in the run-up to major
holidays, such as Christmas, where the credit card companies feel the
need for central authorisation of all transactions to reduce fraud. Fraud
is, naturally, at its peak at these times. The price of wrongly refused transactions is also high, because it means customers march out of shops, having wasted retail staff time.

Is not this number small relatively to capabilities of even 15 y.o.
dual-Xeon server with few dozens of spinning rust disks?

This does not seem to be the case.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 13:35 +0100 (BST)
[email protected] (John Dallman) wrote:

In article <[email protected]>,
[email protected] (Michael S) wrote:

How many transactions per minute does world's biggest company need
at peak hours?

One very painful case is credit card spending in the run-up to major holidays, such as Christmas, where the credit card companies feel the
need for central authorisation of all transactions to reduce fraud.
Fraud is, naturally, at its peak at these times. The price of wrongly
refused transactions is also high, because it means customers march
out of shops, having wasted retail staff time.

Is not this number small relatively to capabilities of even 15 y.o. dual-Xeon server with few dozens of spinning rust disks?

This does not seem to be the case.

John

My post was specifically about flight reservations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>, [email protected] (Michael S) wrote:

My post was specifically about flight reservations.

Ah, sorry. In that field, the airlines have found it best to collect into
large groups with shared reservation systems. If a travel agent has to
use a different system for each airline, then booking becomes very
inefficient and capacity gets wasted.

<https://en.wikipedia.org/wiki/Computer_reservation_system>

So there's real demand for systems with huge capacity. Not very many of
them, but they have large budgets.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/09/2024 21:06, David Schultz wrote:

On 9/11/24 4:40 AM, David Brown wrote:

The other reason, of course, was the name - "PIC" is associated with
brain-dead microcontrollers with terrible C tools and which many
people program in assembly.  They are also renowned for being very
solid, coming in relatively amateur-friendly packages, and for never
going out of production.

After having written code for a PIC I agree with "brain-dead". The small sized memory pages were bad enough but the total lack of an add with
carry instruction drove me mad.

If you pretend it is a sort of microcode rather than assembly, so that
you need several PIC assembly instructions to do the work of a single
assembly instruction on a "normal" 8-bit CISC microcontroller, it feels
less bad. And with enough complicated macros, it is possible to keep
paging a bit more under control and automated.

It also helps to use macros to give instructions better names - such as
"IfBit" and "IfNBit" rather than "btfsc" and "btfss". (The fact that I
can remember these after 25 years or so is a sign of the amount of
cognitive effort it took to work with these things!)

So I swore them off and the introduction of a MIPS based system did
nothing to change that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl wrote:

John Levine <[email protected]> writes:

According to Lawrence D'Oliveiro <[email protected]d>:

You solve that by having multiple units of the cheap machines to achieve >>> the same level of redundancy, or even more. That ends up being more cost- >>> effective than the mainframe.

That's fine for workloads that work that way.

Airline reservation systems historically ran on mainframes because
when they were invented that's all there was (original SABRE ran on
two 7090s) and they are business critical so they need to be very
reliable.

About 30 years ago some guys at MIT realized that route and fare
search, which are some of the most demanding things that CRS do, are
easy to parallelize and don't have to be particularly reliable -- if
your search system crashes and restarts and reruns the search and the
result is a couple of seconds late, that's OK. So they started ITA
software which used racks of PC servers running parallel applications
written in Lisp (they were from MIT) and blew away the competition.

However, that's just the search part. Actually booking the seats and
selling tickets stays on a mainframe or an Oracle system because
double booking or giving away free tickets would be really bad.

Booking flights or seats can easily be distributed: each flight is
assigned to one computer. To avoid double booking or free tickets
even in case of a computer crash, you use the usual transaction
processing approach, and report completion of the booking only when
the booking has reached persistent memory. For persistent memory you
use SSDs with power-loss protection.

These SSDs, ECC RAM, RAID-1, redundant power supplies and UPSs protect against most hardware failures, but availability is still a concern
(e.g., motherboard or CPU failure; that normally does not affect data integrity if the other measures are taken, but it affects
availability). To increase availability, you can use e.g., DRBD
(distributed replicated block device) to get the data on multiple
machines.

Concerning "real bad": Airlines overbook their flights as a matter of
policy to increase their revenue. If they had a booking system that double-booked, say, 1ppm of all bookings, they probably would not even notice, and would deal with it in the same way they deal with the
cases when the overbooking actually results in too many passengers
arriving for the flight. Likewise, free tickets are not an issue if
they occur rarely enough. Do they want to spend a million on a
mainframe to avoid a revenue loss of $100k? But in any case, that's
not the problem with cheap hardware.

You would not want the computer or agents overbooking randomly.
You would want this controlled by policy and done behind the agents
and customers back (or they would just cancel).

So overbooking is just another kind of normal transaction
and not an accident of fate.

The problems are: When the persistent storage fails, you lose all transactions since the latest backup. To avoid that, RAID-1 helps, or
a redundant distributed storage like DRBD, or a redundant distributed transaction system. You may also want more availability than a single
system with RAID-1 (with a spare system standing by) provides, then
you have to go for one of the redundant distributed approaches.

However, my impression from booking flights online is that reliability
of the booking platform is not at all a concern for the airlines. And
as a customer, I find little difference between the booking front-end erroring out or the transaction back-end being unavailable.

There's also a rule of thumb about databases that says one system of
performance 100 is much better than 100 systems of performance 1
because those 100 systems will spend all their time contending for
database locks.

If you handle each flight on one system, the contention for locks is
only within that one system. And I expect that there is not that much contention. How many people book the same flight within the same
millisecond (or however long the lock is held)?

Unlike debit/credit or stock trading transactions which are self contained,
the problem with airline reservation style transactions is they are
interactive in the middle and a traditional DB record/row locking
mechanism is insufficient.

In the interactive transaction case, to do this properly (I don't know
if airline systems actually do this) one needs to apply a timed reserve
lock to a 3-seat row to give the agent a chance to talk to the customer
and find out if the seat is acceptable. This creates a context that must
be maintained for a period of time.

Also typical SQL DB's do not have a way to read a row with lock
and fail if already locked. They stall the request, which is not
what you want a long duration interactive transaction to ever do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 9:22:17 +0000, Michael S wrote:

How many transactions per minute does world's biggest company need at
peak hours? Is not this number small relatively to capabilities of
even 15 y.o. dual-Xeon server with few dozens of spinning rust disks?

A SWAG::

8B people in the world: 1/3rd sleeping, 1/3rd working, 1/3rd relaxing.

So we have only 3B potential transactions, and a single person will
not average more than 1 transaction every 15 minutes over an hour.

So: 3B/15 = 200M T/m

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

They also care deeply about reliability. Modern mainframes have multiple kinds of error
checking and standby CPUs that can take over from a failed CPU, restart a failed
instruction, and the program doesn't notice. I think you'll find a pattern since the
CDC shock of making CPUs fast enough to keep the RAM and I/O devices busy while having
the error checking and recovery features so the systems keep running for years at a time.

shortly after joining IBM, I got pulled into effort to multithread
370/195 ... 195 didn't have branch prediction or speculative execution
so conditional branches drained pipeline and most codes ran at half
rated throughput. Two (simulated, "red/black") instruction streams
running at half speed would achieve rated throughput.

They also claimed that the main difference between 360/195 and 370/195
was introduction of ("370") hardware retry (masking all sorts of
transient hardware errors). Some vague recall mention that 360/195 mean
time between some hardware check was three hrs (combination of number of circuits and how fast they were running).

Then decision was made to add virtual memory to all 370s and it was
decided that the difficulty in adding virtual memory to 370/195 wasn't justified ... and all new work on machine was dropped.

Account of end of ACS/360 ... Amdahl had won the battle to make ACS, 360 compatible ... but folklore is then executives were afraid that it would advance state-of-the-art too fast and IBM would loose control of the
market ... includes some references to multithreading
patents&disclosures.
https://people.computing.clemson.edu/~mark/acs_end.html

also mentions some of ACS/360 features show up more than 20yrs later
with ES/9000.

--
virtualization experience starting Jan1968, online at home since Mar1970

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

I suppose. A review from the USDOE said:

The IBM 3090 with Vector Facility is an extremely interesting machine
because it combines very good scaler performance with enhanced vector
and multitasking performance. For many IBM installations with a large
scientific workload, the 3090/vector/MTF combination may be an ideal
means of increasing throughput at minimum cost. However, neither the
vector nor multitasking capabilities are sufficiently developed to
make the 3090 competitive with our current worker machines for our
large-scale scientific codes.

1st part of 70s, IBM had FS effort, was totally different than 370
and was to completely replace 370 (internal politics was killing
off 370 efforts).
http://www.jfsowa.com/computer/memo125.htm

when FS finally implodes, there is a mad rush to get stuff back into the
370 product pipelines, including kicking off 3033&3081 efforts in
parallel.

I got sucked into work on 16-processor 370 SMP and we con the 3033
processor engineers into working on it in their spare time (lot more interesting that remapping 168 logic for 20% faster chips). Everybody
thot it was great until somebody tells the head of POK lab that it could
be decades before the POK favorite son operating system (batch MVS) has (effective) 16-processor support (at the time MVS documentation claimed
that its 2-processor throughput had 1.2-1.5 times the throughput of
single process). The head of POK then invites some of us to never visit
POK again and the 3033 processor engineers, heads down and no
distractions (although I was invited to sneak back into POK to work with
them). POK doesn't ship a 16-processor machine until after the turn of
the century, more than two decades later.

Once the 3033 was out the door, the processor engineers start on
trout/3090. When vector was announced they complained about it being
purely marketing stunt ... that they had so speeded up 3090 scalar that
it ran at memory bus saturation (and vector would unlikely make
throughput much better).

I had also started pontificating the relative disk throughput had gotten
an order of magnitude slower (disks got 3-5 times faster while systems
got 40-50 times faster) since 360 announce. Disk division executive took exception and directed division performance group to refute the claims,
after a couple weeks they came back and said I had slightly understated
the problem. They respun the analysis on how to configure disks to
improve system throughput for a user group presentation (16Aug1984,
SHARE 63, B874).

I was doing some work with disk engineers and that they had been
directed to use a very slow processor for the 3880 disk controller
follow-on to the 3830 ... while it handled 3mbyte/sec 3380 disks, it
otherwise seriously drove up channel busy. 3090 originally assumed that
3880 would be like previous 3830 but with 3mbyte/sec transfer ... when
they found out how bad things actually was, they realized they would
have to seriously increase the number of (3mbyte/sec) channels (to
achieve target throughput). Marketing then respins the significant
increase in channels as being wonderful I/O machine. Trivia: the
increase in channels required an extra TCM and the 3090 group
semi-facetiously claimed they would bill the 3880 group for increase in
3090 manufacturing cost.

I was also doing some work with Clementi https://en.wikipedia.org/wiki/Enrico_Clementi
E&S lab in IBM Kingston ... had boatload of Floating Point Systems boxes https://en.wikipedia.org/wiki/Floating_Point_Systems
that had 40mbyte/sec disk arrays for keeping the FPS boxes fed.

In 1980, I had been con'ed into doing channel-extender implementation
for IBM STL (since renamed SVL), they were moving 300 people and 3270
terminal to offsite bldg with dataprocessing back to STL datacenter.
They had tried "remote 3270" but found human factors unacceptable. Channel-extender allowed "channel-attached" 3270 controllers to be place
at offsite bldg with no human factors difference between offsite and in
STL. Side-effect was that it increased system throughput by 10-15%. They
had previously spread 3270 controllers across all the same channels with
disks, the channel-extender work significantly reduced 3270 terminal I/O channel busy, increasing disk I/O and system throughput (they were
considering moving all 3270 controllers to channel-extender, even those physically inside STL. Then there was attempt to my support released to customers, but there was group in POK playing with some serial stuff
that get it vetoed, they were afraid if it was in the market, it would
make it harder to release their stuff.

In 1988, the IBM branch office asks if I could help LLNL get some serial
stuff they were playing with, standardized ... which quickly becomes fibre-channel standard ("FCS", initially 1gibt/sec, full-duplex,
aggregate 200mbyte/sec). The POK serial stuff finally gets released in
the 90s with ES/9000 as ESCON (when it is already obsolete,
17mbytes/sec). Then some POK engineers become involved with FCS and
define a heavy-weight protocol that significantly reduces throughput, eventually released as FICON. The latest, public benchmark I've found is
z196 "Peak I/O", getting 2M IOPS using 104 FICON. About the same time, a
FCS is announced for E5-2600 blade claiming over million IOPS (two such
FCS has higher throughput than 104 FICON). Also IBM docs had SAPs
(system assist processors that do actual I/O) kept to 70% cpu (more like
1.5M IOPS), also no IBM CKD DASD have been made for decades all being
simulated on industry standard fixed-block disks.

--
virtualization experience starting Jan1968, online at home since Mar1970

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terje Mathisen <[email protected]> writes:

Novell's System Fault Tolerant NetWare 386 (around 1990) supported two complete servers acting like one, so that any hardware component could
fail and the system would keep running, with nothing noticed by the
clients, even those that were in the middle of an update/write
request.

late 80s, get HA/6000 project, originally for NYTimes to move their
newspaper system (ATEX) off VAXCluster to RS/6000. I then rename it
HA/CMP when I start doing technical/scientific scale-up with national
labs and commercial scale-up with RDBMS vendors (Oracle, Sybase,
Informix, Ingres) that had VAXCluster support in same source base with
Unix (I do distributed lock manager that supported VAXCluster semantics
to ease ports). https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_Multiprocessing

IBM had been marketing S/88, rebranded fault tolerant. Then the S/88
product administer starts taking us around to their customers. https://en.wikipedia.org/wiki/Stratus_Technologies
Also has me write a section for the corporate continuous availability
strategy document ... however, it gets pulled when both Rochester
(AS/400, I-systems) and POK (mainframe) complain that they couldn't meet
the requirements.

Early Jan92 in meeting with Oracle CEO, AWD/Hester tells Ellison that we
would have 16processor clusters by mid92 and 128processor clusters by
ye92. Within a couple weeks (end jan92), cluster scale-up is transferred
for announce as IBM Supercomputer (scientific/technical *ONLY*) and we
are told we can't work on anything with more than four processors (we
leave IBM a few months later).

--
virtualization experience starting Jan1968, online at home since Mar1970

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

That's fine for workloads that work that way.

Airline reservation systems historically ran on mainframes because when they were invented
that's all there was (original SABRE ran on two 7090s) and they are business critical so
they need to be very reliable.

About 30 years ago some guys at MIT realized that route and fare search, which are some of
the most demanding things that CRS do, are easy to parallelize and don't have to be
particularly reliable -- if your search system crashes and restarts and reruns the search
and the result is a couple of seconds late, that's OK. So they started ITA software which
used racks of PC servers running parallel applications written in Lisp (they were from
MIT) and blew away the competition.

However, that's just the search part. Actually booking the seats and selling tickets stays
on a mainframe or an Oracle system because double booking or giving away free tickets would
be really bad.

There's also a rule of thumb about databases that says one system of performance 100 is
much better than 100 systems of performance 1 because those 100 systems will spend all
their time contending for database locks.

after leaving IBM was brought into largest airline res system to look
ten impossible things they can't do. Got started with "ROUTES" (about
25% of the mainframe workload), they gave me a full softcopy of OAG (all scheduled commercial flt segments in the world) ... couple weeks later
came back with ROUTES that implemented their impossible things.
Mainframe had tech trade-offs from the 60s and started from scratch
could make totally different tech trade-offs, initially ran 100 times
faster, then implementing the impossible stuff and still ran ten times
faster (than their mainframe systems). Showed that ten rs6000/990 could
handle workload for every flt and every airline in the world.

Part of the issue was that they extensively massaged the data on a
mainframe MVS/IMS system and then in sunday night, rebuilt the mainframe
"TPF" (limited datamanagement services) system from the MVS/IMS
system. That was all eliminated.

Fare search was harder because it started being "tuned" by some real
time factors.

Could move all to RS/6000 - HA/CMP. Then some very non-technical issues kicked-in (like large staff involved in the data massaging). trivia: I
had done a bunch of slight of hand for HA/CMP RDBMS distributed lock
manager scaleup for 128-processor clusters.


--
virtualization experience starting Jan1968, online at home since Mar1970

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> schrieb:

On Fri, 13 Sep 2024 11:20:06 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:

Terje Mathisen <[email protected]> schrieb:

10-15 years ago I talked to another speaker at a conference, he
told me that he was working on high-end open source LDAP software
using _very_ large memory DBs: Their system allowed one US cell
phone company to keep every SIM card (~100M) on a single system,
while a similar-size competitor had been forced to fall back on
17-way sharding (presumably using a hash of the SIM id).

Keeping databases in memory is definitely a thing now... see SAP HANA.

Any architectural implications for this?

Browsing through the SAP pages, it seems they used Intel's Optane
persistent memory, but that is no longer manufactured (?). But
having fast, persistent storage is definitely an advantage for
databases.

Large memory: Of course.

On the ISA level... these databases run on x86, so that seems to
be good enough.

Anything else?

Another thing that SAP HANA seems to use more intensely than anybody
else is Intel TSX. TSX (at least RTM part, I am not sure about HLE
part) still present in the latest Xeon generation, but is strongly de-emphasized.

Sounds like a market niche... Mitch, how good is your ESM for
in-memory databases?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 09:05:33 -1000, Lynn Wheeler wrote:

I had also started pontificating the relative disk throughput had gotten
an order of magnitude slower (disks got 3-5 times faster while systems
got 40-50 times faster) since 360 announce.

Out of curiosity, did you have figures on how closely the filesystem could
get to using all of theoretical disk I/O bandwidth?

I ask because, in the Unix world, this was pretty terrible until
Berkeley’s FFS (“Fast File System”) came along.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It appears that Michael S <[email protected]> said:

There's also a rule of thumb about databases that says one system of
performance 100 is much better than 100 systems of performance 1
because those 100 systems will spend all their time contending for
database locks.

How many transactions per minute does world's biggest company need at
peak hours?

Ten years ago Visa could process 56,000 messages/second. It must be a
lot more now. I think a transaction is two or four messages depending
on the transaction type.

Is not this number small relatively to capabilities of
even 15 y.o. dual-Xeon server with few dozens of spinning rust disks?

Uh, no, it is not.


--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 21:43:06 +0000, Thomas Koenig wrote:

Michael S <[email protected]> schrieb:

On Fri, 13 Sep 2024 11:20:06 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:

Anything else?

Another thing that SAP HANA seems to use more intensely than anybody
else is Intel TSX. TSX (at least RTM part, I am not sure about HLE
part) still present in the latest Xeon generation, but is strongly
de-emphasized.

Sounds like a market niche... Mitch, how good is your ESM for
in-memory databases?

I do not think the in-memory part has anything to do with ESM
ATOMIC behavior.

I have no actual data, all I have is mental analyses.

The real think about ESM is that it allows one to code in such a way
as to need FEWER ATOMIC events--because each event can do more work;
so, thereby one needs fewer events.

1) You can acquire several cache lines and perform a single event
that would take a more typical ISA multiple ATIMOIC instructions.
This attacks the exponent of how rapidly things degrade under
contention.

2) secondly if a higher privilege thread contends with a lower thread
the higher privileged thread wins.

3) amongst equally privileged threads the one(s) that have made more
forward progress succeed while those just getting started fail.

4) There are ways for SW to get a count of the amount of interference
and each thread choose more wisely such that contention is reduced
on subsequent tries. There are some ATOMIC things for which this takes
a BigO( n**3 ) and makes it BigO( 3 ) {yes constant time}. A more
typical; use with new contenders coming and going randomly goes from
BIgO( n**3 ) to between BigO( n*ln(ln(n)) ) and BigO( n*ln(n) ).

HOWEVER:: if one uses ESM to simply implement locking behavior; only
part 1) above applies. That is if one uses ESM to create you standard {test&set, test*test*set, LoadLocked-StoreCOnditional, CAS, DCAS,
DCADS, TCADS,...} to get a performing kernel that depends on how
the SW is written, not necessarily how HW performs ESM.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 12:22:17 +0300, Michael S wrote:

How many transactions per minute does world's biggest company need at
peak hours?

A few years ago, I read an article about Facebook’s setup. At the time,
they had about a billion users who were active at least once a month. So
that would have been over 300 postings per second, sustained.

They were using MySQL with memcached, and I think they already had HHVM
(their custom PHP implementation) then as well.

Mainframes? Never heard of them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 11:20:06 -0000 (UTC), Thomas Koenig wrote:

Keeping databases in memory is definitely a thing now... see SAP HANA.

memcached might have been there before SAP.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 16:18 +0100 (BST), John Dallman wrote:

So there's real demand for systems with huge capacity. Not very many of
them, but they have large budgets.

Did somebody say “cloud” ... ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

It appears that Michael S <[email protected]> said:

There's also a rule of thumb about databases that says one system of
performance 100 is much better than 100 systems of performance 1
because those 100 systems will spend all their time contending for
database locks.

How many transactions per minute does world's biggest company need at
peak hours?

Ten years ago Visa could process 56,000 messages/second. It must be a
lot more now. I think a transaction is two or four messages depending
on the transaction type.

Is not this number small relatively to capabilities of
even 15 y.o. dual-Xeon server with few dozens of spinning rust disks?

Uh, no, it is not.

The way I would design this for a machine with that little IOPS is as
an in-memory database, with transactions written to a log on RAID-1
(on two or three of the HDDs), and a snapshot of the in-memory
database written to disk repeatedly, with copy-on-write to get a
consistent snapshot. The 8 cores of a 2009-vintage the dual-Xeon
machine should be easily capable of doing it, but the question is if
the machine has enough RAM for the database. Our dual-Xeon system
from IIRC 2007 has 24GB of RAM, not sure how big it could be
configured; OTOH, we have a single-Xeon system from 2009 or so with
32GB of RAM (and there were bigger Xeons in the market at the time).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl <[email protected]> schrieb:

[in-memory database]

but the question is if
the machine has enough RAM for the database. Our dual-Xeon system
from IIRC 2007 has 24GB of RAM, not sure how big it could be
configured; OTOH, we have a single-Xeon system from 2009 or so with
32GB of RAM (and there were bigger Xeons in the market at the time).

The minimum requirement of SAP HANA is 64 GB of memory, but typical
ranges are from 256GB to 1TB.

Interestingly enough, it will run on selected systemw, which only
have Intel processors, and little-endian POWER 8 to 10. No AMD,
no ARM, no zSystem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 21:50:15 -0000 (UTC), John Levine wrote:

Ten years ago Visa could process 56,000 messages/second.

That maybe sounds better than it is. After all, most of those transactions would tend to be geographically localized.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig <[email protected]> writes:

Anton Ertl <[email protected]> schrieb:

[in-memory database]

but the question is if
the machine has enough RAM for the database. Our dual-Xeon system
from IIRC 2007 has 24GB of RAM, not sure how big it could be
configured; OTOH, we have a single-Xeon system from 2009 or so with
32GB of RAM (and there were bigger Xeons in the market at the time).

The minimum requirement of SAP HANA is 64 GB of memory, but typical
ranges are from 256GB to 1TB.

What is the relevance of SAP HANA for the topic at hand?

The question was if the RAM can hold the data. For each account they
would have to keep the current balance (64 bits should be enough for
that), the account number (64 bits for the up to 19 digits of a Visa
card) for verifying that we are at the correct entry in the hash table
and probably some account status information (64 bits should be
plenty?).

There is also the sequence of transactions (a 64-bit transaction
offset in the log per transaction should be enough for that). The
sequence of transactions may be useful for fraud detection, but I
don't know enough about that to know how to scale the system, so I'll
just say that fraud detection is done by a bigger system before the
transaction goes through to the transaction processing computer.

The sequence of transactions is also needed for generating the reports
and for dealing with customer complaints, but again, that's not
processing the transactions themselves (and is basically read-only,
except that the customer-complaint processing may result in additional transactions).

So, with 24 bytes needed for each account on the
transaction-processing server, 32GB with, say 8GB left for
copy-on-write and other administrative purposes should be good for
about 900M accounts at a hash table load factor of 84%. I guess that
Visa has more accounts, so one would need a box with more RAM.

A single core of the Xeon should easily be able to handle all the 56K transactions per second, both the logging and the update of the hash
table, and in that case no locking is needed. But that first needs a
sequence of transactions coming in.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl <[email protected]> schrieb:

Thomas Koenig <[email protected]> writes:

Anton Ertl <[email protected]> schrieb:

[in-memory database]

but the question is if
the machine has enough RAM for the database. Our dual-Xeon system
from IIRC 2007 has 24GB of RAM, not sure how big it could be
configured; OTOH, we have a single-Xeon system from 2009 or so with
32GB of RAM (and there were bigger Xeons in the market at the time).

The minimum requirement of SAP HANA is 64 GB of memory, but typical
ranges are from 256GB to 1TB.

What is the relevance of SAP HANA for the topic at hand?

It is something that is implemented, unlike what you were discussing.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig <[email protected]> writes:

Anton Ertl <[email protected]> schrieb:

Thomas Koenig <[email protected]> writes:

The minimum requirement of SAP HANA is 64 GB of memory, but typical >>>ranges are from 256GB to 1TB.

What is the relevance of SAP HANA for the topic at hand?

It is something that is implemented, unlike what you were discussing.

So what? Linux is also implemented, and it runs on a 32GB machine.

Neither Linux nor SAP HANA satisfy even the most basic requirement
that I outlined (keeping balances) without additional implementation
work. And I doubt that if you give a 15 year old Dual-Xeon even with
64GB of RAM and a bunch of HDDs to a typical SAP developer, he will
implement a system that manages to keep the balance on 1.8M (double
the number for double RAM capacity) credit cards at 56K transactions
per second on that system. What I described is relatively
straightforward to implement on top of Linux.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (Anton Ertl) writes:

Thomas Koenig <[email protected]> writes:

Anton Ertl <[email protected]> schrieb:

Thomas Koenig <[email protected]> writes:

The minimum requirement of SAP HANA is 64 GB of memory, but typical >>>>ranges are from 256GB to 1TB.

What is the relevance of SAP HANA for the topic at hand?

It is something that is implemented, unlike what you were discussing.

So what? Linux is also implemented, and it runs on a 32GB machine.

Neither Linux nor SAP HANA satisfy even the most basic requirement
that I outlined (keeping balances) without additional implementation
work. And I doubt that if you give a 15 year old Dual-Xeon even with
64GB of RAM and a bunch of HDDs to a typical SAP developer, he will
implement a system that manages to keep the balance on 1.8M (double
the number for double RAM capacity) credit cards at 56K transactions
per second on that system. What I described is relatively
straightforward to implement on top of Linux.

That should be 1.8G credit cards. I guess that a typical SAP HANA
client developer will be able to handle 1.8M credit cards in 64GB.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 17:05:35 +0000
[email protected] (MitchAlsup1) wrote:

On Fri, 13 Sep 2024 9:22:17 +0000, Michael S wrote:

How many transactions per minute does world's biggest company need
at peak hours? Is not this number small relatively to capabilities
of even 15 y.o. dual-Xeon server with few dozens of spinning rust
disks?

A SWAG::

8B people in the world: 1/3rd sleeping, 1/3rd working, 1/3rd relaxing.

So we have only 3B potential transactions, and a single person will
not average more than 1 transaction every 15 minutes over an hour.

So: 3B/15 = 200M T/m

I don't know about you, but I personally don't book flights 8 hours per
day. Even less so in the biggest company in the world, which, I
suppose, does not account for more tha 5-7% of world's flights.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 21:50:15 -0000 (UTC)
John Levine <[email protected]> wrote:

It appears that Michael S <[email protected]> said:

There's also a rule of thumb about databases that says one system
of performance 100 is much better than 100 systems of performance 1
because those 100 systems will spend all their time contending for
database locks.

How many transactions per minute does world's biggest company need at
peak hours?

Ten years ago Visa could process 56,000 messages/second. It must be a
lot more now. I think a transaction is two or four messages depending
on the transaction type.

Is not this number small relatively to capabilities of
even 15 y.o. dual-Xeon server with few dozens of spinning rust
disks?

Uh, no, it is not.

I probably was not clear enough. I have no doubts that there exist jobs
for which the machine that I mentioned above is insufficient.
I just don't believe that flight reservation is one of such jobs.

BTW, tcp.org site is down, so I can not find OLTP bechmarks for the
sort of machines that I mentioned in my previus post. Quite possibly
they (scores) do not exsit, because in 2009 people already stopped
benchmarking OLT with rotating media.
For reference, the best TPC-C score for 2-way Xeon in 2010 is 803,068
tpmC, but that score uses SSDs. IIRC, that's ~80% of the world's
absolutely fastest non-clustered score of 2003.

I am posting a link with a hope that tcp.org will be up tomorrow. http://www.tpc.org/results/individual_results/HP/hp_DL380_TPCC_051110_ES.pdf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Sep 2024 19:17:51 +0000, Michael S wrote:

On Fri, 13 Sep 2024 17:05:35 +0000
[email protected] (MitchAlsup1) wrote:

On Fri, 13 Sep 2024 9:22:17 +0000, Michael S wrote:

How many transactions per minute does world's biggest company need
at peak hours? Is not this number small relatively to capabilities
of even 15 y.o. dual-Xeon server with few dozens of spinning rust
disks?

A SWAG::

8B people in the world: 1/3rd sleeping, 1/3rd working, 1/3rd relaxing.

So we have only 3B potential transactions, and a single person will
not average more than 1 transaction every 15 minutes over an hour.

So: 3B/15 = 200M T/m

I don't know about you, but I personally don't book flights 8 hours per
day. Even less so in the biggest company in the world, which, I
suppose, does not account for more tha 5-7% of world's flights.

An number for which total number of transactions of all kinds world
wide will not be exceeded by a total population of 8B people.
{Not just airline, but every transaction over the whole world.}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

Ten years ago Visa could process 56,000 messages/second. It must be a
lot more now. I think a transaction is two or four messages depending
on the transaction type.

card associations were originally to promote brand acceptance/uptake/advertising and network interconnecting the acquiring/merchant card transaction processors with the issuing/consumer
card transaction processors (issuer processor doing the real-time authorization/"auth" transaction).

late 90s, internet/micropayments was looking at card transaction
processors being able to handle micropayments ... but required
singnificantly higher transaction rate than card processors were capable
off. They turn to cellphone operations that were using "in-memory" DBMS
capable of ten times the transaction rate (that card processors were
doing).

Some of the cellphone companies were enticed to get into micropayments
but got out after a few years, turns out they lacked the significant
fraud handling capability (they were absorbing cellphone calling fraud
because it was their own resources, but in case of micropayments fraud,
it involved actually transferring real money to other entities).

As an side, card association interconnect network was flavor of VAN
(value added networks) that was prevalent at the time, but were in the
process of of being obsoleted by the internet. As an side, at the turn
of the century, 90% of all acquiring&issuing card transactions were
being handled by six datacenters having their own private, dedicated, non-association interconnect ... big litigation between card
associations and those processors (the card association network had been charging fee for each transaction that flowed through their network, and association still wanted that fee paid them whether or not the
transaction actually flowed their network.

--
virtualization experience starting Jan1968, online at home since Mar1970

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 15 Sep 2024 0:40:31 +0000, Lawrence D'Oliveiro wrote:

On Sat, 14 Sep 2024 10:57:57 -1000, Lynn Wheeler wrote:

Some of the cellphone companies were enticed to get into micropayments
but got out after a few years, turns out they lacked the significant
fraud handling capability ...

Meanwhile, the Kenyans have figured out how to run a successful online micropayments system mediated via text messages (M-Pesa).

Another reason not to have ANY apps on your cell phone.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Sep 2024 10:57:57 -1000, Lynn Wheeler wrote:

Some of the cellphone companies were enticed to get into micropayments
but got out after a few years, turns out they lacked the significant
fraud handling capability ...

Meanwhile, the Kenyans have figured out how to run a successful online micropayments system mediated via text messages (M-Pesa).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Lawrence D'Oliveiro <[email protected]d>:

Some of the cellphone companies were enticed to get into micropayments
but got out after a few years, turns out they lacked the significant
fraud handling capability ...

Meanwhile, the Kenyans have figured out how to run a successful online >micropayments system mediated via text messages (M-Pesa).

M-pesa isn't micropayments, typical transfers are on the order of
a dollar. It was only possible because there was a dominant
government owned mobile mobile carrier in Kenya and M-Pesa is
basically sending around prepaid mobile phone credits.

It is certainly a success, providing banking services to vast numbers
of poor people who'd never be able to use a normal bank.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

before and after turn of century we would periodically have threads on
the "bank fraud blame game" (in financial industry mailing lists);
interchange fees that financial institutions charge merchants is base
plus fraud surcharge ... adjusted for the fraud rate for kind of
transactions .... internet transactions can have highest surcharge (with
many banks' profit from fraud surcharge reaching major percentage of
their bottom line)

right after turn of century, several "safe" transaction products were
presented to major online merchants (representing 80% of total internet
payment transactions) which saw high acceptance ... expecting that the
fraud surcharge would be eliminated. Then the cognitive dissonance set
in, they were told that instead of eliminating the fraud surchanged, a
new large "safe" surcharge would be added on top of the existing fraud surchange ... and all the interest evaporated.

I had co-authored financial industry transaction protocols as well as
done "safe" transaction chip design (that was one of the "safe"
products) ... was one of panel giving talk at standing room only large ballroom, semi-facetiously saying I was taking $500 milspec chip and aggresively cost reducing by more than two orders of magnitude while
increasing its security: https://csrc.nist.gov/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final
got prototype chips after turn of the century and gave talk in assurance
panal in the trusted computing tract at 2001 IDF https://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp%2bs13
the guy running trusted-computing TPM chip was in front row and I chided
him that it was nice to see his chip was starting to look more like
mine; his response was that I didn't have a committee of 200 people
helping me with design.

--
virtualization experience starting Jan1968, online at home since Mar1970

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Anton Ertl <[email protected]> wrote:

Brett <[email protected]> writes:

Speaking of complex things, have you looked at Swift output, as it checks >>all operations for overflow?

You could add an exception type for that, saving huge numbers of correctly >>predicted branch instructions.

The future of programming languages is type safe with checks, you need to >>get on that bandwagon early.

MIPS got on that bandwagon early. It has, e.g., add (which traps on
signed overflow) in addition to addu (which performs modulo
arithmetic). It has been abandoned and replaced by RISC-V several
years ago.

Alpha got on that bandwagon early. It's a descendent of MIPS, but it
renamed add into addv, and addu into add. It has been canceled around
the year 2000.

[ More details about architectures without trapping overflow instructions ]

Trapping on overflow is basically useless other than as a debug aid,
which clearly nobody values. If you take Rust's approach, and only
detect overflow in debug builds, then you already don't care about
performance.

If you want to do almost anything at all other than core dump on
overflow, you need to branch to recovery code. And although it's
theoretically possible to recover from the trap, it's worse than any
other approach. So it's added hardware that's HARDER for software to
use. No surprise it's gone away.

IA64 went down this road--trapping on speculation failures. It was a
huge disaster--trying to recover through an exception handler mechanism
is slow and painful, for the reasons I'll lay out for overflow
exceptions.

Let's look at how you might want to handle overflows when they happen:

1) Your language supports seemlessly transitioning to BigInts on
overflow. Then each operation that could overflow needs to call
a special bit of code to change to BigInt and then continue the
calculation. This code must exist, even if a trapping
instruction doesn't need an explicit branch to it. Some
mechanism is needed to call this code.

2) You need to call an exception handler, and the routine with the overflow
is ended. We need to know which exception handler to call.

3) You want to clamp the value to a reasonable range and continue. The
reasonable values need to be looked up somewhere.

4) You just want to crash the program. If a debugger is attached, it can
say where the overflow occurred.

Trapping on overflow instructions really are only useful for #4. Let's
look at how the other cases could be handled, with a) meaning using
branches, and b) mean using a trapping instruction.

1a) (BigInt): After doing an operation which could overflow, use a
conditional branch to jump to code to convert to BigInt, which
then jumps back. Overhead is basically the branch-on-overflow
instruction.

1b) (BigInt with traps). Hardware traps to the OS, which needs to prepare
the required structures describing the exception (all regs and
the address), and then call the signal handler. The signal
handler needs to look up the address of the trap with a table
describing what to do for this particular operation which
overflowed. Each table entry needs to describe, in detail, what
registers are involved (the sources and the dest), and where to
return once the BigInt has been created. This requires massive
changes to the compiler (and possibly linker) to prepare these
tables. The compiler must guarantee that changing the dest
register to a pointer to BigInt works properly (otherwise,
special code needs to be emitted for each potentially trapping
instruction to try to recover).

2a) (Try/Catch): After doing an operation which could overflow, use a
conditional branch to jump to the catch block.

2b) (Try/Catch with traps). Repeat all the OS work and call the signal
handler. Now, it just needs a table entry describing where to
jump to to enter the catch block. Almost all the complexity of
1b), but without needing the register details.

3a) (Clamp): After doing an operation which could overflow, use a
conditional branch to do the MIN/MAX operations to bring it back
within range and then jump back.

3b) (Clamp with trap): Basically the same as 1b), but there's an alternative
if the clamps are global (MAX_INT/MIN_INT). The exception handler
can read the instruction which trapped, figure out the source and
dest registers, re-do the calculation, and clamp the destination
to MIN or MAX, and return to just after the instruction which
trapped.

4a) (Crash): Every operation could overflow needs a conditional branch
after it to branch to a crashing instruction (or a branch over
an undefined instruction if there's no overflow).

4b) (Crash with trap): Use operations which trap on overflow. This takes
no new instructions and costs no performance.

Basically, all a) cases are:

op_with_might_overflow();
if(overflow_happened) {
handle the overflow
}

Trapping-on-overflow instructions are clearly useless for languages
which care about overflow. To save one branch instruction, an entry is
needed to describe how to handle the overflow, which is certainly larger
than a branch instruction. And the code to "handle the overflow" is
needed in any case. And this assume some sort of instant lookup--of the
1000 overflow instructions, we need a hash table to look up the address,
which is more overhead.

Trapping on overflow instructions are useful as a debug aid for
languages which don't care about overflow--but then you're optimizing
something nearly useless. It also might be helpful if global clamping
to MIN/MAX was useful (and I don't think it is).

Instruction sets which make detecting overflow difficult (say, RISC-V),
would do well to make branch-on-overflow efficient and easy. But adding trap-on-overflow instructions is a waste of effort.

Note that using traps on data access violations which are "fixed" by
signal handlers CAN work out. They are slow, but as long as the
exception handler can fix the access violation and return right to the instruction which failed (without needing to know ANYTHING about that instruction in particular), this can work fine. But integer overflow
doesn't work like that--it's generally not possible to figure out
in the trap handler what to do without more information.

Kent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Sep 2024 18:35:26 +0000, Kent Dickey wrote:

In article <[email protected]>,

Alpha got on that bandwagon early. It's a descendent of MIPS, but it >>renamed add into addv, and addu into add. It has been canceled around
the year 2000.

[ More details about architectures without trapping overflow
instructions ]

Trapping on overflow is basically useless other than as a debug aid,
which clearly nobody values. If you take Rust's approach, and only
detect overflow in debug builds, then you already don't care about performance.

If you want to do almost anything at all other than core dump on
overflow, you need to branch to recovery code. And although it's theoretically possible to recover from the trap, it's worse than any
other approach. So it's added hardware that's HARDER for software to
use. No surprise it's gone away.

Note: Linux does not even have an "Integer Overflow" signal, while
it does have a "FP exception" signal.

But then IEEE 754 exception semantics make even less sense than
Linux signals. ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Sep 2024 22:00:28 +0000, MitchAlsup1 wrote:

But then IEEE 754 exception semantics make even less sense than Linux signals. ...

Note that what IEEE 754 calls an “exception” is just a bunch of status
bits reporting on the current state of the computation: there is no
implication of some transfer of control elsewhere.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Sep 2024 18:35:26 -0000 (UTC), Kent Dickey wrote:

3) You want to clamp the value to a reasonable range and continue. The
reasonable values need to be looked up somewhere.

This won’t work. The values outside the range are by definition non- representable, so comparisons against them are useless.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 21 Sep 2024 1:09:43 +0000, Lawrence D'Oliveiro wrote:

On Fri, 20 Sep 2024 22:00:28 +0000, MitchAlsup1 wrote:

But then IEEE 754 exception semantics make even less sense than Linux
signals. ...

Note that what IEEE 754 calls an “exception” is just a bunch of status bits reporting on the current state of the computation: there is no implication of some transfer of control elsewhere.

Then how do you implement the alternate exception model ???
which IS part of 754-2008 and 754-2019

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)