--0000000000008396080577fb9735
Content-Type: text/plain; charset="UTF-8"

On Wed, 10 Oct 2018 at 18:40 Niall Douglas <nialldouglas14@gmail.com> wrote:

>
>> I only know of one compiler that has some implementation of this TR's
>> fixed point types - that is gcc, which implements it on some targets.  I
>> have tried it, and the code generated is hopeless despite the target
>> processor having support for some fixed point formats.  It is basically
>> a matter of a gcc developer in the past having implemented the front-end
>> parts and very basic code generation, presumably with the intention that
>> others would pick up the ball and turn it into more optimal code now
>> that the process had been started.  However, it has seen no interest
>> (AFAIK) from either compiler developers or users.
>>
>> Useful to learn, thanks.
>

Yes, thanks David. I feel I now have a better idea of why it's so hard to
find any information about N1169 online.

Mostly so it's noted somewhere, I'll go ahead and try to compare the C++
solutions (P0106 and P0037) with N1169 in depth. I will doubtless get some
facts wrong...
- P0106 and P0037 are library-based abstractions over integer-like types
such as the fundamental types. N1169 aims to provide fundamental types
which are an abstraction over registers and instructions found in DSPs,
FPGAs etc..
- P0106 and P0037 (to varying extents) provide lossless arithmetic
operations (because they are based on integers which also perform many
operations losslessly). N1169's arithmetic operations right-shift their
results eagerly to match the operand types (because that's really all you
can do with C's type system) and so drop low bits routinely.
- This means that if you don't have said processor features, N1169 has you
paying for those shifts whether you use them or not. You often do need them
and P0106 and P0037 provide them but only when you are expressly doing
something like assigning back to the operand type.
- The downside is that you need wider results for intermediate types --
especially for multiplication -- which N1169 would take care of 'under the
hood'.
- N1169 also offers some support for rounding and overflow -- the intention
being to harness those processor features. P0037 sidesteps those issues and
P0106 supports them in software or hardware (but most likely software).
- N1169's approach is to under-specify its types in order to account for
the fact that hardware support varies so much. I guess the intent was to
follow `int`'s example of being different (e.g. in width) from platform to
platform. But there are more and greater differences in fixed-point
hardware. P0106 hides all such details and lets the user chose the exact
range and resolution (effectively integer and fractional bit counts) to
ensure that behaviour is predictable across different implementations.
P0037, again, sidesteps this issue by allowing the user to choose the
backing type. If they choose the <cstdint> types, they can largely iron out
those differences. N1169 doesn't even appear to be compatible with
<stdint.h>'s aliases.

I tried to come up with some examples of P0037 out-performing N1169 in
terms of codegen but without using the exotic fixed-point hardware for
which N1169 is designed, the results don't seem very fair. Here is a circle
intersection test
using P0037 https://gcc.godbolt.org/z/BqxsbS
and N1169 https://gcc.godbolt.org/z/pGRmZU.

The N1169 code eagerly shifts the values which helps avoid overflow but
reduces precision. The P0037 solution relies on integer promotion to avoid
overflow and so is more resource hungry (32-bit values!) but also more
precise. It is a feature of P0037 that you have this control. You can widen
intermediate types yourself when promotion fails you or you can use the
P0828 type and stop worrying about intermediate width. P0106 does something
similar.

I'm not convinced that if I revised P0037 in the future that it would
really help to add this info but I'm happy to do so.

John

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnSuOP4JFTCGsu7qAnSZQ8HKNADUk5jqC2YfJKO9J0KhqQ%40mail.gmail.com.

--0000000000008396080577fb9735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, 10 Oct=
 2018 at 18:40 Niall Douglas &lt;<a href=3D"mailto:nialldouglas14@gmail.com=
">nialldouglas14@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>I only =
know of one compiler that has some implementation of this TR&#39;s
<br>fixed point types - that is gcc, which implements it on some targets.=
=C2=A0 I
<br>have tried it, and the code generated is hopeless despite the target
<br>processor having support for some fixed point formats.=C2=A0 It is basi=
cally
<br>a matter of a gcc developer in the past having implemented the front-en=
d
<br>parts and very basic code generation, presumably with the intention tha=
t
<br>others would pick up the ball and turn it into more optimal code now
<br>that the process had been started.=C2=A0 However, it has seen no intere=
st
<br>(AFAIK) from either compiler developers or users.
<br>
<br></blockquote></div><div dir=3D"ltr"><div>Useful to learn, thanks.</div>=
</div></blockquote><div><br></div><div>Yes, thanks David. I feel I now have=
 a better idea of why it&#39;s so hard to find any information about N1169 =
online. <br></div><div><br></div><div>Mostly so it&#39;s noted somewhere, I=
&#39;ll go ahead and try to compare the C++ solutions=20

(P0106 and P0037) with N1169 in depth. I will doubtless get some facts wron=
g...<br></div><div>- P0106 and P0037 are library-based abstractions over in=
teger-like types such as the fundamental types. N1169 aims to provide funda=
mental types which are an abstraction over registers and instructions found=
 in DSPs, FPGAs etc..</div><div>- P0106 and P0037 (to varying extents) prov=
ide lossless arithmetic operations (because they are based on integers whic=
h also perform many operations losslessly). N1169&#39;s arithmetic operatio=
ns right-shift their results eagerly to match the operand types (because th=
at&#39;s really all you can do with C&#39;s type system) and so drop low bi=
ts routinely.</div><div>- This means that if you don&#39;t have said proces=
sor features, N1169 has you paying for those shifts whether you use them or=
 not. You often do need them and P0106 and P0037 provide them but only when=
 you are expressly

doing something like assigning back to the operand type.</div><div>- The do=
wnside is that you need wider results for intermediate types -- especially =
for multiplication -- which N1169 would take care of &#39;under the hood&#3=
9;. <br></div><div>- N1169 also offers some support for rounding and overfl=
ow -- the intention being to harness those processor features. P0037 sidest=
eps those issues and P0106 supports them in software or hardware (but most =
likely software).</div><div>- N1169&#39;s approach is to under-specify its =
types in order to account for the fact that hardware support varies so much=
.. I guess the intent was to follow `int`&#39;s example of being different (=
e.g. in width) from platform to platform. But there are more and greater di=
fferences in fixed-point hardware. P0106 hides all such details and lets th=
e user chose the exact range and resolution (effectively integer and fracti=
onal bit counts) to ensure that behaviour is predictable across different i=
mplementations. P0037, again, sidesteps this issue by allowing the user to =
choose the backing type. If they choose the &lt;cstdint&gt; types, they can=
 largely iron out those differences. N1169 doesn&#39;t even appear to be co=
mpatible with &lt;stdint.h&gt;&#39;s aliases.<br></div></div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">I tried to come up with s=
ome examples of P0037 out-performing N1169 in terms of codegen but without =
using the exotic fixed-point hardware for which N1169 is designed, the resu=
lts don&#39;t seem very fair. Here is a circle intersection test</div><div =
class=3D"gmail_quote">using P0037 <a href=3D"https://gcc.godbolt.org/z/Bqxs=
bS">https://gcc.godbolt.org/z/BqxsbS</a></div><div class=3D"gmail_quote">an=
d N1169 <a href=3D"https://gcc.godbolt.org/z/pGRmZU">https://gcc.godbolt.or=
g/z/pGRmZU</a>.</div><div class=3D"gmail_quote"><br></div><div class=3D"gma=
il_quote">The N1169 code eagerly shifts the values which helps avoid overfl=
ow but reduces precision. The P0037 solution relies on integer promotion to=
 avoid overflow and so is more resource hungry (32-bit values!) but also mo=
re precise. It is a feature of P0037 that you have this control. You can wi=
den intermediate types yourself when promotion fails you or you can use the=
 P0828 type and stop worrying about intermediate width. P0106 does somethin=
g similar.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">I&#39;m not convinced that if I revised P0037 in the future that it wo=
uld really help to add this info but I&#39;m happy to do so.<br></div><div =
class=3D"gmail_quote"><div><br></div><div>John<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnSuOP4JFTCGsu7qAnSZQ8HKNADUk5jq=
C2YfJKO9J0KhqQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnSuOP4JFTCG=
su7qAnSZQ8HKNADUk5jqC2YfJKO9J0KhqQ%40mail.gmail.com</a>.<br />

--0000000000008396080577fb9735--

.

------=_Part_643_1354996598.1539332758211
Content-Type: multipart/alternative;
 boundary="----=_Part_644_2118781653.1539332758211"

------=_Part_644_2118781653.1539332758211
Content-Type: text/plain; charset="UTF-8"


>
>
> I tried to come up with some examples of P0037 out-performing N1169 in
> terms of codegen but without using the exotic fixed-point hardware for
> which N1169 is designed, the results don't seem very fair. Here is a circle
> intersection test
> using P0037 https://gcc.godbolt.org/z/BqxsbS
> and N1169 https://gcc.godbolt.org/z/pGRmZU.
>
> The N1169 code eagerly shifts the values which helps avoid overflow but
> reduces precision. The P0037 solution relies on integer promotion to avoid
> overflow and so is more resource hungry (32-bit values!) but also more
> precise. It is a feature of P0037 that you have this control. You can widen
> intermediate types yourself when promotion fails you or you can use the
> P0828 type and stop worrying about intermediate width. P0106 does something
> similar.
>
> I'm not convinced that if I revised P0037 in the future that it would
> really help to add this info but I'm happy to do so.
>
> I find the above compelling proof that P0037 is much superior. The codegen
for P0037 is much better. And P0037 is much more flexible.

The reason I raised all this is because I was aghast at how poor codegen
library based extended precision integers generate. I've tried a number of
implementation libraries now, they are all far inferior to compiler based
for the 128 bit integer case. And I find that important - some will argue
that future compilers will optimise better, but I have found that a
crapshoot in the past. Far better to standardise based on existing
optimiser tech, then we know for sure.

Anyway I preempt my paper. Thanks John for all the detail.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0213513-b2b7-40ee-a2bb-9a3103d65427%40isocpp.org.

------=_Part_644_2118781653.1539332758211
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div><br></div></div><div class=3D"gmail_quote">I tried to co=
me up with some examples of P0037 out-performing N1169 in terms of codegen =
but without using the exotic fixed-point hardware for which N1169 is design=
ed, the results don&#39;t seem very fair. Here is a circle intersection tes=
t</div><div class=3D"gmail_quote">using P0037 <a href=3D"https://gcc.godbol=
t.org/z/BqxsbS" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.godbolt.org%2Fz%2=
FBqxsbS\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHsY8XGPZvUWVkGVaeYaulmH99E6=
g&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url=
?q\x3dhttps%3A%2F%2Fgcc.godbolt.org%2Fz%2FBqxsbS\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNHsY8XGPZvUWVkGVaeYaulmH99E6g&#39;;return true;">https://gcc.g=
odbolt.org/z/<wbr>BqxsbS</a></div><div class=3D"gmail_quote">and N1169 <a h=
ref=3D"https://gcc.godbolt.org/z/pGRmZU" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2=
F%2Fgcc.godbolt.org%2Fz%2FpGRmZU\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFR=
PqBsUYOb-YPn128O1RLmrLMWpA&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.godbolt.org%2Fz%2FpGRmZU\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFRPqBsUYOb-YPn128O1RLmrLMWpA&#39;;re=
turn true;">https://gcc.godbolt.org/z/<wbr>pGRmZU</a>.</div><div class=3D"g=
mail_quote"><br></div><div class=3D"gmail_quote">The N1169 code eagerly shi=
fts the values which helps avoid overflow but reduces precision. The P0037 =
solution relies on integer promotion to avoid overflow and so is more resou=
rce hungry (32-bit values!) but also more precise. It is a feature of P0037=
 that you have this control. You can widen intermediate types yourself when=
 promotion fails you or you can use the P0828 type and stop worrying about =
intermediate width. P0106 does something similar.</div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">I&#39;m not convinced that if I=
 revised P0037 in the future that it would really help to add this info but=
 I&#39;m happy to do so.<br></div><div class=3D"gmail_quote"><div><br></div=
></div></div></blockquote><div>I find the above compelling proof that P0037=
 is much superior. The codegen for P0037 is much better. And P0037 is much =
more flexible.</div><div><br></div><div>The reason I raised all this is bec=
ause I was aghast at how poor codegen library based extended precision inte=
gers generate. I&#39;ve tried a number of implementation libraries now, the=
y are all far inferior to compiler based for the 128 bit integer case. And =
I find that important - some will argue that future compilers will optimise=
 better, but I have found that a crapshoot in the past. Far better to stand=
ardise based on existing optimiser tech, then we know for sure.</div><div><=
br></div><div>Anyway I preempt my paper. Thanks John for all the detail.</d=
iv><div><br></div><div>Niall</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0213513-b2b7-40ee-a2bb-9a3103d65427%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a0213513-b2b7-40ee-a2bb-9a3103d65427=
%40isocpp.org</a>.<br />

------=_Part_644_2118781653.1539332758211--

------=_Part_643_1354996598.1539332758211--

.