November 23, 2012
On 11/22/2012 7:03 PM, xenon325 wrote:
> I would think it's actually not preferable.
> Imagine you developed and tuned all the code on x86 and everything is fine. Then
> run it on ARM and suddenly all computations are inaccurate.

Floating point algorithms don't get less precise when precision is increased. I can't think of any.

November 23, 2012
On 23 November 2012 05:03, xenon325 <1@a.net> wrote:

> On Monday, 19 November 2012 at 15:48:23 UTC, Manu wrote:
>
>> This wouldn't strictly retain half precision though, it would be slightly higher precision since the intermediates were full precision (which is surely preferable?).
>>
>
> I would think it's actually not preferable.
> Imagine you developed and tuned all the code on x86 and everything is
> fine. Then run it on ARM and suddenly all computations are inaccurate.
>

I think it would always be the case that work is done in float space,
hardware support for half applies to fast load/store into full float
registers. You would lose precision too fast if work were done directly in
half space.
Most CPU's also apply this principle to integer work. It's typical to load
a byte/short into a 32/64bit register and sign extend or zero extend, then
all integer work is done in the maximum integer precision, and store then
truncates the top bits again. Many older FPU's work this way too.


November 26, 2012
On Friday, 23 November 2012 at 09:08:53 UTC, Manu wrote:
> On 23 November 2012 05:03, xenon325 <1@a.net> wrote:
>
>> On Monday, 19 November 2012 at 15:48:23 UTC, Manu wrote:
>>
>>> This wouldn't strictly retain half precision though, it would be
>>> slightly higher precision since the intermediates were full precision
>>> (which is surely preferable?).
>>>
>>
>> I would think it's actually not preferable.
>> Imagine you developed and tuned all the code on x86 and everything is
>> fine. Then run it on ARM and suddenly all computations are inaccurate.
>>
>
> I think it would always be the case that work is done in float space,
> hardware support for half applies to fast load/store into full float
> registers. You would lose precision too fast if work were done directly in
> half space.
> Most CPU's also apply this principle to integer work. It's typical to load
> a byte/short into a 32/64bit register and sign extend or zero extend, then
> all integer work is done in the maximum integer precision, and store then
> truncates the top bits again. Many older FPU's work this way too.

Then it's ok, of course. Thanks for explaining!
November 26, 2012
On Friday, 23 November 2012 at 06:10:38 UTC, Walter Bright wrote:
> On 11/22/2012 7:03 PM, xenon325 wrote:
>> I would think it's actually not preferable.
>> Imagine you developed and tuned all the code on x86 and everything is fine. Then
>> run it on ARM and suddenly all computations are inaccurate.
>
> Floating point algorithms don't get less precise when precision is increased. I can't think of any.

Actually I meant opposite: on x86 you would work with (kind of) 32-bit `half` and on ARM with 16-bit.

Then, suppose I did math analysis, and picked up algorithms which *should* work correctly, but I have missed something and for 0.01% of input rounding error is too big on 16-bits, but invisible on 32-bits.

If I develop on x86 (with 32-bit precision) and run my app on ARM (16-bit precision), than I'm messed up.

Anyway all this beside the point, as Manu have explained me in other reply.
1 2
Next ›   Last »