November 19, 2012
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

November 19, 2012
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.
November 19, 2012
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.

November 19, 2012
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).
November 19, 2012
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';
November 20, 2012
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
C# that programmers feel immediately comfortable and somewhat 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.

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
though that have shown it is significantly inferior to C# and Java. That
doesn't fill me with confidence.
I do hope work is done to make it at least competitive with java/C#'s GC,
and then we'll see where we stand. C#'s GC is proven to be acceptable in at
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
receptive ears to our needs. It's impossible for us to complain to the C#
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.


November 20, 2012
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
November 20, 2012
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
November 20, 2012
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.


November 20, 2012
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++
> and C# that programmers feel immediately comfortable and somewhat
> 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