half datatype?

Manu turkeyman at gmail.com
Mon Nov 19 07:48:13 PST 2012


On 19 November 2012 06:06, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 11/18/2012 4:23 PM, Manu wrote:
>
>> Actually, they probably will. People using it will need to use it
>> regardless of
>> how it's implemented. Hardware support it great when available, but
>> realistically, it's used when processing data for execution on another
>> processor
>> that does support it in hardware (typically a GPU). Use of fp16 is
>> probably not
>> optional; it doubles your bandwidth wherever the loss of precision is
>> acceptable.
>>
>
> Doing implicit conversions on them implies doing them on the x86 CPU,
> which has no hardware support for the type. All operations would require
> software emulation.
>

It would just make the experience seamless, and also implement the expected
casting/data-loss rules. It's the type safety/casting rules that I find
most valuable, and the ability to use them in templates without
specialising the half path.

I guess it would be nicer/simpler to perform actual work as floats and then
re-pack it on write back, rather than emulating all the operations in half
space. This wouldn't strictly retain half precision though, it would be
slightly higher precision since the intermediates were full precision
(which is surely preferable?).

If it is a storage-only format, then what role do implicit conversions play?
>

It saves pack/unpack calls whenever interacting with them in structs or
streams, which helps generic code. And also encourages use of the type in
structs, as it is not an 'inconvenience' as such. Where I'm from,
memory/bandwidth is often far more scarce than processing time.
x86 can do half conversion fairly efficiently (about 5 opcodes, possibly
one of the reasons it hasn't found it's way into SSE yet). But it's no
surprise that platforms like ARM implemented the conversion operations in
hardware, there's no time to waste on mobile devices.

I've also seen a few threads on this forum before about people targeting
GPU backends to do GPGPU processing with D. Has that ever actually been
used? Found useful in practise?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121119/c10ec255/attachment-0001.html>


More information about the Digitalmars-d mailing list