John Levine wrote:
> According to Anne & Lynn Wheeler <lynn@garlic.com>:
>> Two months later, came back with routes reimplemented in "C" from
>> scratch, demo'ed on rs/6000 320 where they put it through paces ...
>> different complex origin/destination combinations that the existing
>> implementations couldn't handle. workload profiles showed that ten (rack
>> mount) rs/6000 990s could handle all route requests for all airlines in
>> the world.
>
> Sounds a lot like what ITA did. Since route lookups are read-only, you
> can run a lot of stuff in parallel without locks.

Right, that's not even hard. :-)

The company I worked for at one point in time had the contract from the
Norwegian IRS to run the national social security number database.
(Please note that this DB was in fact owned by the IRS and not by the
obvious (?) social security department.)

Anyway, up to the point when I was asked to look into our bid for the
next 5-year period, these contracts had effectively requires running on
an IBM mainframe since several SNA/3270 protocols/API were required, but
the next one would not have this limitation so I was free to see what I
could do for a DB of maximum 7M records, each with not more than 1 KB of
data, so less than 8GB of primary data.

A pair of 64-bit workstation-class machines with 32 GB of RAM would
suffice to keep the entire DB, including all secondary tables and
indices, in memory. All updates were specified to happen via a daily
(i.e. nightly) bulk process so maintaining consistency was also trivial.

Except for the police which has an custom wild card search interface
available (but with extra logging so that it could be verified that this
happened due to an active investigation), every request would be single
record lookups.

Result: The pair (or more, geographically distributed?) of redundant
servers would be able to handle a couple of orders of magnitude more
traffic than the old mainframe DB solution, with sub-us processing time,
i.e. they would run at wire speed of the fastest network available.

Total cost for the required hw and for sw development could be recovered
in a few months compared to the old contract.

Terje

PS. Today I would probably have specified using a Foundation DB as the
repository instead of a totally custom setup.

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

John Levine wrote:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>>> it was that SAP they were referring to, for which Odoo was pitched
>>> as a replacement.
>>
>> ERP software is not a small market. SAP had an anuall turnover
>> of 27.8e9 Euros in 2021 (around 30 Gigadollars).
>
> According to Wikipedia, SAP is the #4 software company in the world after
> Microsoft, IBM, and Oracle. They have long been the biggest European
> computer company.
>

Didn't they use to be #2 for a while, i.e. following Microsoft?

(Back when IBM was a HW company and Oracle sold nothing but Oracle DB)

Terje

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

John Levine <johnl@taugh.com> writes:
>There are new banks and new airlines. If they could do their banking and
>flying on cheap racks of PCs, don't you think they would?

Not necessarily. For each individual company, it can be cheaper to
rent a mainframe and start with established software that handles all
the tax, money laundering etc. regulations rather than starting from
scratch, with lots of companies (IBM, the software companies, and
competing banks) around that will do their utmost to crucify you for
every mistake; and even if you don't make a mistake, everybody else
will tell their customers about your new bank that cannot even afford
proper banking computers. There are probably also network effects at
work that make it hard to break out of the established system.

>I can't find the reference now, but in the database biz people know
>that ten computers of speed X are not equivalent to one of speed 10X

Everybody knows that. It's Amdahl's law. But we are not talking
about ten computers of speed X and one with speed 10X here, we are
talking about several computers with up to 128 cores (if we take a
dual-socket EPYC system; but if you get the distributed software
right, it may be cheaper to use more smaller systems) against one
computer with up to about 240 cores that costs maybe 10x as much; the
cores themselves have little speed difference.

And since you mention per-bank systems, the whole stuff is distributed
anyway: the ATM is situated at one bank (or belongs to one ATM
company), the user's account often at a different one, they have to do
transactions on each bank's computers.

Credit card processing may be more centralized, because there are a
few (or, in Europe, basically one) credit card company, and each
credit card holder and (I presume) each dealer that accepts the card
has an account there, so this can be done within a single system. But
given that you do it in a distributed way for ATM transactions and
money transfers, you can also do it in a distributed way for credit
card payments, if you want to.

>exactly because of the lock contention.

But that's the point I am trying to get across: For the kind of
transactions mentioned here, lock contention is no problem:

1) Nearly all accounts don't do thousands of transactions per second;
and for those that do (say, Amazon's account at Visa or somesuch), you
can split it into multiple accounts if necessary (but I doubt that it
is necessary even for Amazon's volume if the software is written
accordingly).

2) Also, you don't need to hold locks on both accounts involved. The
classic way (from before computing) of money transfer is that the
sending account's bank is taking the money off the one account, sends
it over to the receiving account's bank, and the receiving bank puts
the money into the receiving account. [In the old days there were
IIRC three days when the money was on the way. The banks kept this
timespan up far into the computer age, because it was in their balance
during that time (and produced interest while interest rates were >0),
and it took some regulations for bringing that down to IIRC one day
relatively recently.] You can use the same principle for distributed
computerized credit-card processing or ATM processing.

>You can parallelize a lot, and
>they do parallelize a lot, but at some point, there are atomic
>transactions which means everyone looking at the data the transactions
>touch needs to use the same locks.

A transfer from account A to B and a transfer from account E to F
don't need to use the same locks.

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

John Levine wrote:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>>> Calling Micro/370 a re-microcoded 68000 is
>>> like saying a Z80 is a re-microcoded 8080.
>>> It just doesn't do justice to all the work that went into it.
>> I have removed the reference to the 68000-360 from the German
>> Wikipedia accordingly. At least that reference led to an
>> interesting discussion here :-)
>
> You probably should put it back. The Micro/370 was an experimental chip that never shipped in a product.
>
> The chips in the XT/370 card really were reprogrammed 68K and 8087. See recent messages here for
> some references.

Oh right. The project time frames don't line up.
In Tredennick's book the Micro-370 starts in 1980 and says it might
have been done in about 2 years but project is under resourced and
they get the first chip in 1985.

The IBM paper says they had a 370 emulated entirely in software written
for a Motorola MC68000 in 1982, and the XT/370 is announced in Oct-83.

So they must have been running parallel projects.

In Apr-1988 IBM announced the IBM 7437 VM/SP Technical Workstation
which later became the Personal/370, aka P/370, is a complete
32-bit 370 on a micro-channel adapter (MCA) card for PS/2 or RS/6000.
It was only available to OEM's.
That sounds like it might have been the Micro-370 chip.

https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compatible_systems#Personal/370

I found a picture of a P/370
https://www.ardent-tool.com/CPU/P_370.html

Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>> According to Thomas Koenig <tkoenig@netcologne.de>:
>>>> Calling Micro/370 a re-microcoded 68000 is
>>>> like saying a Z80 is a re-microcoded 8080.
>>>> It just doesn't do justice to all the work that went into it.
>>> I have removed the reference to the 68000-360 from the German
>>> Wikipedia accordingly. At least that reference led to an
>>> interesting discussion here :-)
>> You probably should put it back.
>
> Ii would not have made sense to put back what what there because it was
> wrong on serveral counts, and had no reference
>
> It read (deepl translation, I'm lazy)
>
> This led to such interesting variants as the 68000-360, which could
> execute a ''stripped down'' version of the [[IBM]][[System/360]]
> instruction set directly on the chip and was used for a small 360
> model by IBM.
>
> - It wasn't called 68000-360
> - It wasn't /360 instructions, it was /370
> - It wasn't used for a "small 360"
>
> I replaced it with (again, deepl translation)
>
> In the PC XT/370 plug-in card, which enabled a System/370 on a
> PC/XT, a 68000 with modified microcode was used to execute some of
> the System/370 instructions directly. The remaining instructions
> were emulated on another 68000.
>
> which is, I believe, accurate.

Sorry about that, they had overlapping projects.

I found what looks like the patent for the XT/370 processor
but it still doesn't say how they did the decoder.
There doesn't seem to be any other technical details on it.

Methods for partitioning mainframe instruction sets to
implement microprocessor based emulation thereof, 1982
https://patents.google.com/patent/US4514803

which is basically a copy of the published paper

[paywalled]
Microprocessor Implementation of Mainframe Processors by
Means of Architecture Partitioning, IBM J. RES. DEVELOP 1982
https://ieeexplore.ieee.org/abstract/document/5390522/

EricP <ThatWouldBeTelling@thevillage.com> writes:
> In Apr-1988 IBM announced the IBM 7437 VM/SP Technical Workstation
> which later became the Personal/370, aka P/370, is a complete
> 32-bit 370 on a micro-channel adapter (MCA) card for PS/2 or RS/6000.
> It was only available to OEM's.
> That sounds like it might have been the Micro-370 chip.
>
> https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compatible_systems#Personal/370

upthread I posted doing some work for A74 (which gets announced as 7437
.... with email reference from '85 & '86) ... running at 350KIPS (better
than the xt/370 100KIPS).
http://www.garlic.com/~lynn/2015d.html#email850503
http://www.garlic.com/~lynn/2000e.html#email880622

other XT/370 (AT/370) email
http://www.garlic.com/~lynn/2015e.html#email850617

other a74 email
http://www.garlic.com/~lynn/2015d.html#email85020
http://www.garlic.com/~lynn/2015d.html#email85020b
http://www.garlic.com/~lynn/2015d.html#email85020c
http://www.garlic.com/~lynn/2015d.html#email85020d

mid-80s, IBM Boeblingen (Germany) also did ("ROMAN") 3-chip 370 running
at 3MIPS ... I was looking at how many I could cram into a rack. trivia:
There were monthly meetings at (Stanford) SLAC where would see a lot of
people in Silicon valley ... including many of the Amdahl people. One of
them on business trip to Nixdorf in Germany found they had a bootlegged
copy of the ROMON specification. He confiscated it and mailed it to me
for mailing back to Boeblingen.

'85 ROMAN email
http://www.garlic.com/~lynn/2007c.html#email850712

'85 email mentioning HSDT & suppose to do interconnect for the
NSF supercomputing centers, as well A74 and ROMAN work
http://www.garlic.com/~lynn/2011c.html#email850425b
same archived post with email mentioning HSDT pitch for Berkeley, NSF,
NCAR, etc
http://www.garlic.com/~lynn/2011c.html#email850426

posts also reference was suppose to do pitch to NSF Director on NSF
supercomputer interconnect at same time (IBM) yorktown wanting me for a
week to talk about how many processor chips could be crammed into a
rack (and in addition to all ROMAN 370 chips, how many Blue Iliad,
1st 32bit 801/risc chip) ... misc other
http://www.garlic.com/~lynn/2021g.html#email850312
http://www.garlic.com/~lynn/2021g.html#email850313
http://www.garlic.com/~lynn/2021g.html#email850314
http://www.garlic.com/~lynn/2007d.html#email850315

more HSDT/NSF topic drift: congress cuts the (NSF) budget, some other
things happen, and eventually an RFP is released ... preliminary
announce Preliminary announce (Mar1986)
http://www.garlic.com/~lynn/2002k.html#12
The OASC has initiated three programs: The Supercomputer Centers Program
to provide Supercomputer cycles; the New Technologies Program to foster
new supercomputer software and hardware developments; and the Networking
Program to build a National Supercomputer Access Network - NSFnet.

.... internal IBM politics prevent us from bidding on the RFP. the NSF
director tries to help by writing the company a letter (with support
from other agencies), but that just makes the internal politics worse
(as did claims that what we already had running was at least 5yrs ahead
of the winning bid). The winning bid doesn't even install T1 links
called for ... they are 440kbit/sec links ... but apparently to make it
look like its meeting the requirements, they install telco multiplexors
with T1 trunks (running multiple links/trunk). We periodically ridicule
them that why don't they call it a T5 network (because some of those T1
trunks would in turn be multiplexed over T3 or even T5 trunks). as
regional networks connect in, it becomes the NSFNET backbone, precursor
to modern internet
https://www.technologyreview.com/s/401444/grid-computing/

--
virtualization experience starting Jan1968, online at home since Mar1970

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>Everybody knows that. It's Amdahl's law. But we are not talking
>about ten computers of speed X and one with speed 10X here, we are
>talking about several computers with up to 128 cores (if we take a
>dual-socket EPYC system; but if you get the distributed software
>right, it may be cheaper to use more smaller systems) against one
>computer with up to about 240 cores that costs maybe 10x as much; the
>cores themselves have little speed difference.

To reiterate once again the point I'm trying to make, we all know that
you can get a lot more nominal MIPS/$ with a loosely coupled distributed
system. The problem is that some database stuff is inherently serial,
you can't just wave it away, and that's what keeps mainframes relevant.

>And since you mention per-bank systems, the whole stuff is distributed
>anyway: the ATM is situated at one bank (or belongs to one ATM
>company), the user's account often at a different one, they have to do
>transactions on each bank's computers.

Of course, but if my wife, my daughter, and I all try to take $100 out
of our bank account at the same time from three different places and
there's only $200 in the account, one of us has to lose. Some stuff is
inherently serial.

>>exactly because of the lock contention.
>
>But that's the point I am trying to get across: For the kind of
>transactions mentioned here, lock contention is no problem:

Sorry, I don't know how to explain this any more clearly. You can make
a lot of locks go away, but you can't make all the locks go away, and
if you have to deal with locks, one fast machine does it a lot better
than multiple slow machines.

>2) Also, you don't need to hold locks on both accounts involved. The
>classic way (from before computing) of money transfer is that the
>sending account's bank is taking the money off the one account, sends
>it over to the receiving account's bank, and the receiving bank puts
>the money into the receiving account.

I know, we still have paper checks in the US. But the era when you had
three days to bounce a check is long gone. The US Federal Reserve is
developing a scheme called FedNow which is supposed to do realtime P2P
bank payments next year, similar to what the UK and other countries
already have. I wouldn't dump my IBM stock just yet.

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

On Saturday, April 16, 2022 at 8:56:24 PM UTC+3, John Levine wrote:
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >Everybody knows that. It's Amdahl's law. But we are not talking
> >about ten computers of speed X and one with speed 10X here, we are
> >talking about several computers with up to 128 cores (if we take a
> >dual-socket EPYC system; but if you get the distributed software
> >right, it may be cheaper to use more smaller systems) against one
> >computer with up to about 240 cores that costs maybe 10x as much; the
> >cores themselves have little speed difference.
> To reiterate once again the point I'm trying to make, we all know that
> you can get a lot more nominal MIPS/$ with a loosely coupled distributed
> system. The problem is that some database stuff is inherently serial,
> you can't just wave it away, and that's what keeps mainframes relevant.

Except that mainframes are relative newcomers to Big-SMP.
The wave started with Sun Fire.
The lead in an area of big-SMP forked between HPC-oriented SGI machines,
that were very big, but worst-case latency of remote memory access was also
relatively big, and business-oriented IBM Power (p690, p5 595, p6 595, p795) and HP
Superdome that were smaller than top SGI machines but featured faster remote memory
access, at least on idle or near-idle machine.

It's not that during this period S/360 derivatives (i.e. z series/system z) didn't offere SMP
models. They did. But top z tended to be 2-3 times smaller than top POWER or Superdome.

But around the start of 2010s SGI died, HP had outgrown IBM as a business, but practically
died as leading-edge R&D organization. And IBM's Power group lost enthusiasm about big
SMP. They still released E880 (in 2016?), but it was a little smaller than the biggest p795.

All this allowed to Big Iron to cache up with Big Tin and eventually to top it.
It seems, the latest z still does not have as many cores as the biggest p795, but cores are
much newer and supposedly faster.
I say "supposedly", because no benchmarks published.

> >And since you mention per-bank systems, the whole stuff is distributed
> >anyway: the ATM is situated at one bank (or belongs to one ATM
> >company), the user's account often at a different one, they have to do
> >transactions on each bank's computers.
> Of course, but if my wife, my daughter, and I all try to take $100 out
> of our bank account at the same time from three different places and
> there's only $200 in the account, one of us has to lose. Some stuff is
> inherently serial.
> >>exactly because of the lock contention.
> >
> >But that's the point I am trying to get across: For the kind of
> >transactions mentioned here, lock contention is no problem:
> Sorry, I don't know how to explain this any more clearly. You can make
> a lot of locks go away, but you can't make all the locks go away, and
> if you have to deal with locks, one fast machine does it a lot better
> than multiple slow machines.

The speed of communication between core depends mostly on physical layers
of the COMM and on number of hops.
Communication within SMP is not inherently faster than communication in cluster
with equally good links. More like the opposite, at least for some sort of communication
patterns. IBM itself demonstrated it to the world 20 years ago, when their BlueGene
cluster were winning ping-pong latency benchmarks over SGI's contemporary big-SMP.

Back to 2022, the number of hops in 240-core z and in a small cluster of EPYC3
machines that has approximately the same # of cores or even two times more,
is more or less the same.
In Intel-based systems the # of hops would be smaller, because Intel has more
cores per die. But right now Intel is not competitive for other reasons. Specifically,
some of their products (Cascade Lake) are based on very old cores and others
(Ice Lake server) are screwed by struggling silicon tech.
But with Saphire Rapids Intel should take a significant lead in a field of sped of
remote memory access. That is, unless they screw something again.

> >2) Also, you don't need to hold locks on both accounts involved. The
> >classic way (from before computing) of money transfer is that the
> >sending account's bank is taking the money off the one account, sends
> >it over to the receiving account's bank, and the receiving bank puts
> >the money into the receiving account.
> I know, we still have paper checks in the US. But the era when you had
> three days to bounce a check is long gone. The US Federal Reserve is
> developing a scheme called FedNow which is supposed to do realtime P2P
> bank payments next year, similar to what the UK and other countries
> already have. I wouldn't dump my IBM stock just yet.
>
>
> R's,
> John
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> other a74 email
> http://www.garlic.com/~lynn/2015d.html#email85020
> http://www.garlic.com/~lynn/2015d.html#email85020b
> http://www.garlic.com/~lynn/2015d.html#email85020c
> http://www.garlic.com/~lynn/2015d.html#email85020d

typo, dropped a digit
http://www.garlic.com/~lynn/2015d.html#email850520
http://www.garlic.com/~lynn/2015d.html#email850520b
http://www.garlic.com/~lynn/2015d.html#email850520c
http://www.garlic.com/~lynn/2015d.html#email850520d

--
virtualization experience starting Jan1968, online at home since Mar1970

On Saturday, April 16, 2022 at 1:21:06 AM UTC-6, Thomas Koenig wrote:

> I now replaced it with (again, deepl translation)
> In the [[PC XT/370]] plug-in card, which enabled a [[System/370]]
> on an [[IBM Personal Computer XT|PC/XT]], a 68000 with modified
> microcode was used to execute some of the System/370 instructions
> directly. The remaining instructions were emulated on another
> 68000 or executed on the [[Intel 8087|8087]] used as [[floating
> point unit|FPU]].
>
> which should be accurate.

I went and checked; the Wikipedia article gave a reference to an IBM
disclosure on the Prior Art Database, an archived copy of the site was referenced,
from which I could read an abbreviated version of the text - and the description
matches that. The second 68000 was slightly modified, not by changing its
instruction set, but by adding an address pin to facilitate intercommunication with
the master 68000 which executed the basic 370 subset.

However, the 8087 was also modified; remember, the 370 wasn't using BFP yet
at that time.

John Savard

Anne & Lynn Wheeler wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> In Apr-1988 IBM announced the IBM 7437 VM/SP Technical Workstation
>> which later became the Personal/370, aka P/370, is a complete
>> 32-bit 370 on a micro-channel adapter (MCA) card for PS/2 or RS/6000.
>> It was only available to OEM's.
>> That sounds like it might have been the Micro-370 chip.
>>
>> https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compatible_systems#Personal/370
>
> upthread I posted doing some work for A74 (which gets announced as 7437
> .... with email reference from '85 & '86) ... running at 350KIPS (better
> than the xt/370 100KIPS).

That 350 KIPS performance matches what the Micro-370 documents say,
that it was 250 KIPS at 10 MHz and early tests were up to 16 MHZ
which would be ~400 KIPS. Possibly they later got to 800 KIPS.
Call the Micro-370 a second generation chip.

That could probably make the 3.5 MIPS Personal/370
in the wikipedia page a different 3rd generation 370 chip.

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>Everybody knows that. It's Amdahl's law. But we are not talking
>>about ten computers of speed X and one with speed 10X here, we are
>>talking about several computers with up to 128 cores (if we take a
>>dual-socket EPYC system; but if you get the distributed software
>>right, it may be cheaper to use more smaller systems) against one
>>computer with up to about 240 cores that costs maybe 10x as much; the
>>cores themselves have little speed difference.
>
>To reiterate once again the point I'm trying to make, we all know that
>you can get a lot more nominal MIPS/$ with a loosely coupled distributed
>system. The problem is that some database stuff is inherently serial,
>you can't just wave it away, and that's what keeps mainframes relevant.

Yes, there is database stuff that requires shared memory, and that
keeps big systems around. For the inherently serial ones, a
single-core system is enough, but maybe the RAM or I/O requirements
require some big system.

When discussing these requirements, give examples where shared memory
is necessary/that are inherently serial. ATM processing is not such
an example; indeed it requires distributed processing. Credit card
processing is not such an example; while it can be performed on a
shared-memory machine, it can also be performed in a distributed way.

>>And since you mention per-bank systems, the whole stuff is distributed
>>anyway: the ATM is situated at one bank (or belongs to one ATM
>>company), the user's account often at a different one, they have to do
>>transactions on each bank's computers.
>
>Of course, but if my wife, my daughter, and I all try to take $100 out
>of our bank account at the same time from three different places and
>there's only $200 in the account, one of us has to lose. Some stuff is
>inherently serial.

Certainly the three different ATMs will send their requests to the
computer holding your account, and that computer will process them one
after the other, and the last request will be denied. But for
processing this account of yours a single-core computer with meagre
memory is sufficient; given the resources of a modern PC, it can
process a large number of accounts (not because the problem requires
it, but because it's much cheaper than the PC-per-account setup).

>>But that's the point I am trying to get across: For the kind of
>>transactions mentioned here, lock contention is no problem:
>
>Sorry, I don't know how to explain this any more clearly. You can make
>a lot of locks go away, but you can't make all the locks go away,

I did not claim that there would be no locks, just not lock
contention, except maybe if Amazon has all its transactions on one
account.

Your family members rarely try to take money out of your account at
the same time, and if they do, the locks on your account are probably
contended a few microseconds or (if the code has not been optimized
for holding the account lock for a short time) maybe milliseconds,
which is no problem for a transaction that typically takes many
seconds of the user's time.

>and
>if you have to deal with locks, one fast machine does it a lot better
>than multiple slow machines.

I don't think an IBM mainframe is any faster when dealing with a
single contended lock than, e.g., a PC.

A shared-memory system is probably faster at locking than a
distributed-locking protocoll, but then you need an example that would
require distributed locking.

>>2) Also, you don't need to hold locks on both accounts involved. The
>>classic way (from before computing) of money transfer is that the
>>sending account's bank is taking the money off the one account, sends
>>it over to the receiving account's bank, and the receiving bank puts
>>the money into the receiving account.
>
>I know, we still have paper checks in the US.

I was actually thinking about money transfers (what we do a lot in the
EU), not checks.

>But the era when you had
>three days to bounce a check is long gone.

And now they also only have one day to hold your money in their
balance on a money transfer. And the actual transfer could happen in
seconds, thanks to modern networking. My point is that money
transfers have never needed to lock both accounts, and the difference
in the times when the transaction happens on the accounts shows this
nicely. And ATM and credit card transactions can be implemented in
the same way (I don't know if they are), of course with much faster
transmission needed in the ATM case (but that's not a problem).

> I wouldn't dump my IBM stock just yet.

I have no IBM stock. I think that the mainframe business gives them
nice profits, but it's not the main source of revenue for IBM these
days, so even if all mainframe customers switched to something based
on PC technology, I don't expect a big dent in their stock.

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

On 2022-03-22, Marcus wrote:
> Hello group!
>
> A class of instructions that is very tempting to include in an ISA is
> approximate floating-point reciprocals (1/x & 1/sqrt(x)), and
> possibly specialized instructions for improving precision
> (a Newton-Raphson step).
>
> Many ISAs have such instructions:
>
> CRAY:
> * 070ijx - Floating reciprocal approximation
> * 067ijk - Reciprocal iteration
>
> ARM:
> * FRECPE - Floating-point reciprocal estimate
> * FRECPS - Floating-point reciprocal step
> * FRSQRTE - Floating-point reciprocal square root estimate
> * FRSQRTS - Floating-point reciprocal square root step
>
> POWER:
> * FRES - Floating reciprocal estimate single
> * FRSQRTE - Floating reciprocal square root estimate
>
> x86:
> * RSQRTSS - Approximate reciprocal square root
>
> TI C67x:
> * RCPSP - Floating-Point reciprocal approximation
> * RSQRSP - Floating-Point reciprocal square root approximation
>
> ...and there are probably others.
>
> What are your feelings towards including such instructions in an ISA?
>
> My own feelings are mixed.
>
> Pros:
> * Easy to implement in hardware.
> * Can provide a significant speedup for certain workloads, especially
>   if limited accuracy is acceptable.
>
> Cons:
> * Hard to specify exact operation.
> * Likely a source of poor portability (borderline undefined behavior).
> * The "step/iteration" instructions can usually be replaced by FMA.
>
> /Marcus

One more thing that I discovered about a week ago:

In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
*need* a special Newtom-Raphson step instruction that handles the
special case where x = 0 and y = Inf.

Consider the approximation of y = 1 / x.

A single NR step then becomes: y' = y * (2 - x * y)

When x = 0, the approximation would return Inf, and thus we would end up
calculating x * y = 0 * Inf = NaN according to an IEEE 754 compliant
implementation.

The ARM instruction FRECPS (Floating-point reciprocal step) implements
2 - x * y, but handles the special case x == 0 && y == Inf (or vice
versa) and returns 2 instead of NaN. Thus the complete step would be
Inf * 2 = Inf, which is correct.

/Marcus

On 4/18/2022 9:47 AM, Anton Ertl wrote:
> John Levine <johnl@taugh.com> writes:
>> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>> Everybody knows that. It's Amdahl's law. But we are not talking
>>> about ten computers of speed X and one with speed 10X here, we are
>>> talking about several computers with up to 128 cores (if we take a
>>> dual-socket EPYC system; but if you get the distributed software
>>> right, it may be cheaper to use more smaller systems) against one
>>> computer with up to about 240 cores that costs maybe 10x as much; the
>>> cores themselves have little speed difference.
>>
>> To reiterate once again the point I'm trying to make, we all know that
>> you can get a lot more nominal MIPS/$ with a loosely coupled distributed
>> system. The problem is that some database stuff is inherently serial,
>> you can't just wave it away, and that's what keeps mainframes relevant.
>
> Yes, there is database stuff that requires shared memory, and that
> keeps big systems around. For the inherently serial ones, a
> single-core system is enough, but maybe the RAM or I/O requirements
> require some big system.
>
> When discussing these requirements, give examples where shared memory
> is necessary/that are inherently serial. ATM processing is not such
> an example; indeed it requires distributed processing. Credit card
> processing is not such an example; while it can be performed on a
> shared-memory machine, it can also be performed in a distributed way.
>
>>> And since you mention per-bank systems, the whole stuff is distributed
>>> anyway: the ATM is situated at one bank (or belongs to one ATM
>>> company), the user's account often at a different one, they have to do
>>> transactions on each bank's computers.
>>
>> Of course, but if my wife, my daughter, and I all try to take $100 out
>> of our bank account at the same time from three different places and
>> there's only $200 in the account, one of us has to lose. Some stuff is
>> inherently serial.
>
> Certainly the three different ATMs will send their requests to the
> computer holding your account, and that computer will process them one
> after the other, and the last request will be denied. But for
> processing this account of yours a single-core computer with meagre
> memory is sufficient; given the resources of a modern PC, it can
> process a large number of accounts (not because the problem requires
> it, but because it's much cheaper than the PC-per-account setup).
>
>>> But that's the point I am trying to get across: For the kind of
>>> transactions mentioned here, lock contention is no problem:
>>
>> Sorry, I don't know how to explain this any more clearly. You can make
>> a lot of locks go away, but you can't make all the locks go away,
>
> I did not claim that there would be no locks, just not lock
> contention, except maybe if Amazon has all its transactions on one
> account.
>
> Your family members rarely try to take money out of your account at
> the same time, and if they do, the locks on your account are probably
> contended a few microseconds or (if the code has not been optimized
> for holding the account lock for a short time) maybe milliseconds,
> which is no problem for a transaction that typically takes many
> seconds of the user's time.
>
>> and
>> if you have to deal with locks, one fast machine does it a lot better
>> than multiple slow machines.
>
> I don't think an IBM mainframe is any faster when dealing with a
> single contended lock than, e.g., a PC.
>
> A shared-memory system is probably faster at locking than a
> distributed-locking protocoll, but then you need an example that would
> require distributed locking.
>
>>> 2) Also, you don't need to hold locks on both accounts involved. The
>>> classic way (from before computing) of money transfer is that the
>>> sending account's bank is taking the money off the one account, sends
>>> it over to the receiving account's bank, and the receiving bank puts
>>> the money into the receiving account.
>>
>> I know, we still have paper checks in the US.
>
> I was actually thinking about money transfers (what we do a lot in the
> EU), not checks.
>
>> But the era when you had
>> three days to bounce a check is long gone.
>
> And now they also only have one day to hold your money in their
> balance on a money transfer. And the actual transfer could happen in
> seconds, thanks to modern networking. My point is that money
> transfers have never needed to lock both accounts, and the difference
> in the times when the transaction happens on the accounts shows this
> nicely. And ATM and credit card transactions can be implemented in
> the same way (I don't know if they are), of course with much faster
> transmission needed in the ATM case (but that's not a problem).
>
>> I wouldn't dump my IBM stock just yet.
>
> I have no IBM stock. I think that the mainframe business gives them
> nice profits, but it's not the main source of revenue for IBM these
> days, so even if all mainframe customers switched to something based
> on PC technology, I don't expect a big dent in their stock.
>
> - anton

That's not actually the way distributed accounting works (or at least
worked). There are no locks. If there were locks, then if the
connection went down after acquiring the lock the parties could be
locked out of the account indefinitely. The naive way to deal with that
is to have the transaction timeout, but that's the Byzantine Generals
problem. (https://en.wikipedia.org/wiki/Two_Generals%27_Problem)

The way it used to be done (back when I worked in the area) was a
distributed two-phase commit with a voting algorithm to deal with loss
of the commit node(s). How it's done now I have no idea.

On Monday, April 18, 2022 at 1:12:11 PM UTC-5, Marcus wrote:
> On 2022-03-22, Marcus wrote:
> > Hello group!
> >
> > A class of instructions that is very tempting to include in an ISA is
> > approximate floating-point reciprocals (1/x & 1/sqrt(x)), and
> > possibly specialized instructions for improving precision
> > (a Newton-Raphson step).
> >
> > Many ISAs have such instructions:
> >
> > CRAY:
> > * 070ijx - Floating reciprocal approximation
> > * 067ijk - Reciprocal iteration
> >
> > ARM:
> > * FRECPE - Floating-point reciprocal estimate
> > * FRECPS - Floating-point reciprocal step
> > * FRSQRTE - Floating-point reciprocal square root estimate
> > * FRSQRTS - Floating-point reciprocal square root step
> >
> > POWER:
> > * FRES - Floating reciprocal estimate single
> > * FRSQRTE - Floating reciprocal square root estimate
> >
> > x86:
> > * RSQRTSS - Approximate reciprocal square root
> >
> > TI C67x:
> > * RCPSP - Floating-Point reciprocal approximation
> > * RSQRSP - Floating-Point reciprocal square root approximation
> >
> > ...and there are probably others.
> >
> > What are your feelings towards including such instructions in an ISA?
> >
> > My own feelings are mixed.
> >
> > Pros:
> > * Easy to implement in hardware.
> > * Can provide a significant speedup for certain workloads, especially
> > if limited accuracy is acceptable.
> >
> > Cons:
> > * Hard to specify exact operation.
> > * Likely a source of poor portability (borderline undefined behavior).
> > * The "step/iteration" instructions can usually be replaced by FMA.
> >
> > /Marcus
>
>
> One more thing that I discovered about a week ago:
>
> In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> *need* a special Newtom-Raphson step instruction that handles the
> special case where x = 0 and y = Inf.
>
> Consider the approximation of y = 1 / x.
>
> A single NR step then becomes: y' = y * (2 - x * y)
>
> When x = 0, the approximation would return Inf, and thus we would end up
> calculating x * y = 0 * Inf = NaN according to an IEEE 754 compliant
> implementation.
<
I am going to complain about the word implementation.
<
How one performs RCP and RSQRT is a choice and there is a fairly rich set
of algorithms; Newton-Raphson being only 1 of those.
<
One of the properties of N-R iterations is (given a reasonable starting point)
each iteration doubles the number of bits of accuracy. Here is a situation
where an N-R iteration is performed where the rules of IEEE math cause a
wrong answer to loose all accuracy rather than doubling the accuracy.
<
N-R iterations also have the property that they are self correcting (a small
error in the starting point is reduced quadratically with iteration).
<
Neither of which happen when w=0 and y=inf. I blame this on IEEE
specification not on any arithmetic properties of N-R iterations.
<
<
But this also serves to illustrate why this should be done in HW where all
the special checks can be performed at 0 cycle cost.
>
> The ARM instruction FRECPS (Floating-point reciprocal step) implements
> 2 - x * y, but handles the special case x == 0 && y == Inf (or vice
> versa) and returns 2 instead of NaN. Thus the complete step would be
> Inf * 2 = Inf, which is correct.
>
> /Marcus

Marcus wrote:
> One more thing that I discovered about a week ago:
>
> In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> *need* a special Newtom-Raphson step instruction that handles the
> special case where x = 0 and y = Inf.

The obvious way to handle this, if you have a little bit of HW help in
the form of an input number(s) classifier, is to take out all the
special cases and merge these results with what you get from the normal
algorithm.

>
> Consider the approximation of y = 1 / x.
>
> A single NR step then becomes: y' = y * (2 - x * y)
>
> When x = 0, the approximation would return Inf, and thus we would end up
> calculating x * y = 0 * Inf = NaN according to an IEEE 754 compliant
> implementation.
>
> The ARM instruction FRECPS (Floating-point reciprocal step) implements
> 2 - x * y, but handles the special case x == 0 && y == Inf (or vice
> versa) and returns 2 instead of NaN. Thus the complete step would be
> Inf * 2 = Inf, which is correct.

The alternative is as you show here, which needs HW help in the form of
that special reciprocal step op.

Terje

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

On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
> Marcus wrote:
> > One more thing that I discovered about a week ago:
> >
> > In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> > *need* a special Newtom-Raphson step instruction that handles the
> > special case where x = 0 and y = Inf.
> The obvious way to handle this, if you have a little bit of HW help in
> the form of an input number(s) classifier, is to take out all the
> special cases and merge these results with what you get from the normal
> algorithm.
> >
> > Consider the approximation of y = 1 / x.
> >
> > A single NR step then becomes: y' = y * (2 - x * y)
<
Note: y ~= 1/x -- thus algebraically x×y ~= 1
Here: 0×Inf should be 1 not NaN.
In fact LIM[x->0]( x×~1/x ) -> ~1
<
Here, IEEE simply missed the boat.
> >
> > When x = 0, the approximation would return Inf, and thus we would end up
> > calculating x * y = 0 * Inf = NaN according to an IEEE 754 compliant
> > implementation.
> >
> > The ARM instruction FRECPS (Floating-point reciprocal step) implements
> > 2 - x * y, but handles the special case x == 0 && y == Inf (or vice
> > versa) and returns 2 instead of NaN. Thus the complete step would be
> > Inf * 2 = Inf, which is correct.
> The alternative is as you show here, which needs HW help in the form of
> that special reciprocal step op.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On 4/19/2022 3:10 AM, Terje Mathisen wrote:
> Marcus wrote:
>> One more thing that I discovered about a week ago:
>>
>> In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
>> *need* a special Newtom-Raphson step instruction that handles the
>> special case where x = 0 and y = Inf.
>
> The obvious way to handle this, if you have a little bit of HW help in
> the form of an input number(s) classifier, is to take out all the
> special cases and merge these results with what you get from the normal
> algorithm.
>

Yeah. For example, exponents of 000 and 7FF trigger special cases,
everything else can pass through as normal.

>>
>> Consider the approximation of y = 1 / x.
>>
>> A single NR step then becomes: y' = y * (2 - x * y)
>>
>> When x = 0, the approximation would return Inf, and thus we would end up
>> calculating x * y = 0 * Inf = NaN according to an IEEE 754 compliant
>> implementation.
>>
>> The ARM instruction FRECPS (Floating-point reciprocal step) implements
>> 2 - x * y, but handles the special case x == 0 && y == Inf (or vice
>> versa) and returns 2 instead of NaN. Thus the complete step would be
>> Inf * 2 = Inf, which is correct.
>
> The alternative is as you show here, which needs HW help in the form of
> that special reciprocal step op.
>

Though, absent having something special in the hardware, such a helper
op would offer little real advantage over using normal FPU instructions
(FMUL/FADD/FMAC/...).

Since the operation is effectively latency-bound rather than throughput
bound, and normal FPU instructions can (presumably) operate the FPU at
their full speed (in terms of latency).

For example, I recently went and re-implemented an FDIV instruction,
based on just sort of plumbing the existing units together in a way that
sort of does a crude approximation of N-R ... (With no actual stepping
or flow-control on the values), and as-is has a relatively slow
convergence. The FPU then just sorta stalls for a while and waits for
the values to converge (need to shift the value right a few bits else it
just sorta flies off into space).

In this case, I took the "hopefully cheap" route rather than an
"actually good" route.

I initially went with "wait until difference drops to zero", but then
switched over to "stall for N cycles", because:
Easier to reason about costs;
Marginally cheaper;
Will not deadlock the CPU if a pathological edge-case happens.
For now, using 240 for FDIV, and 252 for FSQRT.

So, while it can technically divide numbers, and perform square root,
as-is its performance "leaves something to be desired". Current testing
shows that it is also somewhat slower than the current software options.

The power of software in this case being that it allows "coordinating"
the individual steps, and allows the flexibility of doing N-R properly
only a single FMUL and FADD unit.

Also, in software it is possible to have alternate versions depending on
what is needed (so, for example, for much of Quake's renderer I can use
a chopped down version with only 2 N-R steps, which is "mostly good
enough", and around 1/3 as many clock-cycles as the FDIV op).

Theoretically, better coordination could be possible by fiddling with
pipeline-delays such that the values move through the pipelines in a
sensible way. Though, initial attempts at this made the stability and
convergence "actually worse" than just going at "full-speed".

Initial guess for FDIV was basically:
{ Rs[63]^Rt[63], Rs[62:40]-Rt[62:40]+23'h3FF000, 40'h00 }
With the low-order bits cut off because:
They are basically already wrong anyways;
They add cost and latency.

Couldn't find a better approximate that would not depend on large lookup
tables, and attempts to break it down into small (6-bit) lookups were
unsuccessful.

Though, a single 6-bit lookup for the high-bits of the mantissa would be
at least slightly more accurate than a bare subtract.
{ Rs[63]^Rt[63], Rs[62:40] +
{ 11'h3FE-Rt[62:52], RtApxRcpFra },
40'h00 }
Where, one uses Rt[51:46] to lookup an approximation of the reciprocal.

....

At present, FDIV via this method takes around 240 clock cycles to
converge...

Also have noted that the low-order bits of the result are basically
garbage in this implementation.

It is also basically a boat anchor if one tries to use it in Quake or
similar.

....

On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
> On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
> > Marcus wrote:
> > > One more thing that I discovered about a week ago:
> > >
> > > In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> > > *need* a special Newtom-Raphson step instruction that handles the
> > > special case where x = 0 and y = Inf.
> > The obvious way to handle this, if you have a little bit of HW help in
> > the form of an input number(s) classifier, is to take out all the
> > special cases and merge these results with what you get from the normal
> > algorithm.
> > >
> > > Consider the approximation of y = 1 / x.
> > >
> > > A single NR step then becomes: y' = y * (2 - x * y)
> <
> Note: y ~= 1/x -- thus algebraically x×y ~= 1
> Here: 0×Inf should be 1 not NaN.
> In fact LIM[x->0]( x×~1/x ) -> ~1

0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.

On Tuesday, April 19, 2022 at 5:05:28 PM UTC-5, Michael S wrote:
> On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
> > On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
> > > Marcus wrote:
> > > > One more thing that I discovered about a week ago:
> > > >
> > > > In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> > > > *need* a special Newtom-Raphson step instruction that handles the
> > > > special case where x = 0 and y = Inf.
> > > The obvious way to handle this, if you have a little bit of HW help in
> > > the form of an input number(s) classifier, is to take out all the
> > > special cases and merge these results with what you get from the normal
> > > algorithm.
> > > >
> > > > Consider the approximation of y = 1 / x.
> > > >
> > > > A single NR step then becomes: y' = y * (2 - x * y)
> > <
> > Note: y ~= 1/x -- thus algebraically x×y ~= 1
> > Here: 0×Inf should be 1 not NaN.
> > In fact LIM[x->0]( x×~1/x ) -> ~1
> 0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
> In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.
<
They may be unknown "in general" but in this particular N-R iteration the LIM is known to be 1.000000000000000000000000000.
<

On Wednesday, April 20, 2022 at 1:33:50 AM UTC+3, MitchAlsup wrote:
> On Tuesday, April 19, 2022 at 5:05:28 PM UTC-5, Michael S wrote:
> > On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
> > > On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
> > > > Marcus wrote:
> > > > > One more thing that I discovered about a week ago:
> > > > >
> > > > > In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> > > > > *need* a special Newtom-Raphson step instruction that handles the
> > > > > special case where x = 0 and y = Inf.
> > > > The obvious way to handle this, if you have a little bit of HW help in
> > > > the form of an input number(s) classifier, is to take out all the
> > > > special cases and merge these results with what you get from the normal
> > > > algorithm.
> > > > >
> > > > > Consider the approximation of y = 1 / x.
> > > > >
> > > > > A single NR step then becomes: y' = y * (2 - x * y)
> > > <
> > > Note: y ~= 1/x -- thus algebraically x×y ~= 1
> > > Here: 0×Inf should be 1 not NaN.
> > > In fact LIM[x->0]( x×~1/x ) -> ~1
> > 0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
> > In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.
> <
> They may be unknown "in general" but in this particular N-R iteration the LIM is known to be 1.000000000000000000000000000.
> <

The rules are "in general". They are not created to satisfy needs of one particular not extremely important algorithm.
BTW, after thinking a bit about it I feel that existing inf rules are rather "too practical", scarifying mathematical rigor
in favor of non-proven practicality.
In particular, being today (tonight) in rigorous mood, I'd prefer (+inf - Finite_Positive_Number) to be NaN rather than +inf.
Because we don't know if result is bigger than MAX_DBL or, may be, smaller.
The same goes for (inf / Finite_Number_Above_One).
Etc...

On Tuesday, April 19, 2022 at 9:03:41 PM UTC-5, Michael S wrote:
> On Wednesday, April 20, 2022 at 1:33:50 AM UTC+3, MitchAlsup wrote:
> > On Tuesday, April 19, 2022 at 5:05:28 PM UTC-5, Michael S wrote:
> > > On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
> > > > On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
> > > > > Marcus wrote:
> > > > > > One more thing that I discovered about a week ago:
> > > > > >
> > > > > > In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> > > > > > *need* a special Newtom-Raphson step instruction that handles the
> > > > > > special case where x = 0 and y = Inf.
> > > > > The obvious way to handle this, if you have a little bit of HW help in
> > > > > the form of an input number(s) classifier, is to take out all the
> > > > > special cases and merge these results with what you get from the normal
> > > > > algorithm.
> > > > > >
> > > > > > Consider the approximation of y = 1 / x.
> > > > > >
> > > > > > A single NR step then becomes: y' = y * (2 - x * y)
> > > > <
> > > > Note: y ~= 1/x -- thus algebraically x×y ~= 1
> > > > Here: 0×Inf should be 1 not NaN.
> > > > In fact LIM[x->0]( x×~1/x ) -> ~1
> > > 0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
> > > In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.
> > <
> > They may be unknown "in general" but in this particular N-R iteration the LIM is known to be 1.000000000000000000000000000.
> > <
> The rules are "in general". They are not created to satisfy needs of one particular not extremely important algorithm.
> BTW, after thinking a bit about it I feel that existing inf rules are rather "too practical", scarifying mathematical rigor
> in favor of non-proven practicality.
<
And that is exactly why floating point is not "like" real numbers.
<
Perhaps posits are our only real hope.
<
> In particular, being today (tonight) in rigorous mood, I'd prefer (+inf - Finite_Positive_Number) to be NaN rather than +inf.
> Because we don't know if result is bigger than MAX_DBL or, may be, smaller.
> The same goes for (inf / Finite_Number_Above_One).
> Etc...

MitchAlsup wrote:
> On Tuesday, April 19, 2022 at 5:05:28 PM UTC-5, Michael S wrote:
>> On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
>>> On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
>>>> Marcus wrote:
>>>>> One more thing that I discovered about a week ago:
>>>>>
>>>>> In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
>>>>> *need* a special Newtom-Raphson step instruction that handles the
>>>>> special case where x = 0 and y = Inf.
>>>> The obvious way to handle this, if you have a little bit of HW help in
>>>> the form of an input number(s) classifier, is to take out all the
>>>> special cases and merge these results with what you get from the normal
>>>> algorithm.
>>>>>
>>>>> Consider the approximation of y = 1 / x.
>>>>>
>>>>> A single NR step then becomes: y' = y * (2 - x * y)
>>> <
>>> Note: y ~= 1/x -- thus algebraically x×y ~= 1
>>> Here: 0×Inf should be 1 not NaN.
>>> In fact LIM[x->0]( x×~1/x ) -> ~1
>> 0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
>> In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.
> <
> They may be unknown "in general" but in this particular N-R iteration the LIM is known to be 1.000000000000000000000000000.

Which is why you cannot use normal (individual/standard) FP ops to do
this, you need something higher level which knows about the special
rules in effect right here. I.e. like that ARM reciprocal step opcode.

Alternatively, and the solution I prefer, you handle all special inputs
in parallel with the normal algorithm and merge at the end.

I.e. if the divisor is 0 then the 754 standard specifies exactly what
the output should be for all the various dividend/divisor combinations:

non-zero/zero -> inf with sign according to normal (XOR) rules.

zero/zero -> NaN
inf/zero -> NaN
nan/zero -> NaN

You have similar rows for (x)/inf and (x)/NaN, i.e. this is a simple
square lookup table based on the types of the two operands where only
the number/number entry specifies that the normal NR result should be
propagated.

You do of course have to detect overflow/underflow as part of that
normal algorithm!

Terje

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

Michael S wrote:
> On Wednesday, April 20, 2022 at 1:33:50 AM UTC+3, MitchAlsup wrote:
>> On Tuesday, April 19, 2022 at 5:05:28 PM UTC-5, Michael S wrote:
>>> On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
>>>> On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
>>>>> Marcus wrote:
>>>>>> One more thing that I discovered about a week ago:
>>>>>>
>>>>>> In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
>>>>>> *need* a special Newtom-Raphson step instruction that handles the
>>>>>> special case where x = 0 and y = Inf.
>>>>> The obvious way to handle this, if you have a little bit of HW help in
>>>>> the form of an input number(s) classifier, is to take out all the
>>>>> special cases and merge these results with what you get from the normal
>>>>> algorithm.
>>>>>>
>>>>>> Consider the approximation of y = 1 / x.
>>>>>>
>>>>>> A single NR step then becomes: y' = y * (2 - x * y)
>>>> <
>>>> Note: y ~= 1/x -- thus algebraically x×y ~= 1
>>>> Here: 0×Inf should be 1 not NaN.
>>>> In fact LIM[x->0]( x×~1/x ) -> ~1
>>> 0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
>>> In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.
>> <
>> They may be unknown "in general" but in this particular N-R iteration the LIM is known to be 1.000000000000000000000000000.
>> <
>
> The rules are "in general". They are not created to satisfy needs of one particular not extremely important algorithm.
> BTW, after thinking a bit about it I feel that existing inf rules are rather "too practical", scarifying mathematical rigor
> in favor of non-proven practicality.
> In particular, being today (tonight) in rigorous mood, I'd prefer (+inf - Finite_Positive_Number) to be NaN rather than +inf.
> Because we don't know if result is bigger than MAX_DBL or, may be, smaller.
> The same goes for (inf / Finite_Number_Above_One).
> Etc...

Sorry, but this is simply wrong:

What you suggest here is to abandon knowledge we do have in favor of
making NaN even more sticky than it currently is.

If you have an algorithm which can spuriously overflow in the middle,
but which with a different evaluation order, or higher intermediate
precision/exponent range, would be OK, then giving Inf as the result
still provides important information: This calculation overflowed
somewhere in the middle.

Always returning NaN instead means that you have lost this info, now the
NaN could have been due to many different errors, including 0/0 etc.

All the 754 ops have been defined to return the best possible answer,
when taken in isolation.

The original (1978) idea was to handle exponent overflow (or underflow)
via a trap handler that would save the current exponent, bias it enough
to bring the current operation into legal range, and then inspect and
correct the final result based on any such bias operations performed
during the processing.

Afaik, nobody is seriously doing this for production code.

Terje

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

On Wednesday, April 20, 2022 at 11:02:51 AM UTC+3, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Tuesday, April 19, 2022 at 5:05:28 PM UTC-5, Michael S wrote:
> >> On Tuesday, April 19, 2022 at 10:42:08 PM UTC+3, MitchAlsup wrote:
> >>> On Tuesday, April 19, 2022 at 3:10:26 AM UTC-5, Terje Mathisen wrote:
> >>>> Marcus wrote:
> >>>>> One more thing that I discovered about a week ago:
> >>>>>
> >>>>> In order to support the IEEE 754 semantics of 1 / 0 == Inf, you actually
> >>>>> *need* a special Newtom-Raphson step instruction that handles the
> >>>>> special case where x = 0 and y = Inf.
> >>>> The obvious way to handle this, if you have a little bit of HW help in
> >>>> the form of an input number(s) classifier, is to take out all the
> >>>> special cases and merge these results with what you get from the normal
> >>>> algorithm.
> >>>>>
> >>>>> Consider the approximation of y = 1 / x.
> >>>>>
> >>>>> A single NR step then becomes: y' = y * (2 - x * y)
> >>> <
> >>> Note: y ~= 1/x -- thus algebraically x×y ~= 1
> >>> Here: 0×Inf should be 1 not NaN.
> >>> In fact LIM[x->0]( x×~1/x ) -> ~1
> >> 0*Inf = NaN for the same reason 0/0=Nan and Inf/Inf=Nan.
> >> In all 3 cases the results are "unknown" and FP numbers have no better encoding for "unknown" than NaN.
> > <
> > They may be unknown "in general" but in this particular N-R iteration the LIM is known to be 1.000000000000000000000000000.
> Which is why you cannot use normal (individual/standard) FP ops to do
> this, you need something higher level which knows about the special
> rules in effect right here. I.e. like that ARM reciprocal step opcode.
>
> Alternatively, and the solution I prefer, you handle all special inputs
> in parallel with the normal algorithm and merge at the end.
>
> I.e. if the divisor is 0 then the 754 standard specifies exactly what
> the output should be for all the various dividend/divisor combinations:
>
> non-zero/zero -> inf with sign according to normal (XOR) rules.
>
> zero/zero -> NaN
> inf/zero -> NaN

Are you sure about it?
I didn't look in the IEEE docs, but both my intuition and gcc compiler disagree.
Both say:
inf/zero -> inf with sign according to normal (XOR) rules.

> nan/zero -> NaN
>
> You have similar rows for (x)/inf and (x)/NaN, i.e. this is a simple
> square lookup table based on the types of the two operands where only
> the number/number entry specifies that the normal NR result should be
> propagated.
>
> You do of course have to detect overflow/underflow as part of that
> normal algorithm!
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"