On 19 November 2012 06:06, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 11/18/2012 4:23 PM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Actually, they probably will. People using it will need to use it regardless of<br>
how it's implemented. Hardware support it great when available, but<br>
realistically, it's used when processing data for execution on another processor<br>
that does support it in hardware (typically a GPU). Use of fp16 is probably not<br>
optional; it doubles your bandwidth wherever the loss of precision is acceptable.<br>
</blockquote>
<br></div>
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.<br></blockquote><div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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?).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If it is a storage-only format, then what role do implicit conversions play?<br>

</blockquote></div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>