www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - half datatype?

reply Manu <turkeyman gmail.com> writes:
I've often wondered about having an official 'half' type.
It's very common in rendering/image processing, supported by most video
cards (so compression routines interacting with this type are common), and
it's also supported in hardware by some cpu's.

ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
which would map nicely if D supported the type in the front end.

The alternative us to use ushort everywhere, which is awkward, because it
is neither unsigned, nor is it an integer, and it's not typesafe (allows
direct assignment to ints and stuff)...
It would be nice if: cast(half)someFloat would yield the proper value, even
if it is performed in software in most architectures, it could be mapped to
hardware for those that do it.

It could be done in a library, but then GCC couldn't map it properly to the
hardware type, and since D has no way to describe implicit casts (that I
know of?) it becomes awkward to use.
someFloat = someHalf <- doesn't work, because a cast operator expects an
explicit cast, even though this is a lossless conversion and should be
exactly the same as someDouble = someFloat.

Thoughts?
Nov 18 2012
next sibling parent "Zoadian" <github zoadian.de> writes:
+1

i'm using halffloat regularly, would be nice to have them builtin.
Nov 18 2012
prev sibling next sibling parent "ponce" <spam spam.org> writes:
I tend to agree with your aguments, because the half type could
be very useful to reduce memory usage of data stored as float for
lack of a smaller type.


 The alternative us to use ushort everywhere, which is awkward, 
 because it
 is neither unsigned, nor is it an integer, and it's not 
 typesafe (allows
 direct assignment to ints and stuff)...


For better or worse, you can use a wrapper type around this
ushort:
https://github.com/p0nce/gfm/blob/master/math/half.d


 It would be nice if: cast(half)someFloat would yield the proper 
 value, even
 if it is performed in software in most architectures, it could 
 be mapped to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it 
 properly to the
 hardware type, and



 since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator 
 expects an
 explicit cast, even though this is a lossless conversion and 
 should be
 exactly the same as someDouble = someFloat.


When I first implemented half floats in D I came to the same
conclusion. Built-ins types have implicit conversion but one
can't define new ones.

Yet it's a trade-off probably choosen for good reasons. How to
make sure people won't abuse them? What to do with chained
implicit conversions?
Nov 18 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

 someFloat = someHalf <- doesn't work, because a cast operator 
 expects an
 explicit cast, even though this is a lossless conversion and 
 should be
 exactly the same as someDouble = someFloat.

 Thoughts?


---
struct Half {
     float toFloat() { return 3.14f; }
     alias toFloat this;
}

void test() {
     Half h;
     float f = h;
     double d = h;
}
---

Works for you?

David
Nov 18 2012
parent reply Manu <turkeyman gmail.com> writes:
On 18 November 2012 14:01, David Nadlinger <see klickverbot.at> wrote:


 On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:


 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?


 ---
 struct Half {
     float toFloat() { return 3.14f; }
     alias toFloat this;
 }

 void test() {
     Half h;
     float f = h;
     double d = h;
 }
 ---

 Works for you?



Interesting approach to the implicit cast problem. Very handy trick.
Nov 18 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/12 7:30 AM, Manu wrote:

 On 18 November 2012 14:01, David Nadlinger <see klickverbot.at
 <mailto:see klickverbot.at>> wrote:

     On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

         someFloat = someHalf <- doesn't work, because a cast operator
         expects an
         explicit cast, even though this is a lossless conversion and
         should be
         exactly the same as someDouble = someFloat.

         Thoughts?


     ---
     struct Half {
          float toFloat() { return 3.14f; }
          alias toFloat this;
     }

     void test() {
          Half h;
          float f = h;
          double d = h;
     }
     ---

     Works for you?


 Interesting approach to the implicit cast problem. Very handy trick.


Well that was quite explicitly part of the purpose of alias this.

Andrei
Nov 18 2012
next sibling parent Manu <turkeyman gmail.com> writes:
I'm sure that's true, I've just always used it to gain access to members of
embedded types, kinda of like abstraction for 'struct's. It hadn't occurred
to me to support explicit casting in that way.


On 18 November 2012 18:31, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/18/12 7:30 AM, Manu wrote:


 On 18 November 2012 14:01, David Nadlinger <see klickverbot.at

 <mailto:see klickverbot.at>> wrote:

     On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

         someFloat = someHalf <- doesn't work, because a cast operator
         expects an
         explicit cast, even though this is a lossless conversion and
         should be
         exactly the same as someDouble = someFloat.

         Thoughts?


     ---
     struct Half {
          float toFloat() { return 3.14f; }
          alias toFloat this;
     }

     void test() {
          Half h;
          float f = h;
          double d = h;
     }
     ---

     Works for you?


 Interesting approach to the implicit cast problem. Very handy trick.


 Well that was quite explicitly part of the purpose of alias this.

 Andrei
Nov 18 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 19 November 2012 01:58, Manu <turkeyman gmail.com> wrote:


 I'm sure that's true, I've just always used it to gain access to members
 of embedded types, kinda of like abstraction for 'struct's. It hadn't
 occurred to me to support explicit casting in that way.



**cough** IMPLICIT casting.

On 18 November 2012 18:31, Andrei Alexandrescu <

 SeeWebsiteForEmail erdani.org> wrote:


 On 11/18/12 7:30 AM, Manu wrote:


 On 18 November 2012 14:01, David Nadlinger <see klickverbot.at

 <mailto:see klickverbot.at>> wrote:

     On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

         someFloat = someHalf <- doesn't work, because a cast operator
         expects an
         explicit cast, even though this is a lossless conversion and
         should be
         exactly the same as someDouble = someFloat.

         Thoughts?


     ---
     struct Half {
          float toFloat() { return 3.14f; }
          alias toFloat this;
     }

     void test() {
          Half h;
          float f = h;
          double d = h;
     }
     ---

     Works for you?


 Interesting approach to the implicit cast problem. Very handy trick.


 Well that was quite explicitly part of the purpose of alias this.

 Andrei
Nov 18 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/18/2012 3:21 PM, Manu пишет:

 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.


I guess half(someFloat) will do for conversion.


 It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.


alias this should work.
Just tried it, works wonders:

import std.math;

struct half{
     ushort data; //this one should be __fp16 where it works
//other overloaded ops, etc.

     alias getFloat this;
     //***only for the purpose of showing implicit conversion ***
     float getFloat(){ return data * 0.1; }
}

void main(){
     float x = half(12);
     assert(abs(x - 1.2) < 1e-6);
}


 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?


Everything but hardware support is doable as is. I'm not sure if it's 
possible and/or feasible to make _efficient_ wrapper type that uses 
hardware support.

The easiest path seems to be:
- convince GDC to add __fp16 type as an extension that maps to GCC's one
- use it on GDC, and fallback to emulation on DMD

That being said I personally have no objections to add half type to 
built-ins in DMD.

-- 
Dmitry Olshansky
Nov 18 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 November 2012 14:13, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 11/18/2012 3:21 PM, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:


 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.


 I guess half(someFloat) will do for conversion.



How do you define 'will do'? It still behaves differently than proper types=
.
someFloat =3D someDouble without a cast is a compile error, likewise should
be true in this case, but I don't know how to do that.
someHalf =3D someFloat should require an explicit cast too, or use a 1.0h
literal ;)

It could be done in a library, but then GCC couldn't map it properly to

 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.


 alias this should work.
 Just tried it, works wonders:

 import std.math;

 struct half{
     ushort data; //this one should be __fp16 where it works
 //other overloaded ops, etc.

     alias getFloat this;
     //***only for the purpose of showing implicit conversion ***
     float getFloat(){ return data * 0.1; }
 }

 void main(){
     float x =3D half(12);
     assert(abs(x - 1.2) < 1e-6);

 }


Yup, that solves the up-cast problem perfectly! I didn't think of that
trick.

someFloat =3D someHalf <- doesn't work, because a cast operator expects an

 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble =3D someFloat.

 Thoughts?


 Everything but hardware support is doable as is. I'm not sure if it's
 possible and/or feasible to make _efficient_ wrapper type that uses
 hardware support.

 The easiest path seems to be:
 - convince GDC to add __fp16 type as an extension that maps to GCC's one
 - use it on GDC, and fallback to emulation on DMD

 That being said I personally have no objections to add half type to
 built-ins in DMD.



I'm sure it's already accessible in GDC, but it's not portable unless it
gets a proper name in the front end.
The point would be to name the type, add the conversion functions to
druntime for fallback/portability, and a literal 1.0h would be handy to
identify the type to templates.
Nov 18 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/18/2012 4:41 PM, Manu пишет:

         The alternative us to use ushort everywhere, which is awkward,
         because
         it is neither unsigned, nor is it an integer, and it's not typesafe
         (allows direct assignment to ints and stuff)...
         It would be nice if: cast(half)someFloat would yield the proper
         value,
         even if it is performed in software in most architectures, it
         could be
         mapped to hardware for those that do it.


     I guess half(someFloat) will do for conversion.


 How do you define 'will do'? It still behaves differently than proper types.
 someFloat = someDouble without a cast is a compile error, likewise
 should be true in this case, but I don't know how to do that.
 someHalf = someFloat should require an explicit cast too, or use a 1.0h
 literal ;)


The point was it does now. Wrapper struct doesn't accept direct 
assignments from float (unless you want it to and defined opAssign to do 
that).

alias this trick makes it magical r-value of type float where it makes 
sense. Obviously on assignment it doesn't ;)

In code:
half myHalf = half(1.23);
myHalf = 35; //doesn't compile
myHalf = half(35); //works

The example though demonstrates one painful limitation of a wrapper - 
no value range propagation. Basically since 35 fits into a half, no 
explicit cast should be needed.

And that's a big deal sometimes:
ubyte flags = 0x80 | 0x40; //no casts, thank God


     Everything but hardware support is doable as is. I'm not sure if
     it's possible and/or feasible to make _efficient_ wrapper type that
     uses hardware support.

     The easiest path seems to be:
     - convince GDC to add __fp16 type as an extension that maps to GCC's one
     - use it on GDC, and fallback to emulation on DMD

     That being said I personally have no objections to add half type to
     built-ins in DMD.


 I'm sure it's already accessible in GDC,


Good to know.


 The point would be to name the type, add the conversion functions to
 druntime for fallback/portability, and a literal 1.0h would be handy to
 identify the type to templates.


Mmm the literal. Dunno but '1h' looks like 1 hour to me :)

Another trick to pull is to use UFCS:

 property auto hf(T)(T value)
if(isFloatingPoint!T || isIntegral!T)
{
	return half(value);
}

Then 1.0.hf && 32.hf both should work. Not as nice as true suffix but 
damn close.


-- 
Dmitry Olshansky
Nov 18 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 November 2012 12:41, Manu <turkeyman gmail.com> wrote:

 On 18 November 2012 14:13, Dmitry Olshansky <dmitry.olsh gmail.com> wrote=


:

 11/18/2012 3:21 PM, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.



 I guess half(someFloat) will do for conversion.



 How do you define 'will do'? It still behaves differently than proper typ=


es.

 someFloat =3D someDouble without a cast is a compile error, likewise shou=


ld be

 true in this case, but I don't know how to do that.
 someHalf =3D someFloat should require an explicit cast too, or use a 1.0h
 literal ;)


 It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.



 alias this should work.
 Just tried it, works wonders:

 import std.math;

 struct half{
     ushort data; //this one should be __fp16 where it works
 //other overloaded ops, etc.

     alias getFloat this;
     //***only for the purpose of showing implicit conversion ***
     float getFloat(){ return data * 0.1; }
 }

 void main(){
     float x =3D half(12);
     assert(abs(x - 1.2) < 1e-6);

 }



 Yup, that solves the up-cast problem perfectly! I didn't think of that
 trick.


 someFloat =3D someHalf <- doesn't work, because a cast operator expects=






 an

 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble =3D someFloat.

 Thoughts?



 Everything but hardware support is doable as is. I'm not sure if it's
 possible and/or feasible to make _efficient_ wrapper type that uses hard=




ware

 support.

 The easiest path seems to be:
 - convince GDC to add __fp16 type as an extension that maps to GCC's one
 - use it on GDC, and fallback to emulation on DMD

 That being said I personally have no objections to add half type to
 built-ins in DMD.



 I'm sure it's already accessible in GDC, but it's not portable unless it
 gets a proper name in the front end.
 The point would be to name the type, add the conversion functions to
 druntime for fallback/portability, and a literal 1.0h would be handy to
 identify the type to templates.


The two modes guaranteed to exist in GDC are single and double (reals
could be a vagarity of sizes).  Half I believe is only defined
(internally) for ARM.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Nov 18 2012
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman gmail.com> wrote:


 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common), and
 it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
 which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because it
 is neither unsigned, nor is it an integer, and it's not typesafe (allows
 direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value, even
 if it is performed in software in most architectures, it could be mapped to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to the
 hardware type, and since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?


Vote--.

The a half data type is already part of std.numeric. From the docs:

// Define a 16-bit floating point values
    CustomFloat!16                                x;     // Using the number of
bits
    CustomFloat!(10, 5)                           y;     // Using the precision
and exponent width
    CustomFloat!(10, 5,CustomFloatFlags.ieee)     z;     // Using the
precision, exponent width and format flags
    CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w;     // Using the
precision, exponent width, format flags and exponent offset bias

    // Use the 16-bit floats mostly like normal numbers
    w = x*y - 1;
    writeln(w);

    // Functions calls require conversion
    z = sin(+x)           + cos(+y);                     // Use uniary plus to
concisely convert to a real
    z = sin(x.re)         + cos(y.re);                   // Or use the .re
property to convert to a real
    z = sin(x.get!float)  + cos(y.get!float);            // Or use get!T
    z = sin(cast(float)x) + cos(cast(float)y);           // Or use cast(T) to
explicitly convert

    // Define a 8-bit custom float for storing probabilities
    alias CustomFloat!(4, 4,
CustomFloatFlags.ieee^CustomFloatFlags.probability^CustomFloatFlags.signed )
Probability;
    auto p = Probability(0.5);
Nov 18 2012
parent reply Manu <turkeyman gmail.com> writes:
On 19 November 2012 01:08, Robert Jacques <sandford jhu.edu> wrote:


 On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman gmail.com> wrote:

  I've often wondered about having an official 'half' type.

 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common), and
 it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
 which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because it
 is neither unsigned, nor is it an integer, and it's not typesafe (allows
 direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even
 if it is performed in software in most architectures, it could be mapped
 to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to
 the
 hardware type, and since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?


 Vote--.

 The a half data type is already part of std.numeric. From the docs:

 // Define a 16-bit floating point values
    CustomFloat!16                                x;     // Using the
 number of bits
    CustomFloat!(10, 5)                           y;     // Using the
 precision and exponent width
    CustomFloat!(10, 5,CustomFloatFlags.ieee)     z;     // Using the
 precision, exponent width and format flags
    CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w;     // Using the
 precision, exponent width, format flags and exponent offset bias

    // Use the 16-bit floats mostly like normal numbers
    w = x*y - 1;
    writeln(w);

    // Functions calls require conversion
    z = sin(+x)           + cos(+y);                     // Use uniary plus
 to concisely convert to a real
    z = sin(x.re)         + cos(y.re);                   // Or use the .re
 property to convert to a real
    z = sin(x.get!float)  + cos(y.get!float);            // Or use get!T
    z = sin(cast(float)x) + cos(cast(float)y);           // Or use cast(T)
 to explicitly convert

    // Define a 8-bit custom float for storing probabilities
    alias CustomFloat!(4, 4, CustomFloatFlags.ieee^**
 CustomFloatFlags.probability^**CustomFloatFlags.signed ) Probability;
    auto p = Probability(0.5);


I still can't buy arguments like this. It completely changes the syntax.
If I told you this is how real should be implemented, would you vote ++?
What about double? Why?
Why not float for that matter? There seems like no reason for the language
to define any floating point type at all if you consider this acceptable...

'half' isn't some custom float for niche use, it's an established standard,
implemented in vastly more hardware than implements 'real'.
Nov 18 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2012 4:31 PM, Manu wrote:

 If I told you this is how real should be implemented, would you vote ++? What
 about double? Why?
 Why not float for that matter? There seems like no reason for the language to
 define any floating point type at all if you consider this acceptable...


Because they are implemented in hardware. It's pretty dang hard for a compiler 
to look at a floating point emulator and figure out "gee, I have a nice
hardware 
instruction that does the same thing as this 2K of code!"


 'half' isn't some custom float for niche use, it's an established standard,
 implemented in vastly more hardware than implements 'real'.


It's implemented in GPUs, sure, but it is it implemented in hardware that D
runs 
on? (I do know about this: 
http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)

There is no major technical difficulty in implementing it as a basic type, but
I 
want to be sure we've exhausted the library approach first.
Nov 18 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 19 November 2012 06:19, Walter Bright <newshound2 digitalmars.com> wrote:


 On 11/18/2012 4:31 PM, Manu wrote:


 If I told you this is how real should be implemented, would you vote ++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this acceptable...


 Because they are implemented in hardware. It's pretty dang hard for a
 compiler to look at a floating point emulator and figure out "gee, I have a
 nice hardware instruction that does the same thing as this 2K of code!"



Right, and this is my point precisely. It's hard for GDC for instance to
hook some complex library because it happens to have hardware to do it.

 'half' isn't some custom float for niche use, it's an established standard,

 implemented in vastly more hardware than implements 'real'.


 It's implemented in GPUs, sure, but it is it implemented in hardware that
 D runs on? (I do know about this: http://gcc.gnu.org/onlinedocs/**
 gcc/Half_002dPrecision.html<http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html>
 )

 There is no major technical difficulty in implementing it as a basic type,
 but I want to be sure we've exhausted the library approach first.


Well it's available in hardware on basically all mobile devices (that's a
LOT of devices (in the billions)), but even if it's just implemented in
software (x86), the values are consumed by the GPU, and the validity of the
values is no less important. It still seems like a valuable 1st class type;
why shouldn't it enjoy the same casting, assignment, literal, range
checking rules as the rest of the floats? Additionally, convenience and
compatibility with generic code would be significantly improved.
I don't see how it can be made to feel seamless with a lib... and that
sounds like an awful lot more work.


Anyway, I'm not desperate for this personally. I just wondered how people
felt about it in general, and if it was something that should/would be
seriously considered.
Nov 19 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2012 8:04 AM, Manu wrote:

 Well it's available in hardware on basically all mobile devices (that's a LOT
of
 devices (in the billions)), but even if it's just implemented in software
(x86),
 the values are consumed by the GPU, and the validity of the values is no less
 important. It still seems like a valuable 1st class type; why shouldn't it
enjoy
 the same casting, assignment, literal, range checking rules as the rest of the
 floats? Additionally, convenience and compatibility with generic code would be
 significantly improved.
 I don't see how it can be made to feel seamless with a lib... and that sounds
 like an awful lot more work.


By making a library type that implicitly converts to/from float, and then doing 
the operations on float, that should about cover it.

For the ARM, the conversion itself could be done by a builtin function, which 
can use the ARM hardware instruction for it.

For literals, I think:

     __fp16(3.5)

coupled with UTFE can work.



 Anyway, I'm not desperate for this personally. I just wondered how people felt
 about it in general, and if it was something that should/would be seriously
 considered.


I think it should be considered.
Nov 19 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 November 2012 16:04, Manu <turkeyman gmail.com> wrote:

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

 On 11/18/2012 4:31 PM, Manu wrote:

 If I told you this is how real should be implemented, would you vote ++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this acceptable...



 Because they are implemented in hardware. It's pretty dang hard for a
 compiler to look at a floating point emulator and figure out "gee, I have a
 nice hardware instruction that does the same thing as this 2K of code!"



 Right, and this is my point precisely. It's hard for GDC for instance to
 hook some complex library because it happens to have hardware to do it.


 'half' isn't some custom float for niche use, it's an established
 standard,
 implemented in vastly more hardware than implements 'real'.



 It's implemented in GPUs, sure, but it is it implemented in hardware that
 D runs on? (I do know about this:
 http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)

 There is no major technical difficulty in implementing it as a basic type,
 but I want to be sure we've exhausted the library approach first.



 Well it's available in hardware on basically all mobile devices (that's a
 LOT of devices (in the billions)), but even if it's just implemented in
 software (x86), the values are consumed by the GPU, and the validity of the
 values is no less important. It still seems like a valuable 1st class type;
 why shouldn't it enjoy the same casting, assignment, literal, range checking
 rules as the rest of the floats? Additionally, convenience and compatibility
 with generic code would be significantly improved.
 I don't see how it can be made to feel seamless with a lib... and that
 sounds like an awful lot more work.


 Anyway, I'm not desperate for this personally. I just wondered how people
 felt about it in general, and if it was something that should/would be
 seriously considered.


I'm neither here nor there.  I'm just pointing out that you are
proposing a dedicated type to be introduced that is supported on only
one platform. :-)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 19 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 19 November 2012 19:28, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 19 November 2012 16:04, Manu <turkeyman gmail.com> wrote:

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


 wrote:

 On 11/18/2012 4:31 PM, Manu wrote:

 If I told you this is how real should be implemented, would you vote






 ++?

 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this






 acceptable...

 Because they are implemented in hardware. It's pretty dang hard for a
 compiler to look at a floating point emulator and figure out "gee, I




 have a

 nice hardware instruction that does the same thing as this 2K of code!"



 Right, and this is my point precisely. It's hard for GDC for instance to
 hook some complex library because it happens to have hardware to do it.


 'half' isn't some custom float for niche use, it's an established
 standard,
 implemented in vastly more hardware than implements 'real'.



 It's implemented in GPUs, sure, but it is it implemented in hardware




 that

 D runs on? (I do know about this:
 http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)

 There is no major technical difficulty in implementing it as a basic




 type,

 but I want to be sure we've exhausted the library approach first.



 Well it's available in hardware on basically all mobile devices (that's a
 LOT of devices (in the billions)), but even if it's just implemented in
 software (x86), the values are consumed by the GPU, and the validity of


 the

 values is no less important. It still seems like a valuable 1st class


 type;

 why shouldn't it enjoy the same casting, assignment, literal, range


 checking

 rules as the rest of the floats? Additionally, convenience and


 compatibility

 with generic code would be significantly improved.
 I don't see how it can be made to feel seamless with a lib... and that
 sounds like an awful lot more work.


 Anyway, I'm not desperate for this personally. I just wondered how people
 felt about it in general, and if it was something that should/would be
 seriously considered.


 I'm neither here nor there.  I'm just pointing out that you are
 proposing a dedicated type to be introduced that is supported on only
 one platform. :-)


real is only supported on one platform (x86, it's deprecated in x64 and x87
will likely be removed/emulated in the future), but I think many here
consider it valuable(?).
And that's not strictly true either, virtually every machine has a GPU, and
host software still has to process data for it. I'm mainly encouraging this
for the sake of correctness/type safety, though hardware support on ARM
would be a particularly nice bonus.

I also wanted to gauge the interest/opposition.
Nov 19 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 November 2012 17:57, Manu <turkeyman gmail.com> wrote:

 On 19 November 2012 19:28, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 19 November 2012 16:04, Manu <turkeyman gmail.com> wrote:

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

 On 11/18/2012 4:31 PM, Manu wrote:

 If I told you this is how real should be implemented, would you vote
 ++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this
 acceptable...



 Because they are implemented in hardware. It's pretty dang hard for a
 compiler to look at a floating point emulator and figure out "gee, I
 have a
 nice hardware instruction that does the same thing as this 2K of code!"



 Right, and this is my point precisely. It's hard for GDC for instance to
 hook some complex library because it happens to have hardware to do it.


 'half' isn't some custom float for niche use, it's an established
 standard,
 implemented in vastly more hardware than implements 'real'.



 It's implemented in GPUs, sure, but it is it implemented in hardware
 that
 D runs on? (I do know about this:
 http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)

 There is no major technical difficulty in implementing it as a basic
 type,
 but I want to be sure we've exhausted the library approach first.



 Well it's available in hardware on basically all mobile devices (that's
 a
 LOT of devices (in the billions)), but even if it's just implemented in
 software (x86), the values are consumed by the GPU, and the validity of
 the
 values is no less important. It still seems like a valuable 1st class
 type;
 why shouldn't it enjoy the same casting, assignment, literal, range
 checking
 rules as the rest of the floats? Additionally, convenience and
 compatibility
 with generic code would be significantly improved.
 I don't see how it can be made to feel seamless with a lib... and that
 sounds like an awful lot more work.


 Anyway, I'm not desperate for this personally. I just wondered how
 people
 felt about it in general, and if it was something that should/would be
 seriously considered.


 I'm neither here nor there.  I'm just pointing out that you are
 proposing a dedicated type to be introduced that is supported on only
 one platform. :-)



 real is only supported on one platform (x86, it's deprecated in x64 and x87
 will likely be removed/emulated in the future), but I think many here
 consider it valuable(?).
 And that's not strictly true either, virtually every machine has a GPU, and
 host software still has to process data for it. I'm mainly encouraging this
 for the sake of correctness/type safety, though hardware support on ARM
 would be a particularly nice bonus.

 I also wanted to gauge the interest/opposition.


Real is mapped to the target's long double.  It could be 64bit, 80bit,
96bit, or 128bit.  The phobos math library already caters for this.
:-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 19 2012
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman gmail.com> wrote:


 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common), and
 it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
 which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because it
 is neither unsigned, nor is it an integer, and it's not typesafe (allows
 direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value, even
 if it is performed in software in most architectures, it could be mapped to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to the
 hardware type, and since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?


Vote--.

The a half data type is already part of std.numeric. From the docs:

// Define a 16-bit floating point values
    CustomFloat!16                                x;     // Using the number of
bits
    CustomFloat!(10, 5)                           y;     // Using the precision
and exponent width
    CustomFloat!(10, 5,CustomFloatFlags.ieee)     z;     // Using the
precision, exponent width and format flags
    CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w;     // Using the
precision, exponent width, format flags and exponent offset bias

    // Use the 16-bit floats mostly like normal numbers
    w = x*y - 1;
    writeln(w);

    // Functions calls require conversion
    z = sin(+x)           + cos(+y);                     // Use uniary plus to
concisely convert to a real
    z = sin(x.re)         + cos(y.re);                   // Or use the .re
property to convert to a real
    z = sin(x.get!float)  + cos(y.get!float);            // Or use get!T
    z = sin(cast(float)x) + cos(cast(float)y);           // Or use cast(T) to
explicitly convert

    // Define a 8-bit custom float for storing probabilities
    alias CustomFloat!(4, 4,
CustomFloatFlags.ieee^CustomFloatFlags.probability^CustomFloatFlags.signed )
Probability;
    auto p = Probability(0.5);
Nov 18 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 19, 2012 19:57:37 Manu wrote:

 I also wanted to gauge the interest/opposition.


I'd never even _heard_ of half types before this discussion came up. But then 
again, the same goes for SIMD. And IIRC, there was some sort of function 
attribute relating to pointers and registers that you or some other gaming 
person was insisting on a while back, and I'd never heard of it existing in 
C++ either (as an extension or otherwise). You clearly program in a very 
different world than I do. I care about high performance in what I do but 
nothing on _that_ level. I suspect that this is another one of those things 
that certain folks would really like to have, and most of the rest of us don't 
have any real interest in and often know nothing about in the first place. I 
don't know that I really care whether it's added to the language though. I'll 
leave that sort of decision up to Walter.

If anything, I just find it interesting how many low level things folks like 
you keep coming up with as must-haves or very strong wants that I've never 
even heard of and will almost certainly never care about aside perhaps from 
how having them in D might help D catch on.

- Jonathan M Davis
Nov 19 2012
next sibling parent reply "Rob T" <rob ucora.com> writes:
On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis 
wrote:

 I'd never even _heard_ of half types before this discussion 
 came up. But then
 again, the same goes for SIMD. And IIRC, there was some sort of 
 function
 attribute relating to pointers and registers that you or some 
 other gaming
 person was insisting on a while back, and I'd never heard of it 
 existing in
 C++ either (as an extension or otherwise). You clearly program 
 in a very
 different world than I do. I care about high performance in 
 what I do but
 nothing on _that_ level. I suspect that this is another one of 
 those things
 that certain folks would really like to have, and most of the 
 rest of us don't
 have any real interest in and often know nothing about in the 
 first place. I
 don't know that I really care whether it's added to the 
 language though. I'll
 leave that sort of decision up to Walter.

 If anything, I just find it interesting how many low level 
 things folks like
 you keep coming up with as must-haves or very strong wants that 
 I've never
 even heard of and will almost certainly never care about aside 
 perhaps from
 how having them in D might help D catch on.

 - Jonathan M Davis


Anyone interested in the low precision float types, and what they 
are good for, can start here
http://www.opengl.org/wiki/Small_Float_Formats

I did not read through all of this thread, but my guess is that 
the people making the request for half float are mostly into game 
development and image processing.

When I first started investigating D as a potential C++ 
replacement, I noted that a lot of the "visible" development 
(what I could see being publicized) was game development, so it 
seemed that for some reason a lot of the D users were also game 
developers, so there's perhaps something about D that they find 
attractive.

Why game devs are interested so much in D is interesting 
considering the GC is noted to be a problem for game devs. The 
work of H. S. Teoh comes to mind with his work on a game engine, 
that pushed the limits of the GC and std lib.

In any case, the point is that I don't think the D community 
should overlook what the game devs are doing, they're pushing D 
to its limits and are making D more visible than perhaps anyone.

--rt
Nov 19 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2012 12:28 PM, Rob T wrote:

 In any case, the point is that I don't think the D community should overlook
 what the game devs are doing, they're pushing D to its limits and are making D
 more visible than perhaps anyone.


I agree.

I might also point out that adoption of a language (or any new technology)
often 
happens because it solves a problem for an otherwise overlooked niche, and
their 
adoption of it drives it into the mainstream.
Nov 19 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 19, 2012 12:55:11 Walter Bright wrote:

 On 11/19/2012 12:28 PM, Rob T wrote:

 In any case, the point is that I don't think the D community should
 overlook what the game devs are doing, they're pushing D to its limits
 and are making D more visible than perhaps anyone.


 
 I agree.
 
 I might also point out that adoption of a language (or any new technology)
 often happens because it solves a problem for an otherwise overlooked
 niche, and their adoption of it drives it into the mainstream.


I don't disagree at all. I just find it interesting how many things that the 
game devs keep coming up with that they consider critical that most of the 
rest of us haven't ever even considered and frequently know absolutely nothing 
about.

- Jonathan M Davis
Nov 19 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 20 November 2012 02:51, Jonathan M Davis <jmdavisProg gmx.com> wrote:


 On Monday, November 19, 2012 12:55:11 Walter Bright wrote:

 On 11/19/2012 12:28 PM, Rob T wrote:

 In any case, the point is that I don't think the D community should
 overlook what the game devs are doing, they're pushing D to its limits
 and are making D more visible than perhaps anyone.


 I agree.

 I might also point out that adoption of a language (or any new


 technology)

 often happens because it solves a problem for an otherwise overlooked
 niche, and their adoption of it drives it into the mainstream.


 I don't disagree at all. I just find it interesting how many things that
 the
 game devs keep coming up with that they consider critical that most of the
 rest of us haven't ever even considered and frequently know absolutely
 nothing
 about.


Dunno what to tell you.
Gamedev is a strange union of 3-4-5 very distinct fields of programming,
each with their own set of requirements, and often just the interaction
between them is an interesting problem in its self.
Engine programming is the most critical though, with virtually no room for
compromise. D needs to be competitive in that space if it hopes to dislodge
C/C++, and it's not far off.
Nov 19 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 19 November 2012 22:28, Rob T <rob ucora.com> wrote:


 On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:


 I'd never even _heard_ of half types before this discussion came up. But
 then
 again, the same goes for SIMD. And IIRC, there was some sort of function
 attribute relating to pointers and registers that you or some other gaming
 person was insisting on a while back, and I'd never heard of it existing
 in
 C++ either (as an extension or otherwise). You clearly program in a very
 different world than I do. I care about high performance in what I do but
 nothing on _that_ level. I suspect that this is another one of those
 things
 that certain folks would really like to have, and most of the rest of us
 don't
 have any real interest in and often know nothing about in the first
 place. I
 don't know that I really care whether it's added to the language though.
 I'll
 leave that sort of decision up to Walter.

 If anything, I just find it interesting how many low level things folks
 like
 you keep coming up with as must-haves or very strong wants that I've never
 even heard of and will almost certainly never care about aside perhaps
 from
 how having them in D might help D catch on.

 - Jonathan M Davis


 Anyone interested in the low precision float types, and what they are good
 for, can start here
 http://www.opengl.org/wiki/**Small_Float_Formats<http://www.opengl.org/wiki/Small_Float_Formats>

 I did not read through all of this thread, but my guess is that the people
 making the request for half float are mostly into game development and
 image processing.

 When I first started investigating D as a potential C++ replacement, I
 noted that a lot of the "visible" development (what I could see being
 publicized) was game development, so it seemed that for some reason a lot
 of the D users were also game developers, so there's perhaps something
 about D that they find attractive.


I've said it before, but I think D has MASSIVE potential in gaming. We are
an industry crying our for salvation from C++, but there's no possibility
to compromise on the level of access it provides us to the hardware we work
with.
D is the only language I know of that seriously threatens to offer modern
programming constructs, while still providing a syntax and compiler
technology that I can easily understand in terms of code generation and can
hit the metal when I need to.

Additionally, most games programmers have very long-term relationships with
C++ almost exclusively, so despite hating it, moving to something utterly
different like rust or whatever cool thing comes along will just never fly.
You'll never convince a team of 10-30 programmers to agree on such a change
all at once, and re-training staff in something so foreign would never be
economical.
D is again particularly interesting here because it's enough like C++ and

but not threatened. Also, in a lot of cases, the changes to D are
relatively intuitive. The things you expect should work, often just do...
but there are still lots of rough edges too.

Gaming is a very demanding and progressive field of software, but also very
backwards at the same time. It's a sort of unity between many disciplines,
and it all comes together under a performance critical and usually embedded
umbrella, in a highly competitive and fickle industry.
You can't tell the customer to upgrade their hardware when it needs to run
on a console with an ~8 year lifecycle. As a (tech/engine) programmer, if
you don't scrutinise the code generation, calling conventions, memory
access patterns, data layout and sizes, the competition will, and their
product will appear superior. Towards the end of that 8 year cycle,
programmers are REALLY squeezing these machines. If the language doesn't
support that, then you can't compete anymore, hence we remain stuck on C++
(and there are many instances where the industry is reverting to C because
C++ is a bloaty pig).

Why game devs are interested so much in D is interesting considering the GC

 is noted to be a problem for game devs. The work of H. S. Teoh comes to
 mind with his work on a game engine, that pushed the limits of the GC and
 std lib.


I'll admit this is my biggest fear hands down!
That said, D is the only GC based language I know if where the GC is
relatively optional. This allows us to hedge our bets, and ease in to it
slowly as we gain confidence and understanding of how it behaves.
I don't yet have much confidence in the GC, and generally avoid using it. I
only use it for short term allocations, or non-critical-loop work which
often only survive for the scope of the function.

I don't have enough experience to make any reasonable claims about its
affect on performance, but I have seen a lot of benchmarks in this NG

doesn't fill me with confidence.


least smaller/independent games. It's probably still not acceptable on
major AAA console titles though. We need thread-local collection... it
can't stop the world to do a collect, and I wouldn't afford more than 1ms
at any given time (and I think that's even being generous). Perhaps
incremental collection where it would stop after it reaches its allocated
time budget or something?

So my working theory is, if the GC were limited to relatively few
'convenience allocations' and the bulk of memory was still managed
manually, maybe that will lift the load to the point that the cost is
insignificant, and it will be a useful tool...?
But yes, for the moment, we use malloc and emplace.

I think this will mature only with experience and it'll help if there are

guys about the habits of their GC and expect anyone to care. This community
offers options.
We don't HATE garbage collection, we just can't generally afford it.

 In any case, the point is that I don't think the D community should

 overlook what the game devs are doing, they're pushing D to its limits and
 are making D more visible than perhaps anyone.



This is about the only thing of significance I think we can hope to offer
back to the community. If we can use it successfully in a major commercial
game, then tell the story afterwards, I think that could bring a lot of new
interest. I hope we are able to do that.
I think maturity is reaching the point where people can realistically start
to consider taking a risk with it.

I'd love to see more movement on the android/ios front, I reckon there's a
lot more immediate potential in that space given that it's a lot less risky
and the bar isn't as high.
Nov 19 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-20 01:45, Manu wrote:

 On 19 November 2012 22:28, Rob T <rob ucora.com <mailto:rob ucora.com>>
 wrote:

     On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:

         I'd never even _heard_ of half types before this discussion came
         up. But then
         again, the same goes for SIMD. And IIRC, there was some sort of
         function
         attribute relating to pointers and registers that you or some
         other gaming
         person was insisting on a while back, and I'd never heard of it
         existing in
         C++ either (as an extension or otherwise). You clearly program
         in a very
         different world than I do. I care about high performance in what
         I do but
         nothing on _that_ level. I suspect that this is another one of
         those things
         that certain folks would really like to have, and most of the
         rest of us don't
         have any real interest in and often know nothing about in the
         first place. I
         don't know that I really care whether it's added to the language
         though. I'll
         leave that sort of decision up to Walter.

         If anything, I just find it interesting how many low level
         things folks like
         you keep coming up with as must-haves or very strong wants that
         I've never
         even heard of and will almost certainly never care about aside
         perhaps from
         how having them in D might help D catch on.

         - Jonathan M Davis


     Anyone interested in the low precision float types, and what they
     are good for, can start here
     http://www.opengl.org/wiki/__Small_Float_Formats
     <http://www.opengl.org/wiki/Small_Float_Formats>

     I did not read through all of this thread, but my guess is that the
     people making the request for half float are mostly into game
     development and image processing.

     When I first started investigating D as a potential C++ replacement,
     I noted that a lot of the "visible" development (what I could see
     being publicized) was game development, so it seemed that for some
     reason a lot of the D users were also game developers, so there's
     perhaps something about D that they find attractive.


 I've said it before, but I think D has MASSIVE potential in gaming. We
 are an industry crying our for salvation from C++, but there's no
 possibility to compromise on the level of access it provides us to the
 hardware we work with.
 D is the only language I know of that seriously threatens to offer
 modern programming constructs, while still providing a syntax and
 compiler technology that I can easily understand in terms of code
 generation and can hit the metal when I need to.

 Additionally, most games programmers have very long-term relationships
 with C++ almost exclusively, so despite hating it, moving to something
 utterly different like rust or whatever cool thing comes along will just
 never fly. You'll never convince a team of 10-30 programmers to agree on
 such a change all at once, and re-training staff in something so foreign
 would never be economical.
 D is again particularly interesting here because it's enough like C++

 liberated, but not threatened. Also, in a lot of cases, the changes to D
 are relatively intuitive. The things you expect should work, often just
 do... but there are still lots of rough edges too.

 Gaming is a very demanding and progressive field of software, but also
 very backwards at the same time. It's a sort of unity between many
 disciplines, and it all comes together under a performance critical and
 usually embedded umbrella, in a highly competitive and fickle industry.
 You can't tell the customer to upgrade their hardware when it needs to
 run on a console with an ~8 year lifecycle. As a (tech/engine)
 programmer, if you don't scrutinise the code generation, calling
 conventions, memory access patterns, data layout and sizes, the
 competition will, and their product will appear superior. Towards the
 end of that 8 year cycle, programmers are REALLY squeezing these
 machines. If the language doesn't support that, then you can't compete
 anymore, hence we remain stuck on C++ (and there are many instances
 where the industry is reverting to C because C++ is a bloaty pig).

     Why game devs are interested so much in D is interesting considering
     the GC is noted to be a problem for game devs. The work of H. S.
     Teoh comes to mind with his work on a game engine, that pushed the
     limits of the GC and std lib.


 I'll admit this is my biggest fear hands down!
 That said, D is the only GC based language I know if where the GC is
 relatively optional. This allows us to hedge our bets, and ease in to it
 slowly as we gain confidence and understanding of how it behaves.
 I don't yet have much confidence in the GC, and generally avoid using
 it. I only use it for short term allocations, or non-critical-loop work
 which often only survive for the scope of the function.


Someone has created GC free versions of Phobos and druntime:

http://3d.benjamin-thaut.de/?p=20#more-20

Was posted here:

http://forum.dlang.org/thread/k27bh7$t7f$1 digitalmars.com

-- 
/Jacob Carlborg
Nov 19 2012
parent reply Manu <turkeyman gmail.com> writes:
On 20 November 2012 09:41, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-20 01:45, Manu wrote:


 On 19 November 2012 22:28, Rob T <rob ucora.com <mailto:rob ucora.com>>

 wrote:

     On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:

         I'd never even _heard_ of half types before this discussion came
         up. But then
         again, the same goes for SIMD. And IIRC, there was some sort of
         function
         attribute relating to pointers and registers that you or some
         other gaming
         person was insisting on a while back, and I'd never heard of it
         existing in
         C++ either (as an extension or otherwise). You clearly program
         in a very
         different world than I do. I care about high performance in what
         I do but
         nothing on _that_ level. I suspect that this is another one of
         those things
         that certain folks would really like to have, and most of the
         rest of us don't
         have any real interest in and often know nothing about in the
         first place. I
         don't know that I really care whether it's added to the language
         though. I'll
         leave that sort of decision up to Walter.

         If anything, I just find it interesting how many low level
         things folks like
         you keep coming up with as must-haves or very strong wants that
         I've never
         even heard of and will almost certainly never care about aside
         perhaps from
         how having them in D might help D catch on.

         - Jonathan M Davis


     Anyone interested in the low precision float types, and what they
     are good for, can start here
     http://www.opengl.org/wiki/__**Small_Float_Formats<http://www.opengl.org/wiki/__Small_Float_Formats>

     <http://www.opengl.org/wiki/**Small_Float_Formats<http://www.opengl.org/wiki/Small_Float_Formats>


     I did not read through all of this thread, but my guess is that the
     people making the request for half float are mostly into game
     development and image processing.

     When I first started investigating D as a potential C++ replacement,
     I noted that a lot of the "visible" development (what I could see
     being publicized) was game development, so it seemed that for some
     reason a lot of the D users were also game developers, so there's
     perhaps something about D that they find attractive.


 I've said it before, but I think D has MASSIVE potential in gaming. We
 are an industry crying our for salvation from C++, but there's no
 possibility to compromise on the level of access it provides us to the
 hardware we work with.
 D is the only language I know of that seriously threatens to offer
 modern programming constructs, while still providing a syntax and
 compiler technology that I can easily understand in terms of code
 generation and can hit the metal when I need to.

 Additionally, most games programmers have very long-term relationships
 with C++ almost exclusively, so despite hating it, moving to something
 utterly different like rust or whatever cool thing comes along will just
 never fly. You'll never convince a team of 10-30 programmers to agree on
 such a change all at once, and re-training staff in something so foreign
 would never be economical.
 D is again particularly interesting here because it's enough like C++

 liberated, but not threatened. Also, in a lot of cases, the changes to D
 are relatively intuitive. The things you expect should work, often just
 do... but there are still lots of rough edges too.

 Gaming is a very demanding and progressive field of software, but also
 very backwards at the same time. It's a sort of unity between many
 disciplines, and it all comes together under a performance critical and
 usually embedded umbrella, in a highly competitive and fickle industry.
 You can't tell the customer to upgrade their hardware when it needs to
 run on a console with an ~8 year lifecycle. As a (tech/engine)
 programmer, if you don't scrutinise the code generation, calling
 conventions, memory access patterns, data layout and sizes, the
 competition will, and their product will appear superior. Towards the
 end of that 8 year cycle, programmers are REALLY squeezing these
 machines. If the language doesn't support that, then you can't compete
 anymore, hence we remain stuck on C++ (and there are many instances
 where the industry is reverting to C because C++ is a bloaty pig).

     Why game devs are interested so much in D is interesting considering
     the GC is noted to be a problem for game devs. The work of H. S.
     Teoh comes to mind with his work on a game engine, that pushed the
     limits of the GC and std lib.


 I'll admit this is my biggest fear hands down!
 That said, D is the only GC based language I know if where the GC is
 relatively optional. This allows us to hedge our bets, and ease in to it
 slowly as we gain confidence and understanding of how it behaves.
 I don't yet have much confidence in the GC, and generally avoid using
 it. I only use it for short term allocations, or non-critical-loop work
 which often only survive for the scope of the function.


 Someone has created GC free versions of Phobos and druntime:

 http://3d.benjamin-thaut.de/?**p=20#more-20<http://3d.benjamin-thaut.de/?p=20#more-20>



Nice case study! Thanks!
Looks like a cool little game too :P



 Was posted here:

 http://forum.dlang.org/thread/**k27bh7$t7f$1 digitalmars.com<http://forum.dlang.org/thread/k27bh7$t7f$1 digitalmars.com>

 --
 /Jacob Carlborg





 Nov 20 2012



 next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote:

 Nice case study! Thanks!
 Looks like a cool little game too :P


  Watched the video. Interesting looking game, but how long it was 
taking to move around the ships gives a sense of size, making me 
ask myself 'my god, how big IS that ship?'.



 Nov 20 2012



  parent  "DypthroposTheImposter" <mcbracket gmail.com>  writes:


  I've used half in C++, although mostly just to feed to the GPU 
since its pretty common that you don't want to waste the 
bandwidth on 32 bit floats.



 Nov 20 2012



prev sibling  parent  "Kagamin" <spam here.lot>  writes:


On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote:

 Nice case study! Thanks!
 Looks like a cool little game too :P


AFAIK, tart also has a prototype of realtime GC, but I don't know 
whether it can solve your problem. Such things are of little 
priority now for D and general purpose programming, I think.



 Nov 20 2012



prev sibling  parent  "Rob T" <rob ucora.com>  writes:


On Monday, 19 November 2012 at 20:28:22 UTC, Rob T wrote:

 The work of H. S. Teoh comes to mind with his work on a game 
 engine, that pushed the limits of the GC and std lib.


Not to undermine the work Teoh has done on D, but I meant 
Benjamin Thaut is the person who published his findings related 
to problems encountered with the GC and the std lib.

--rt



 Nov 19 2012



prev sibling  parent  "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis 
wrote:

 On Monday, November 19, 2012 19:57:37 Manu wrote:

 I also wanted to gauge the interest/opposition.


 I'd never even _heard_ of half types before this discussion 
 came up. But then
 again, the same goes for SIMD.

 [SNIP]

 - Jonathan M Davis


What I find extremely interesting about D is how easy it is to do 
extremely low level stuff.

ASM? Built-in. SIMD: You don't even realize you're doing it. In 
C++, you have to jump through flaming loops to get that stuff 
working.

I know where I'd go for my low level needs: Not C or C++ ;)

I think it could only benefit D to have the "full low level 
package in a comprehensive high level language". It's been on a 
winning run so far anyways (IMO).



 Nov 19 2012



prev sibling  parent  Don Clugston <dac nospam.com>  writes:


On 18/11/12 12:21, Manu wrote:

 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?


I suspect that what you want in nearly all cases is conversion from

half[] <-> float[]

ie, a pack/unpack operation. I think it would be quite rare to want to 
operate on a single half.

Although it's supported natively on GPUs, for D's purposes it is more 
natural to view it as compressed data.



 Nov 20 2012