MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, March 30, 2022 at 1:19:52 PM UTC-5, Thomas Koenig wrote:

>> Could you give that Chebyshev formula for 1/x?
><
> p(x) = 0.32323232×x^2 -0.48484848×x + 0.66666667
><
> on the interval 1.0..2.0
><
> Which is compared to 1000 randomized points against 1/x
><
> The highest error encountered has 6.63 bits of precision.
><---------------------------------
> But the x I put into the polynomial was the distance from the mid-point of the interval = 1.5
><---------------------------------
> Making the formula::
><
> p(x) = 0.32323232×(x-1.5)^2 -0.48484848×(x-1.5) + 0.66666667
><
> x in the interval {1.0..2.0} polynomial argument in the range {-0.5..+0.5}
><
><
><
> It is so easy to get lost in eXcel spreadsheet equations.

Which is one reason why I seriously don't like Excel and avoid
its use whenever I can. Just today, I was saved from putting a
bad value into a research report by having checked with MathCad
beforehand :-)

Wasn't there some economic theory based on faulty spreadsheets?
I remember such a story a few years ago...

Michael S wrote:
> On Thursday, April 7, 2022 at 12:03:32 PM UTC+3, Anton Ertl wrote:
>> We were actually talking about the program that worked nicely on Linux,
>> and failed on WSL.
>>
>
> More I think about it, less I see a justification for WSL control word defaults.

I agree 100%, the WSL setup is simply broken.

>
>> But yes, the library may not be doing what it should do in a program
>> that actively sets the precision to some other values than long
>> double.
>>
>> I can imagine some measures that would deal with the problem in the
>> usual case: E.g., on first invocation the function for setting the
>> precision control changes the vector of the quad-math functions to
>> versions that set the precision control for their own needs (and save
>> and restore the x87 control word). However, that would not work for
>> programs that don't use these functions, but set the control word
>> directly (in assembly language), so unless the library is documented
>> as requiring the function calls for changing the precision control,
>> the library would still be deficient.
>>
>
> In this particular case, the only winning strategy is to refuse to play.
> I.e. quadmath library should be and could be coded without any use of 80-bit
> FP and with very minimalist use of 64-bit FP. On modern 64-bit x86 (and,
> I suppose, on modern ARM and POWER) it's not only the most robust way,
> precision-wise, but also the fastest.

I'm guessing that in real world use there might actually be significant
instances of numbers which happens to fit inside the 80-bit format, but
not in double. In that particular case using 80-bit is obviously a big
win, but this will break down pretty quickly as soon as you do a number
of FMULQs or a single FDIVQ or FSQRTQ.
>
> But I can imagine other cases where judicious use of 80-bit FP is really
> beneficiary.

Right.

The FSQRTQ example is an obvious case, since using 80-bit gives you a
64-bit mantissa, which after one NR iteration becomes ~128 which will be
correctly rounded in approximately 65535 out 65536 cases, right?

Doing a full precision back-multiplication, by splitting the 128-bit
mantissa into two parts and squaring it (4 uint64_t 64x64->128 muls)
give you the residual and tells you if the initial result needs to be
adjusted by 1 ulp.

Terje

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

On Thursday, April 7, 2022 at 10:47:42 PM UTC+3, Terje Mathisen wrote:
> Michael S wrote:
> > On Thursday, April 7, 2022 at 12:03:32 PM UTC+3, Anton Ertl wrote:
> >> We were actually talking about the program that worked nicely on Linux,
> >> and failed on WSL.
> >>
> >
> > More I think about it, less I see a justification for WSL control word defaults.
> I agree 100%, the WSL setup is simply broken.
> >
> >> But yes, the library may not be doing what it should do in a program
> >> that actively sets the precision to some other values than long
> >> double.
> >>
> >> I can imagine some measures that would deal with the problem in the
> >> usual case: E.g., on first invocation the function for setting the
> >> precision control changes the vector of the quad-math functions to
> >> versions that set the precision control for their own needs (and save
> >> and restore the x87 control word). However, that would not work for
> >> programs that don't use these functions, but set the control word
> >> directly (in assembly language), so unless the library is documented
> >> as requiring the function calls for changing the precision control,
> >> the library would still be deficient.
> >>
> >
> > In this particular case, the only winning strategy is to refuse to play.
> > I.e. quadmath library should be and could be coded without any use of 80-bit
> > FP and with very minimalist use of 64-bit FP. On modern 64-bit x86 (and,
> > I suppose, on modern ARM and POWER) it's not only the most robust way,
> > precision-wise, but also the fastest.
> I'm guessing that in real world use there might actually be significant
> instances of numbers which happens to fit inside the 80-bit format, but
> not in double. In that particular case using 80-bit is obviously a big
> win, but this will break down pretty quickly as soon as you do a number
> of FMULQs or a single FDIVQ or FSQRTQ.

Finding out that result fits in 80 bit and converting back and force will take more
time than just doing the work. Pay attention that in common cases of FADD/FSUB/FMUL
a work itself, outside of call overhead, parsing inputs and formatting output, is of
order of 10 clocks, at worst 15 clocks on less modern cores.

> >
> > But I can imagine other cases where judicious use of 80-bit FP is really
> > beneficiary.
> Right.
>
> The FSQRTQ example is an obvious case, since using 80-bit gives you a
> 64-bit mantissa, which after one NR iteration becomes ~128 which will be
> correctly rounded in approximately 65535 out 65536 cases, right?
>
> Doing a full precision back-multiplication, by splitting the 128-bit
> mantissa into two parts and squaring it (4 uint64_t 64x64->128 muls)
> give you the residual and tells you if the initial result needs to be
> adjusted by 1 ulp.

I don't think so.
Doing rsqrt on x87 with 64-bit precision is not faster than doing
it with something like ~63.7 bits on the integer side. More likely, not just not faster,
but much slower, esp. when we take into account conversions.
And then, for the algorithm that I have in mind, 63.7 or 64 bits are not much better
than, say, 61 bit. In both cases on the next step you calculate a result with precision
of more than 113 bits, but less than 228 bits required for correct rounding (or is it 227?
I don't remember). So, after that step we examine the closeness of result to to the mid-point
between representable numbers and only when result is close we do additional step
which consists of doing the square of the midpoint, calculating only relevant bits and
then choosing direction of the rounding according to bit[115] of the square.
With susch algorithm the only difference between 64-bit estimate and 61-bit estimate
is the probability of doing the additional step. For 61b probability is low and for 64b it is
extremely low. Such difference is unlikely to cause detectable speed difference in real-world
usage scenario or even in benchmarks, except when they are intentionally crafted to
concentrate on the corner cases.

When I was talking about judicious use I didn't mean quadmath library at all,
but things like solving non-linear equations with double-precision inputs and
outputs where you sometimes want better precision on intermediate in order
to simplify algorithms and improve stability.
May be, something similar can be encountered in matrix factorization when det(A) is
small, but here I am less sure.
In fact, my comment was just an expression of general feeling. It wasn't deeply thought.

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

On Wed, 6 Apr 2022 22:01 +0100 (BST), jgd@cix.co.uk (John Dallman)
wrote:

>In article <vofo4hh9npgd0vaefo51khtndt80g440if@4ax.com>,
>gneuner2@comcast.net (George Neuner) wrote:
>
>> Blame should fall on the library - if code needs control flags set
>> in some particular way, it should make sure they are set correctly.
>> Relying on system defaults because they happen to line up with
>> expectations is just lazy.
>
>Changing those flags takes time - on the microsecond scale,because it
>often requires the pipeline to empty before the change - so you don't
>want to be doing it at every entry to a quad-precision library, where
>you'd hope that some operations would be timed on the nanosecond scale.
>It's probably better to document what's needed, so that the application
>can control things.
>
>> Also the Windows default x87 setting IS 64-bit (full width)
>> precision.
>
>Default in what circumstances? In the Microsoft C/C++ run-time
>environment, the default has been ordinary double precision, with a
>53-bit mantissa, since 1996 to my certain knowledge. The hardware default
>for the x87 registers is long double, with a 64-bit mantissa.

Since Pentium 4 the compiler has by default used SIMD registers for
floating point. The x87 is not normally used.

But we were discussing use of the x87 by the quadmath library. The
library does/did not explicitly set x87 precision, and Michael found
the default setting under WSL to be wrong.

I was a bit sloppy in my wording, but in context I was addressing
Michael's assertion:

"Somehow, under WSL, x87 control word is set to 53-bit
precision (default Windows settings)."

WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
double). Anton gave a more detailed response further down.

My real point was that library code should not be relying on defaults
for changeable settings. If quadmath explicitly set the needed
precision, the odd default running under WSL would not have mattered.

And yes, I understand both Michael's and Anton's aversion to
unnecessary work ... particularly because changing precision on the
x87 can be very slow. But since the setting can be READ as well as
written, there is no need to change it if it is correct when the
library goes to use it.

George

Michael S wrote:
> On Thursday, April 7, 2022 at 10:47:42 PM UTC+3, Terje Mathisen wrote:
>> Michael S wrote:
>>> On Thursday, April 7, 2022 at 12:03:32 PM UTC+3, Anton Ertl wrote:
>>>> We were actually talking about the program that worked nicely on Linux,
>>>> and failed on WSL.
>>>>
>>>
>>> More I think about it, less I see a justification for WSL control word defaults.
>> I agree 100%, the WSL setup is simply broken.
>>>
>>>> But yes, the library may not be doing what it should do in a program
>>>> that actively sets the precision to some other values than long
>>>> double.
>>>>
>>>> I can imagine some measures that would deal with the problem in the
>>>> usual case: E.g., on first invocation the function for setting the
>>>> precision control changes the vector of the quad-math functions to
>>>> versions that set the precision control for their own needs (and save
>>>> and restore the x87 control word). However, that would not work for
>>>> programs that don't use these functions, but set the control word
>>>> directly (in assembly language), so unless the library is documented
>>>> as requiring the function calls for changing the precision control,
>>>> the library would still be deficient.
>>>>
>>>
>>> In this particular case, the only winning strategy is to refuse to play.
>>> I.e. quadmath library should be and could be coded without any use of 80-bit
>>> FP and with very minimalist use of 64-bit FP. On modern 64-bit x86 (and,
>>> I suppose, on modern ARM and POWER) it's not only the most robust way,
>>> precision-wise, but also the fastest.
>> I'm guessing that in real world use there might actually be significant
>> instances of numbers which happens to fit inside the 80-bit format, but
>> not in double. In that particular case using 80-bit is obviously a big
>> win, but this will break down pretty quickly as soon as you do a number
>> of FMULQs or a single FDIVQ or FSQRTQ.
>
> Finding out that result fits in 80 bit and converting back and force will take more
> time than just doing the work. Pay attention that in common cases of FADD/FSUB/FMUL
> a work itself, outside of call overhead, parsing inputs and formatting output, is of
> order of 10 clocks, at worst 15 clocks on less modern cores.
>
>>>
>>> But I can imagine other cases where judicious use of 80-bit FP is really
>>> beneficiary.
>> Right.
>>
>> The FSQRTQ example is an obvious case, since using 80-bit gives you a
>> 64-bit mantissa, which after one NR iteration becomes ~128 which will be
>> correctly rounded in approximately 65535 out 65536 cases, right?
>>
>> Doing a full precision back-multiplication, by splitting the 128-bit
>> mantissa into two parts and squaring it (4 uint64_t 64x64->128 muls)
>> give you the residual and tells you if the initial result needs to be
>> adjusted by 1 ulp.
>
> I don't think so.
> Doing rsqrt on x87 with 64-bit precision is not faster than doing
> it with something like ~63.7 bits on the integer side. More likely, not just not faster,
> but much slower, esp. when we take into account conversions.
> And then, for the algorithm that I have in mind, 63.7 or 64 bits are not much better
> than, say, 61 bit. In both cases on the next step you calculate a result with precision
> of more than 113 bits, but less than 228 bits required for correct rounding (or is it 227?

Quad uses 1:15:112, so 113 including the hidden bit? I would like to
have 230 bits to feel perfectly safe, but if it has been proven to work
with one or two less, that's fine.

> I don't remember). So, after that step we examine the closeness of result to to the mid-point
> between representable numbers and only when result is close we do additional step
> which consists of doing the square of the midpoint, calculating only relevant bits and
> then choosing direction of the rounding according to bit[115] of the square.

That is a good idea! We don't need the leading 128 bits of the 256-bit
multiplication result (assuming 64-bit ints here), but that only saves
one 64x64->128 MUL (plus a few ADD/ADC).

> With susch algorithm the only difference between 64-bit estimate and 61-bit estimate
> is the probability of doing the additional step. For 61b probability is low and for 64b it is
> extremely low. Such difference is unlikely to cause detectable speed difference in real-world
> usage scenario or even in benchmarks, except when they are intentionally crafted to
> concentrate on the corner cases.

Yeah, I agree.

>
> When I was talking about judicious use I didn't mean quadmath library at all,
> but things like solving non-linear equations with double-precision inputs and
> outputs where you sometimes want better precision on intermediate in order
> to simplify algorithms and improve stability.
> May be, something similar can be encountered in matrix factorization when det(A) is
> small, but here I am less sure.

OK.

> In fact, my comment was just an expression of general feeling. It wasn't deeply thought.
:-)

Terje

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

On Friday, April 8, 2022 at 2:46:46 AM UTC+3, George Neuner wrote:
> On Wed, 6 Apr 2022 22:01 +0100 (BST), j...@cix.co.uk (John Dallman)
> wrote:
> >In article <vofo4hh9npgd0vaef...@4ax.com>,
> >gneu...@comcast.net (George Neuner) wrote:
> >
> >> Blame should fall on the library - if code needs control flags set
> >> in some particular way, it should make sure they are set correctly.
> >> Relying on system defaults because they happen to line up with
> >> expectations is just lazy.
> >
> >Changing those flags takes time - on the microsecond scale,because it
> >often requires the pipeline to empty before the change - so you don't
> >want to be doing it at every entry to a quad-precision library, where
> >you'd hope that some operations would be timed on the nanosecond scale.
> >It's probably better to document what's needed, so that the application
> >can control things.
> >
> >> Also the Windows default x87 setting IS 64-bit (full width)
> >> precision.
> >
> >Default in what circumstances? In the Microsoft C/C++ run-time
> >environment, the default has been ordinary double precision, with a
> >53-bit mantissa, since 1996 to my certain knowledge. The hardware default
> >for the x87 registers is long double, with a 64-bit mantissa.
> Since Pentium 4 the compiler has by default used SIMD registers for
> floating point. The x87 is not normally used.

I wonder what you mean by that.
For starter, Windows does not have default user-mode compiler.
But the closest thing to "default compiler" is Microsoft's own Visual C++ with no special options.
32-bit Visual C++ with no special options most definitely uses x87 registers for FP math.
On any CPU, Pentium 4 or not.
If programmer want SSE2 then he has to tell it specifically to the compiler.

Now, 64-bit Visual C++ is different. This compiler uses SSE by default and can be told to use
AVX instead. But it can't be told to use x87.
Also, x86-64 Visual C++ is 3-4 years younger than Pentium 4 and it didn't become a default
of Visual Studio until very recently.
Or, may be, a default is still 32-bit? I don't have a latest version of VS to check.

>
> But we were discussing use of the x87 by the quadmath library. The
> library does/did not explicitly set x87 precision, and Michael found
> the default setting under WSL to be wrong.

Google helped me to find out that it was reported as a bug 5 years ago.
It seems, somebody at MS didn't agree with such definition.
https://github.com/microsoft/WSL/issues/1748

>
> I was a bit sloppy in my wording, but in context I was addressing
> Michael's assertion:
>
> "Somehow, under WSL, x87 control word is set to 53-bit
> precision (default Windows settings)."
>
> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
> double). Anton gave a more detailed response further down.

It's true for Gnu and clang tools for Windows.
For Microsoft tools it's not a case.
Microsoft 's tools default to control word = 0x02F7.
It's true both in 32-bit mode, where it makes a very good sense
because at introduction of WinNT back in 1993 Microsoft's major goal was maximal
compatibility of behavior between IA-32, MIPS and Alpha, and in 64-bit mode,
where it does not make a lot of sense, since compiler does not use x87 anyway so
its only user are asm programmers and libraries that most likely use it exactly due to
higher precision.

>
>
> My real point was that library code should not be relying on defaults
> for changeable settings. If quadmath explicitly set the needed
> precision, the odd default running under WSL would not have mattered.
>
> And yes, I understand both Michael's and Anton's aversion to
> unnecessary work ... particularly because changing precision on the
> x87 can be very slow. But since the setting can be READ as well as
> written, there is no need to change it if it is correct when the
> library goes to use it.
>
> George

Michael S wrote:
> On Friday, April 8, 2022 at 2:46:46 AM UTC+3, George Neuner wrote:
>> On Wed, 6 Apr 2022 22:01 +0100 (BST), j...@cix.co.uk (John Dallman)
>> wrote:
>>> In article <vofo4hh9npgd0vaef...@4ax.com>,
>>> gneu...@comcast.net (George Neuner) wrote:
>>>
>>>> Blame should fall on the library - if code needs control flags set
>>>> in some particular way, it should make sure they are set correctly.
>>>> Relying on system defaults because they happen to line up with
>>>> expectations is just lazy.
>>> Changing those flags takes time - on the microsecond scale,because it
>>> often requires the pipeline to empty before the change - so you don't
>>> want to be doing it at every entry to a quad-precision library, where
>>> you'd hope that some operations would be timed on the nanosecond scale.
>>> It's probably better to document what's needed, so that the application
>>> can control things.
>>>
>>>> Also the Windows default x87 setting IS 64-bit (full width)
>>>> precision.
>>> Default in what circumstances? In the Microsoft C/C++ run-time
>>> environment, the default has been ordinary double precision, with a
>>> 53-bit mantissa, since 1996 to my certain knowledge. The hardware default
>>> for the x87 registers is long double, with a 64-bit mantissa.
>> Since Pentium 4 the compiler has by default used SIMD registers for
>> floating point. The x87 is not normally used.
>
> I wonder what you mean by that.
> For starter, Windows does not have default user-mode compiler.
> But the closest thing to "default compiler" is Microsoft's own Visual C++ with no special options.
> 32-bit Visual C++ with no special options most definitely uses x87 registers for FP math.
> On any CPU, Pentium 4 or not.
> If programmer want SSE2 then he has to tell it specifically to the compiler.
>
> Now, 64-bit Visual C++ is different. This compiler uses SSE by default and can be told to use
> AVX instead. But it can't be told to use x87.
> Also, x86-64 Visual C++ is 3-4 years younger than Pentium 4 and it didn't become a default
> of Visual Studio until very recently.
> Or, may be, a default is still 32-bit? I don't have a latest version of VS to check.
>
>> But we were discussing use of the x87 by the quadmath library. The
>> library does/did not explicitly set x87 precision, and Michael found
>> the default setting under WSL to be wrong.
>
> Google helped me to find out that it was reported as a bug 5 years ago.
> It seems, somebody at MS didn't agree with such definition.
> https://github.com/microsoft/WSL/issues/1748
>
>> I was a bit sloppy in my wording, but in context I was addressing
>> Michael's assertion:
>>
>> "Somehow, under WSL, x87 control word is set to 53-bit
>> precision (default Windows settings)."
>>
>> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
>> double). Anton gave a more detailed response further down.
>
> It's true for Gnu and clang tools for Windows.
> For Microsoft tools it's not a case.
> Microsoft 's tools default to control word = 0x02F7.
> It's true both in 32-bit mode, where it makes a very good sense
> because at introduction of WinNT back in 1993 Microsoft's major goal was maximal
> compatibility of behavior between IA-32, MIPS and Alpha, and in 64-bit mode,
> where it does not make a lot of sense, since compiler does not use x87 anyway so
> its only user are asm programmers and libraries that most likely use it exactly due to
> higher precision.
>
>>
>> My real point was that library code should not be relying on defaults
>> for changeable settings. If quadmath explicitly set the needed
>> precision, the odd default running under WSL would not have mattered.
>>
>> And yes, I understand both Michael's and Anton's aversion to
>> unnecessary work ... particularly because changing precision on the
>> x87 can be very slow. But since the setting can be READ as well as
>> written, there is no need to change it if it is correct when the
>> library goes to use it.
>>
>> George

This comment seems to think it is due to how fork is implemented:
In WSL1 the FP control word is maintained across a fork, in Linux it is not.
(as with all Internet opinions, that should be taken with a grain of salt).

https://github.com/microsoft/WSL/issues/830#issuecomment-472279984

Later comments indicate it is fixed in WSL2
but then others contradict that.

Michael S <already5chosen@yahoo.com> writes:
> Google helped me to find out that it was reported as a bug 5 years ago.
>It seems, somebody at MS didn't agree with such definition.
>https://github.com/microsoft/WSL/issues/1748

Following this points to
<https://github.com/microsoft/WSL/issues/830>. And if you read down
that issue, you find that this also affects fork(), and fixing this
"requires some fairly substantial changes to the Windows kernel
itself." This issue also shows that this bug hits lots of people.

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

In article <16su4hdjofh949len5eha1ncb73r4av8oe@4ax.com>,
gneuner2@comcast.net (George Neuner) wrote:

> Since Pentium 4 the compiler has by default used SIMD registers for
> floating point. The x87 is not normally used.

Which compiler? Microsoft Visual Studio is the nearest thing to a default
compiler for Windows. Its x86-64 version has used SSE2 for all floating
point since it first appeared, but that was several years after Pentium 4.
The x86 version became able to compile for SSE2 in VS.2005, and adopted
it as the default in VS.2012, but some versions have used x87 as well as
SSE2 instructions in the same compiles.

> But we were discussing use of the x87 by the quadmath library. The
> library does/did not explicitly set x87 precision, and Michael found
> the default setting under WSL to be wrong.

It is wrong, for accurate emulation of a Linux environment.

> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
> double). Anton gave a more detailed response further down.

Which environment is this in? That is not true for the Visual Studio
compilers.

> And yes, I understand both Michael's and Anton's aversion to
> unnecessary work ... particularly because changing precision on the
> x87 can be very slow. But since the setting can be READ as well as
> written, there is no need to change it if it is correct when the
> library goes to use it.

If you do it that way, you need to read the flags on every entry, and set
them if they need to change. And if you're going to avoid leaking this
setting to other code that may be upset by it, you need to save the old
controls and restore them. It all adds overhead.

John

On Friday, April 8, 2022 at 2:23:19 AM UTC-5, Terje Mathisen wrote:
> Michael S wrote:
> > On Thursday, April 7, 2022 at 10:47:42 PM UTC+3, Terje Mathisen wrote:
> >> Michael S wrote:
> >>> On Thursday, April 7, 2022 at 12:03:32 PM UTC+3, Anton Ertl wrote:
> >>>> We were actually talking about the program that worked nicely on Linux,
> >>>> and failed on WSL.
> >>>>
> >>>
> >>> More I think about it, less I see a justification for WSL control word defaults.
> >> I agree 100%, the WSL setup is simply broken.
> >>>
> >>>> But yes, the library may not be doing what it should do in a program
> >>>> that actively sets the precision to some other values than long
> >>>> double.
> >>>>
> >>>> I can imagine some measures that would deal with the problem in the
> >>>> usual case: E.g., on first invocation the function for setting the
> >>>> precision control changes the vector of the quad-math functions to
> >>>> versions that set the precision control for their own needs (and save
> >>>> and restore the x87 control word). However, that would not work for
> >>>> programs that don't use these functions, but set the control word
> >>>> directly (in assembly language), so unless the library is documented
> >>>> as requiring the function calls for changing the precision control,
> >>>> the library would still be deficient.
> >>>>
> >>>
> >>> In this particular case, the only winning strategy is to refuse to play.
> >>> I.e. quadmath library should be and could be coded without any use of 80-bit
> >>> FP and with very minimalist use of 64-bit FP. On modern 64-bit x86 (and,
> >>> I suppose, on modern ARM and POWER) it's not only the most robust way,
> >>> precision-wise, but also the fastest.
> >> I'm guessing that in real world use there might actually be significant
> >> instances of numbers which happens to fit inside the 80-bit format, but
> >> not in double. In that particular case using 80-bit is obviously a big
> >> win, but this will break down pretty quickly as soon as you do a number
> >> of FMULQs or a single FDIVQ or FSQRTQ.
> >
> > Finding out that result fits in 80 bit and converting back and force will take more
> > time than just doing the work. Pay attention that in common cases of FADD/FSUB/FMUL
> > a work itself, outside of call overhead, parsing inputs and formatting output, is of
> > order of 10 clocks, at worst 15 clocks on less modern cores.
> >
> >>>
> >>> But I can imagine other cases where judicious use of 80-bit FP is really
> >>> beneficiary.
> >> Right.
> >>
> >> The FSQRTQ example is an obvious case, since using 80-bit gives you a
> >> 64-bit mantissa, which after one NR iteration becomes ~128 which will be
> >> correctly rounded in approximately 65535 out 65536 cases, right?
> >>
> >> Doing a full precision back-multiplication, by splitting the 128-bit
> >> mantissa into two parts and squaring it (4 uint64_t 64x64->128 muls)
> >> give you the residual and tells you if the initial result needs to be
> >> adjusted by 1 ulp.
> >
> > I don't think so.
> > Doing rsqrt on x87 with 64-bit precision is not faster than doing
> > it with something like ~63.7 bits on the integer side. More likely, not just not faster,
> > but much slower, esp. when we take into account conversions.
> > And then, for the algorithm that I have in mind, 63.7 or 64 bits are not much better
> > than, say, 61 bit. In both cases on the next step you calculate a result with precision
> > of more than 113 bits, but less than 228 bits required for correct rounding (or is it 227?
>
> Quad uses 1:15:112, so 113 including the hidden bit? I would like to
> have 230 bits to feel perfectly safe, but if it has been proven to work
> with one or two less, that's fine.
<
2×n+3 for (DIV, SQRT, RCP, RSQRT) -> 113×2+3 = 229
<
> > I don't remember). So, after that step we examine the closeness of result to to the mid-point
> > between representable numbers and only when result is close we do additional step
> > which consists of doing the square of the midpoint, calculating only relevant bits and
> > then choosing direction of the rounding according to bit[115] of the square.
> That is a good idea! We don't need the leading 128 bits of the 256-bit
> multiplication result (assuming 64-bit ints here), but that only saves
> one 64x64->128 MUL (plus a few ADD/ADC).
> > With susch algorithm the only difference between 64-bit estimate and 61-bit estimate
> > is the probability of doing the additional step. For 61b probability is low and for 64b it is
> > extremely low. Such difference is unlikely to cause detectable speed difference in real-world
> > usage scenario or even in benchmarks, except when they are intentionally crafted to
> > concentrate on the corner cases.
> Yeah, I agree.
> >
> > When I was talking about judicious use I didn't mean quadmath library at all,
> > but things like solving non-linear equations with double-precision inputs and
> > outputs where you sometimes want better precision on intermediate in order
> > to simplify algorithms and improve stability.
> > May be, something similar can be encountered in matrix factorization when det(A) is
> > small, but here I am less sure.
> OK.
> > In fact, my comment was just an expression of general feeling. It wasn't deeply thought.
> :-)
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Friday, April 8, 2022 at 6:03:53 PM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> > Google helped me to find out that it was reported as a bug 5 years ago.
> >It seems, somebody at MS didn't agree with such definition.
> >https://github.com/microsoft/WSL/issues/1748
> Following this points to
> <https://github.com/microsoft/WSL/issues/830>. And if you read down
> that issue, you find that this also affects fork(), and fixing this
> "requires some fairly substantial changes to the Windows kernel
> itself." This issue also shows that this bug hits lots of people.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Thank you.
It seems, it all would have been much simpler if not for the old belief of kernel devs
that saving FPU context is expensive so the are obliged to be tricky about it.
I think that saving FPU context is less expensive than their clever tricks for at least
12-13 years (approximately since Nehalem on Intel and slightly longer on AMD),
but it's hard to change an established belief.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>This comment seems to think it is due to how fork is implemented:
>In WSL1 the FP control word is maintained across a fork, in Linux it is not.

The other way round. WSL resets the FP control word on fork(), Linux
propagates it.

>https://github.com/microsoft/WSL/issues/830#issuecomment-472279984
>
>Later comments indicate it is fixed in WSL2
>but then others contradict that.

[citation needed] Given that WSL2 runs the Linux kernel in a VM, it is
plausible that WSL2 fixes this. I have not seen any reports that WSL2
does not fix this, only additional requests to also fix this in WSL.

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

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> This comment seems to think it is due to how fork is implemented:
>> In WSL1 the FP control word is maintained across a fork, in Linux it is not.
>
> The other way round. WSL resets the FP control word on fork(), Linux
> propagates it.
>
>> https://github.com/microsoft/WSL/issues/830#issuecomment-472279984

"The symptom indicates the x87 control word is not maintained as part
of the linux process context, it's only in the NT process context."

I read that to mean on fork Linux overwrites FPCW,
WSL does not overwrite and retains the original value.

>>
>> Later comments indicate it is fixed in WSL2
>> but then others contradict that.
>
> [citation needed] Given that WSL2 runs the Linux kernel in a VM, it is
> plausible that WSL2 fixes this. I have not seen any reports that WSL2
> does not fix this, only additional requests to also fix this in WSL.
>
> - anton

The comment that it is fixed in WSL2 is below the above link on 3-Jul.
But below that on 25-Sep it says "people are still hitting this".

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> This comment seems to think it is due to how fork is implemented:
>>> In WSL1 the FP control word is maintained across a fork, in Linux it is not.
>>
>> The other way round. WSL resets the FP control word on fork(), Linux
>> propagates it.
>>
>>> https://github.com/microsoft/WSL/issues/830#issuecomment-472279984
>
>"The symptom indicates the x87 control word is not maintained as part
>of the linux process context, it's only in the NT process context."

luoqi-git showed what actually happens in
<https://github.com/microsoft/WSL/issues/830#issuecomment-472268384>:

|native% ./t
|initial fcw 37f csr 1f80
|parent fcw f7f csr ff80
|thread fcw f7f csr ff80
|child fcw f7f csr ff80
|sigfpe fcw f7b csr fd80
|child exited with status 0
|wsl% ./t
|initial fcw 37f csr 1f80
|parent fcw f7f csr ff80
|thread fcw 27f csr 1f80
|child fcw 27f csr 1f80
|child exited with status 142

I.e., Linux leaves the fcw as-is on fork and thread creation, WSL
changes it.

Not sure if his/her statement you cited was mixed up, or was written
in a way that reading it makes it easy to mix up, but if you read
his/her other statements, it's clear what happens and that he/she
thinks that Linux is POSIX-conformant and WSL is not.

>The comment that it is fixed in WSL2 is below the above link on 3-Jul.
>But below that on 25-Sep it says "people are still hitting this".

That refers to people still using WSL, not WSL2. See also
<https://github.com/microsoft/WSL/issues/830#issuecomment-837200238>
by the same poster:

|A user just hit this again today. So apparently people still are using
|WSL1.

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

Michael S wrote:
> On Friday, April 8, 2022 at 6:03:53 PM UTC+3, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>>> Google helped me to find out that it was reported as a bug 5 years ago.
>>> It seems, somebody at MS didn't agree with such definition.
>>> https://github.com/microsoft/WSL/issues/1748
>> Following this points to
>> <https://github.com/microsoft/WSL/issues/830>. And if you read down
>> that issue, you find that this also affects fork(), and fixing this
>> "requires some fairly substantial changes to the Windows kernel
>> itself." This issue also shows that this bug hits lots of people.
>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
>
> Thank you.
> It seems, it all would have been much simpler if not for the old belief of kernel devs
> that saving FPU context is expensive so the are obliged to be tricky about it.
> I think that saving FPU context is less expensive than their clever tricks for at least
> 12-13 years (approximately since Nehalem on Intel and slightly longer on AMD),
> but it's hard to change an established belief.

Changing and restoring the FPU context was a key part of the FDIV sw
workaround back in 1994/95:

All compilers at the time were modified to either refuse to work on a
broken x87 part, or to include the workaround which I wrote a large part
of, but Tim Coe and Peter Tang did the heavy mathematical lifting to
prove that it would always work:

The code looked like this (pseudo-code):

double fdiv_fix(double a, double b) /* a / b */
{ uint32_t mant = *(uint32_t * &b +4); // Pick top word
mant = (mant >> 10) & 1023; // Top 10 mantissa bits
fpu_load(a); // Put both operands on the FPU stack
fpu_load(b);
// Lookup the mantissa in a 128 byte/1024-bit table
if (bug_table[mant>>3] & (1 << (mant & 7))) { // 5 one bits
old_fpu = get_fpu_env();
set_fpu_env(LONG_DOUBLE); // Force 80-bit mode
fmul(a80,(15/16.0)); // Scale both operands by 15/16, this is exact
fmul(b80,15/16.0);
set_fpu_env(old_fpu); // Restore to typically 64-bit mode
}
fdiv();
}

I.e. if and only if the top 10 mantissa bits happened to hit one of
those 5 (out of 1024) patterns which made it possible for the SRT
divider to hit one of the 5 missing entries, would we run the workaround
code, otehrwise the only overhead was the integer code to extract those
10 bits and check them in the 128-byte table, so typically less than 10
cycles extra for an operation that normally took 40.

If we did get a hit then we used the beautiful trick (I did not come up
with it) of extending precision to 80-bit and then scale both operand by
15/16, both of those FMULs were guaranteed to be exact since we now had
more exponent and mantissa bits available.

Set the mode back to the original and simply drop down into the final
FDIV opcode which would always give the exactly same result as a working
fpu, while using about 80 cycles, so that even for code which did almost
nothing but FDIV the program would not be noticably slower.

Terje

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

On Fri, 8 Apr 2022 16:04 +0100 (BST), jgd@cix.co.uk (John Dallman)
wrote:

>In article <16su4hdjofh949len5eha1ncb73r4av8oe@4ax.com>,
>gneuner2@comcast.net (George Neuner) wrote:
>
>> Since Pentium 4 the compiler has by default used SIMD registers for
>> floating point. The x87 is not normally used.
>
>Which compiler? Microsoft Visual Studio is the nearest thing to a default
>compiler for Windows. Its x86-64 version has used SSE2 for all floating
>point since it first appeared, but that was several years after Pentium 4.
>The x86 version became able to compile for SSE2 in VS.2005, and adopted
>it as the default in VS.2012, but some versions have used x87 as well as
>SSE2 instructions in the same compiles.

32-bit VisualC(++) v6.0. and 64-bit VisualC(++) v4.0 used SSE2 by
default. Both of these were released in Fall 2000 concurrent with
introduction of the Pentium 4.

Prior to v6, the 32-bit compiler used the x87 by default but v5 could
be back-patched to both use SSE2 and generate SSE2 intrinsics.

>> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
>> double). Anton gave a more detailed response further down.
>
>Which environment is this in? That is not true for the Visual Studio
>compilers.

Windows creates processes with the x87 flags set to 64-bit precision.
You can see this if you write your program in assembler or step
through the program startup BEFORE the C runtime mucks with things.

At least through v5, the 32-bit compiler maintained the process
default. At some point the runtime (MSVC.DLL) began changing to
53-bit precision before running user code.

I don't recall when that happened ... I didn't write much 64-bit code
for Windows until ~2010, and the image processing applications I was
working on benefited from integer SIMD but were not much affected by
FPU precision or which FPU was used.

>> And yes, I understand both Michael's and Anton's aversion to
>> unnecessary work ... particularly because changing precision on the
>> x87 can be very slow. But since the setting can be READ as well as
>> written, there is no need to change it if it is correct when the
>> library goes to use it.
>
>If you do it that way, you need to read the flags on every entry, and set
>them if they need to change. And if you're going to avoid leaking this
>setting to other code that may be upset by it, you need to save the old
>controls and restore them. It all adds overhead.

Yes it does.

Changing precision on the x87 does not affect the speed of most FPU
instructions. The problem with doing it is that the FPU pipeline has
to be emptied before the change can happen, so the changeover may be
slow (possibly in both directions).

>John
George

On Saturday, April 9, 2022 at 1:27:09 PM UTC-5, George Neuner wrote:
> On Fri, 8 Apr 2022 16:04 +0100 (BST), j...@cix.co.uk (John Dallman)
> wrote:
> >In article <16su4hdjofh949len...@4ax.com>,
> >gneu...@comcast.net (George Neuner) wrote:
> >
> >> Since Pentium 4 the compiler has by default used SIMD registers for
> >> floating point. The x87 is not normally used.
> >
> >Which compiler? Microsoft Visual Studio is the nearest thing to a default
> >compiler for Windows. Its x86-64 version has used SSE2 for all floating
> >point since it first appeared, but that was several years after Pentium 4.
> >The x86 version became able to compile for SSE2 in VS.2005, and adopted
> >it as the default in VS.2012, but some versions have used x87 as well as
> >SSE2 instructions in the same compiles.
> 32-bit VisualC(++) v6.0. and 64-bit VisualC(++) v4.0 used SSE2 by
> default. Both of these were released in Fall 2000 concurrent with
> introduction of the Pentium 4.
>
> Prior to v6, the 32-bit compiler used the x87 by default but v5 could
> be back-patched to both use SSE2 and generate SSE2 intrinsics.
> >> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
> >> double). Anton gave a more detailed response further down.
> >
> >Which environment is this in? That is not true for the Visual Studio
> >compilers.
> Windows creates processes with the x87 flags set to 64-bit precision.
> You can see this if you write your program in assembler or step
> through the program startup BEFORE the C runtime mucks with things.
>
> At least through v5, the 32-bit compiler maintained the process
> default. At some point the runtime (MSVC.DLL) began changing to
> 53-bit precision before running user code.
>
> I don't recall when that happened ... I didn't write much 64-bit code
> for Windows until ~2010, and the image processing applications I was
> working on benefited from integer SIMD but were not much affected by
> FPU precision or which FPU was used.
> >> And yes, I understand both Michael's and Anton's aversion to
> >> unnecessary work ... particularly because changing precision on the
> >> x87 can be very slow. But since the setting can be READ as well as
> >> written, there is no need to change it if it is correct when the
> >> library goes to use it.
> >
> >If you do it that way, you need to read the flags on every entry, and set
> >them if they need to change. And if you're going to avoid leaking this
> >setting to other code that may be upset by it, you need to save the old
> >controls and restore them. It all adds overhead.
> Yes it does.
>
> Changing precision on the x87 does not affect the speed of most FPU
> instructions. The problem with doing it is that the FPU pipeline has
> to be emptied before the change can happen, so the changeover may be
> slow (possibly in both directions).

<
Bad wording:: it is possible to design a processor that does not HAVE to drain
pipeline to set the mode--Intel has not done so.
<
>
> >John
> George

On Saturday, April 9, 2022 at 11:19:58 PM UTC+3, MitchAlsup wrote:
> On Saturday, April 9, 2022 at 1:27:09 PM UTC-5, George Neuner wrote:
> > On Fri, 8 Apr 2022 16:04 +0100 (BST), j...@cix.co.uk (John Dallman)
> > wrote:
> > >In article <16su4hdjofh949len...@4ax.com>,
> > >gneu...@comcast.net (George Neuner) wrote:
> > >
> > >> Since Pentium 4 the compiler has by default used SIMD registers for
> > >> floating point. The x87 is not normally used.
> > >
> > >Which compiler? Microsoft Visual Studio is the nearest thing to a default
> > >compiler for Windows. Its x86-64 version has used SSE2 for all floating
> > >point since it first appeared, but that was several years after Pentium 4.
> > >The x86 version became able to compile for SSE2 in VS.2005, and adopted
> > >it as the default in VS.2012, but some versions have used x87 as well as
> > >SSE2 instructions in the same compiles.
> > 32-bit VisualC(++) v6.0. and 64-bit VisualC(++) v4.0 used SSE2 by
> > default. Both of these were released in Fall 2000 concurrent with
> > introduction of the Pentium 4.
> >
> > Prior to v6, the 32-bit compiler used the x87 by default but v5 could
> > be back-patched to both use SSE2 and generate SSE2 intrinsics.
> > >> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
> > >> double). Anton gave a more detailed response further down.
> > >
> > >Which environment is this in? That is not true for the Visual Studio
> > >compilers.
> > Windows creates processes with the x87 flags set to 64-bit precision.
> > You can see this if you write your program in assembler or step
> > through the program startup BEFORE the C runtime mucks with things.
> >
> > At least through v5, the 32-bit compiler maintained the process
> > default. At some point the runtime (MSVC.DLL) began changing to
> > 53-bit precision before running user code.
> >
> > I don't recall when that happened ... I didn't write much 64-bit code
> > for Windows until ~2010, and the image processing applications I was
> > working on benefited from integer SIMD but were not much affected by
> > FPU precision or which FPU was used.
> > >> And yes, I understand both Michael's and Anton's aversion to
> > >> unnecessary work ... particularly because changing precision on the
> > >> x87 can be very slow. But since the setting can be READ as well as
> > >> written, there is no need to change it if it is correct when the
> > >> library goes to use it.
> > >
> > >If you do it that way, you need to read the flags on every entry, and set
> > >them if they need to change. And if you're going to avoid leaking this
> > >setting to other code that may be upset by it, you need to save the old
> > >controls and restore them. It all adds overhead.
> > Yes it does.
> >
> > Changing precision on the x87 does not affect the speed of most FPU
> > instructions. The problem with doing it is that the FPU pipeline has
> > to be emptied before the change can happen, so the changeover may be
> > slow (possibly in both directions).
>
> <
> Bad wording:: it is possible to design a processor that does not HAVE to drain
> pipeline to set the mode--Intel has not done so.

As far as I remember, Intel actually did so, at least as long as the change
was only in rounding control bits. I don't remember whether the change in
precision control bits got the same facelift.
The motivation for the change was speeding out double-to-integer conversion
that started to become a bottleneck for one or more of important customers.
Of course, few years later they introduced SSE4.1 that includes ROUNDSD that
performs double-to-integer conversions just fine without messing with rounding
modes, but I think (although never tested) that fast handling of changes of x87
rounding modes still persists in modern Intel processors even despite it is
no longer important.

> <
> >
> > >John
> > George

In article <tmg35h5jeb295i594psbeih9dlrjik3cvs@4ax.com>,
gneuner2@comcast.net (George Neuner) wrote:

> 32-bit VisualC(++) v6.0. and 64-bit VisualC(++) v4.0 used SSE2 by
> default. Both of these were released in Fall 2000 concurrent with
> introduction of the Pentium 4.

You are talking about a quite different history of Visual C++ from me. We
appear to be posting across realities.

In my history, Visual C++ 6 was released in 1998,
<https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#vc6>, and there
wasn't a Visual C++ compiler for 64-bit x86 until Visual C++ 8 in
November 2005.
<https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#32-bit_and_64-bit_
versions> Visual C++ 4 was from 1995, far roo early for 64-bit support.
There were no separate versions for 64-bit x86, with version numbers
duplicating older version numbers.

In my history the Athlon 64 wasn't released until September 2003
<https://en.wikipedia.org/wiki/Athlon_64>, so a Visual C++ targeting
64-bit x86 in 2000 did not happen.

John

On Saturday, April 9, 2022 at 2:19:58 PM UTC-6, MitchAlsup wrote:
> On Saturday, April 9, 2022 at 1:27:09 PM UTC-5, George Neuner wrote:

> > Changing precision on the x87 does not affect the speed of most FPU
> > instructions. The problem with doing it is that the FPU pipeline has
> > to be emptied before the change can happen, so the changeover may be
> > slow (possibly in both directions).

> Bad wording:: it is possible to design a processor that does not HAVE to drain
> pipeline to set the mode--Intel has not done so.

I can't really agree with your criticism; he is talking about the real world, not
hypotheticals.

But I must admit that I am disappointed to hear this.

You have heard the crazy way *I* would have designed a processor. With separate
pipelines for single precision and double precision and quad precision and one-and-a-half
precision.

But if one were to put a 60-bit floating-point number down the double precision pipeline,
no, one would not have to drain it to change the mode. (The double precision pipeline
would actually be designed for 72-bit floats, which would also use it. 80 bit temporary
reals would go down the double precision pipeline, unless there was one for 96-bit
floats.)

So mixing precisions would make your programs go *faster*, because it would utilize
the other pipelines that otherwise would not be used. The very opposite of Intel!

John Savard

On Saturday, April 9, 2022 at 3:52:38 PM UTC-6, John Dallman wrote:
> In article <tmg35h5jeb295i594...@4ax.com>,
> gneu...@comcast.net (George Neuner) wrote:
>
> > 32-bit VisualC(++) v6.0. and 64-bit VisualC(++) v4.0 used SSE2 by
> > default. Both of these were released in Fall 2000 concurrent with
> > introduction of the Pentium 4.
> You are talking about a quite different history of Visual C++ from me. We
> appear to be posting across realities.
>
> In my history, Visual C++ 6 was released in 1998,
> <https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#vc6>, and there
> wasn't a Visual C++ compiler for 64-bit x86 until Visual C++ 8 in
> November 2005.
> <https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#32-bit_and_64-bit_
> versions> Visual C++ 4 was from 1995, far roo early for 64-bit support.
> There were no separate versions for 64-bit x86, with version numbers
> duplicating older version numbers.
>
> In my history the Athlon 64 wasn't released until September 2003
> <https://en.wikipedia.org/wiki/Athlon_64>, so a Visual C++ targeting
> 64-bit x86 in 2000 did not happen.

Just because 32-bit Visual C++ 4.0 was from 1995 doesn't mean that Microsoft
could have released 64-bit Visual C++ 4.0 later. However, I think the actual explanation,
given that the two compilers mentioned were released at the same time, is that he
meant to type "64-bit VisualC(++) v6.0" to match the 32-bit one, and it was a typo.

Much simpler than posting across timelines.

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>You have heard the crazy way *I* would have designed a processor. With separate
>pipelines for single precision and double precision and quad precision and one-and-a-half
>precision.
>
>But if one were to put a 60-bit floating-point number down the double precision pipeline,
>no, one would not have to drain it to change the mode. (The double precision pipeline
>would actually be designed for 72-bit floats, which would also use it. 80 bit temporary
>reals would go down the double precision pipeline, unless there was one for 96-bit
>floats.)
>
>So mixing precisions would make your programs go *faster*, because it would utilize
>the other pipelines that otherwise would not be used. The very opposite of Intel!

In the last weeks I have noticed unusually many people posting
over-long lines (i.e., longer than 80 chars, and ideally you should
limit the lines to 70-72 chars to leave room for quoting). Is there
some new attack on Usenet conventions coming out from Google?

Anyway, my guess for the reason for slow precision-setting is that
Intel and AMD microarchitects want the precision setting to be known
to the decoder, so it can deliver the precision as part of the uop.
This requires that when setting the precision, decoding of subsequent
instructions starts from scratch. An alternative would be to deliver
the precision as another input in the OoO engine, but that would
require additional resources in the OoO engine, an apparently they
thought that spending these resources elsewhere would buy more
performance.

Concerning your separate-pipelines idea, in that setup it's even more
advantageous to know the precision early in instruction processing:
You can have separate queues/ports for the different precisions and
steer the instructions to these ports early, instead of having common
FP queues, and steering the instructions to the right pipelines only
when all the data (including precision) is in; ok, you could also have
two stages of queues, but that introduces additional complication,
area, and probably latency.

Also, even if switching is fast, how frequent is code with mixed
precision? E.g., in DGEMM you only use double precision operations,
while in SGEMM you only use single-precision operations.

Bottom line: There's a reason why Intel and AMD are designing their
CPUs the way they are.

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

On Saturday, April 9, 2022 at 9:27:09 PM UTC+3, George Neuner wrote:
> On Fri, 8 Apr 2022 16:04 +0100 (BST), j...@cix.co.uk (John Dallman)
> wrote:
> >In article <16su4hdjofh949len...@4ax.com>,
> >gneu...@comcast.net (George Neuner) wrote:
> >
> >> Since Pentium 4 the compiler has by default used SIMD registers for
> >> floating point. The x87 is not normally used.
> >
> >Which compiler? Microsoft Visual Studio is the nearest thing to a default
> >compiler for Windows. Its x86-64 version has used SSE2 for all floating
> >point since it first appeared, but that was several years after Pentium 4.
> >The x86 version became able to compile for SSE2 in VS.2005, and adopted
> >it as the default in VS.2012, but some versions have used x87 as well as
> >SSE2 instructions in the same compiles.
> 32-bit VisualC(++) v6.0. and 64-bit VisualC(++) v4.0 used SSE2 by
> default. Both of these were released in Fall 2000 concurrent with
> introduction of the Pentium 4.
>
> Prior to v6, the 32-bit compiler used the x87 by default but v5 could
> be back-patched to both use SSE2 and generate SSE2 intrinsics.

I don't have VS5 or VS6 installed.
[O.T.]
I'd like to have VS5 and it is even moderately important for the maintenance
of one of the old projects, but I don't know where to find it.
[O.T.]
I do have VS2005 (i.e. VS8 if we map it to old numbering scheme).
I tried to compile a following program with default Win32 Release settings:

void GN_test(double* x) {
x[2] = x[0] + x[1];
}

That's what I got:
; Listing generated by Microsoft (R) Optimizing Compiler Version 14.00.50727.762

TITLE d:\michael\George_Neuner_test\gn_test.c
.686P
.XMM
include listing.inc
.model flat

INCLUDELIB OLDNAMES

PUBLIC _GN_test
EXTRN __fltused:DWORD
; Function compile flags: /Ogtpy
; COMDAT _GN_test
_TEXT SEGMENT
_GN_test PROC ; COMDAT
; _x$ = eax
; File d:\michael\george_neuner_test\gn_test.c
; Line 2
fld QWORD PTR [eax+8]
fadd QWORD PTR [eax]
fstp QWORD PTR [eax+16]
; Line 3
ret 0
_GN_test ENDP
END

As you see, it's 100% x87, no traces of SSE2.

Then I tried the same on VS2017 and result was different.
; Listing generated by Microsoft (R) Optimizing Compiler Version 19.16.27032.1

TITLE c:\users\michael_s\work\kuku\george_neuner_test\gn_test\gn_test\gn_test.c
.686P
.XMM
include listing.inc
.model flat

INCLUDELIB OLDNAMES

EXTRN @__security_check_cookie@4:PROC
PUBLIC _GN_test
PUBLIC __xmm@40000000000000003ff0000000000000
EXTRN __fltused:DWORD
; COMDAT __xmm@40000000000000003ff0000000000000
CONST SEGMENT
__xmm@40000000000000003ff0000000000000 DB 00H, 00H, 00H, 00H, 00H, 00H, 0f0H
DB '?', 00H, 00H, 00H, 00H, 00H, 00H, 00H, '@'
CONST ENDS
; Function compile flags: /Ogtp
; COMDAT _GN_test
_TEXT SEGMENT
_GN_test PROC ; COMDAT
; _x$ = ecx
; File c:\users\michael_s\work\kuku\george_neuner_test\gn_test\gn_test\gn_test.c
; Line 2
movsd xmm0, QWORD PTR [ecx+8]
addsd xmm0, QWORD PTR [ecx]
movsd QWORD PTR [ecx+16], xmm0
; Line 3
ret 0
_GN_test ENDP
_TEXT ENDS
END

Here we see SSE2 code.
I don't have other versions of Visual Studio installed right now, so can't be sure when exactly
defaults were changed to SSE2, but it happened at least 3 versions later than you suggested.

> >> WSL aside, on /Windows/ x87 precision defaults to 64-bit (long
> >> double). Anton gave a more detailed response further down.
> >
> >Which environment is this in? That is not true for the Visual Studio
> >compilers.
> Windows creates processes with the x87 flags set to 64-bit precision.
> You can see this if you write your program in assembler or step
> through the program startup BEFORE the C runtime mucks with things.
>
> At least through v5, the 32-bit compiler maintained the process
> default. At some point the runtime (MSVC.DLL) began changing to
> 53-bit precision before running user code.
>
> I don't recall when that happened ... I didn't write much 64-bit code
> for Windows until ~2010, and the image processing applications I was
> working on benefited from integer SIMD but were not much affected by
> FPU precision or which FPU was used.
> >> And yes, I understand both Michael's and Anton's aversion to
> >> unnecessary work ... particularly because changing precision on the
> >> x87 can be very slow. But since the setting can be READ as well as
> >> written, there is no need to change it if it is correct when the
> >> library goes to use it.
> >
> >If you do it that way, you need to read the flags on every entry, and set
> >them if they need to change. And if you're going to avoid leaking this
> >setting to other code that may be upset by it, you need to save the old
> >controls and restore them. It all adds overhead.
> Yes it does.
>
> Changing precision on the x87 does not affect the speed of most FPU
> instructions. The problem with doing it is that the FPU pipeline has
> to be emptied before the change can happen, so the changeover may be
> slow (possibly in both directions).
>
> >John
> George

Anton Ertl wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> You have heard the crazy way *I* would have designed a processor. With separate
>> pipelines for single precision and double precision and quad precision and one-and-a-half
>> precision.
>>
>> But if one were to put a 60-bit floating-point number down the double precision pipeline,
>> no, one would not have to drain it to change the mode. (The double precision pipeline
>> would actually be designed for 72-bit floats, which would also use it. 80 bit temporary
>> reals would go down the double precision pipeline, unless there was one for 96-bit
>> floats.)
>>
>> So mixing precisions would make your programs go *faster*, because it would utilize
>> the other pipelines that otherwise would not be used. The very opposite of Intel!
>
> In the last weeks I have noticed unusually many people posting
> over-long lines (i.e., longer than 80 chars, and ideally you should
> limit the lines to 70-72 chars to leave room for quoting). Is there
> some new attack on Usenet conventions coming out from Google?
>
> Anyway, my guess for the reason for slow precision-setting is that
> Intel and AMD microarchitects want the precision setting to be known
> to the decoder, so it can deliver the precision as part of the uop.
> This requires that when setting the precision, decoding of subsequent
> instructions starts from scratch. An alternative would be to deliver
> the precision as another input in the OoO engine, but that would
> require additional resources in the OoO engine, an apparently they
> thought that spending these resources elsewhere would buy more
> performance.
>
> Concerning your separate-pipelines idea, in that setup it's even more
> advantageous to know the precision early in instruction processing:
> You can have separate queues/ports for the different precisions and
> steer the instructions to these ports early, instead of having common
> FP queues, and steering the instructions to the right pipelines only
> when all the data (including precision) is in; ok, you could also have
> two stages of queues, but that introduces additional complication,
> area, and probably latency.
>
> Also, even if switching is fast, how frequent is code with mixed
> precision? E.g., in DGEMM you only use double precision operations,
> while in SGEMM you only use single-precision operations.
>
> Bottom line: There's a reason why Intel and AMD are designing their
> CPUs the way they are.

The x87 FP Control Word has flags to control
Infinity, Rounding, Precision, and Exception masking.

If you are changing some bits and not others then you have to
store the current value, mask in your changes, and load it FLDCW.
That store can either be synchronous FSTCW or asynchronous FNSTCW
(remember x87 is a separate co-processor with long running
transcendentals, and the FSTCW is actually an assembler macro
instruction which emits FWAIT, FNSTCW).

If any of the exception mask flags change then we may need to
synchronize with current and pending exceptions status.
So this ties changes in the control word into current
and future state in the status register.

Then there is the issue that the new CW is coming from the
data path so to merge the CW bits into the uOp bits in the decoder
implies some kind of front end delay between when the FLDCW decodes
and when the new value propagates back to decode.

An alternatively design merges the FPCW flags into the uOp in the
FPU itself, but then we have to deal with the FP instructions are
launching out-of-order and we have to make sure the right set
of flags goes to the right uOp.
For this I would have a small set physical FPCW registers,
4 should be sufficient, and a renamer for the one logical CW register.
This makes the CW bits a uOp data dependency like other FP operands
and it would require its own wake-up matrix and forwarding bus,
but much simpler than the normal operand support logic.
The then current (future) CW bits merge into the uOp when
it is launched for execution.

With this a write to the FPCW would only stall as long as it took
the new CW value to arrive at its CW physical register or appear
on its forwarding bus, so ideally allowing back-to-back execution.

EricP wrote:
> Anton Ertl wrote:
>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>> You have heard the crazy way *I* would have designed a processor.
>>> With separate
>>> pipelines for single precision and double precision and quad
>>> precision and one-and-a-half
>>> precision.
>>>
>>> But if one were to put a 60-bit floating-point number down the double
>>> precision pipeline,
>>> no, one would not have to drain it to change the mode. (The double
>>> precision pipeline
>>> would actually be designed for 72-bit floats, which would also use
>>> it. 80 bit temporary
>>> reals would go down the double precision pipeline, unless there was
>>> one for 96-bit
>>> floats.)
>>>
>>> So mixing precisions would make your programs go *faster*, because it
>>> would utilize
>>> the other pipelines that otherwise would not be used. The very
>>> opposite of Intel!
>>
>> In the last weeks I have noticed unusually many people posting
>> over-long lines (i.e., longer than 80 chars, and ideally you should
>> limit the lines to 70-72 chars to leave room for quoting). Is there
>> some new attack on Usenet conventions coming out from Google?
>>
>> Anyway, my guess for the reason for slow precision-setting is that
>> Intel and AMD microarchitects want the precision setting to be known
>> to the decoder, so it can deliver the precision as part of the uop.
>> This requires that when setting the precision, decoding of subsequent
>> instructions starts from scratch. An alternative would be to deliver
>> the precision as another input in the OoO engine, but that would
>> require additional resources in the OoO engine, an apparently they
>> thought that spending these resources elsewhere would buy more
>> performance.
>>
>> Concerning your separate-pipelines idea, in that setup it's even more
>> advantageous to know the precision early in instruction processing:
>> You can have separate queues/ports for the different precisions and
>> steer the instructions to these ports early, instead of having common
>> FP queues, and steering the instructions to the right pipelines only
>> when all the data (including precision) is in; ok, you could also have
>> two stages of queues, but that introduces additional complication,
>> area, and probably latency.
>>
>> Also, even if switching is fast, how frequent is code with mixed
>> precision? E.g., in DGEMM you only use double precision operations,
>> while in SGEMM you only use single-precision operations.
>>
>> Bottom line: There's a reason why Intel and AMD are designing their
>> CPUs the way they are.
>
> The x87 FP Control Word has flags to control
> Infinity, Rounding, Precision, and Exception masking.
>
> If you are changing some bits and not others then you have to
> store the current value, mask in your changes, and load it FLDCW.
> That store can either be synchronous FSTCW or asynchronous FNSTCW
> (remember x87 is a separate co-processor with long running
> transcendentals, and the FSTCW is actually an assembler macro
> instruction which emits FWAIT, FNSTCW).
>
> If any of the exception mask flags change then we may need to
> synchronize with current and pending exceptions status.
> So this ties changes in the control word into current
> and future state in the status register.
>
> Then there is the issue that the new CW is coming from the
> data path so to merge the CW bits into the uOp bits in the decoder
> implies some kind of front end delay between when the FLDCW decodes
> and when the new value propagates back to decode.
>
> An alternatively design merges the FPCW flags into the uOp in the
> FPU itself, but then we have to deal with the FP instructions are
> launching out-of-order and we have to make sure the right set
> of flags goes to the right uOp.
> For this I would have a small set physical FPCW registers,
> 4 should be sufficient, and a renamer for the one logical CW register.
> This makes the CW bits a uOp data dependency like other FP operands
> and it would require its own wake-up matrix and forwarding bus,
> but much simpler than the normal operand support logic.
> The then current (future) CW bits merge into the uOp when
> it is launched for execution.
>
> With this a write to the FPCW would only stall as long as it took
> the new CW value to arrive at its CW physical register or appear
> on its forwarding bus, so ideally allowing back-to-back execution.

This would also need something to handle the FP Status Word
which contains the sticky exception flags.
The implied OR of the uOp status with the current status
creates a serial dependency that we'd need to break up.

It is not the same as the integer status flags because those
flags overwrite the prior values so a rename can handle them.

Whereas each FP exception bit has to OR with its prior state
and then merge with that uOps exception mask bits to
decide whether to throw and exception.
So a simple renamer for the FPSW wouldn't suffice.