Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Sat, Feb 09, 2019 at 01:08:55AM +, bitwise via Digitalmars-d-announce wrote: > On Saturday, 9 February 2019 at 00:04:20 UTC, Dennis wrote: > > On Friday, 8 February 2019 at 23:58:49 UTC, H. S. Teoh wrote: > > > Yep, the moral of the story is, if codegen quality is important to > > > you, use ldc (and presumably gdc too) rather than dmd. > > > > That's definitely true, but that leaves the question whether > > lowering rvalue references to lambdas is acceptable. There's the > > 'dmd for fast builds, gdc/ldc for fast code' motto, but if your > > debug builds of your game make it run at 15 fps it becomes unusable. > > I don't want the gap between dmd and compilers with modern back-ends > > to widen. > > Since the user doesn't explicitly place the lambda in their code, > wouldn't it be justifiable for the compiler to take it back out again > at a later step in compilation, even in debug mode? Using lowering to lambdas as a way of defining semantics is not the same thing as actually using lambdas to implement a feature in the compiler! While it can be convenient to do the latter as a first stab, I'd expect that the optimizer could make use of special knowledge available in the compiler to implement this more efficiently. Since the compiler will always use a fixed pattern for the lowering, the backend could detect this pattern and optimize accordingly. Or the compiler implementation could lower it directly to something more efficient in the first place. T -- If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Saturday, 9 February 2019 at 00:04:20 UTC, Dennis wrote: On Friday, 8 February 2019 at 23:58:49 UTC, H. S. Teoh wrote: Yep, the moral of the story is, if codegen quality is important to you, use ldc (and presumably gdc too) rather than dmd. That's definitely true, but that leaves the question whether lowering rvalue references to lambdas is acceptable. There's the 'dmd for fast builds, gdc/ldc for fast code' motto, but if your debug builds of your game make it run at 15 fps it becomes unusable. I don't want the gap between dmd and compilers with modern back-ends to widen. Since the user doesn't explicitly place the lambda in their code, wouldn't it be justifiable for the compiler to take it back out again at a later step in compilation, even in debug mode?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Sat, Feb 09, 2019 at 12:04:20AM +, Dennis via Digitalmars-d-announce wrote: > On Friday, 8 February 2019 at 23:58:49 UTC, H. S. Teoh wrote: > > Yep, the moral of the story is, if codegen quality is important to > > you, use ldc (and presumably gdc too) rather than dmd. > > That's definitely true, but that leaves the question whether lowering > rvalue references to lambdas is acceptable. There's the 'dmd for fast > builds, gdc/ldc for fast code' motto, but if your debug builds of your > game make it run at 15 fps it becomes unusable. I don't want the gap > between dmd and compilers with modern back-ends to widen. TBH, I've been finding that ldc compilation times aren't all that bad compared to dmd. It's definitely slightly slower, but it's not anywhere near the gap between, say, dmd and g++. Recently I've been quite tempted to replace dmd with ldc as my main D compiler, esp. now that ldc releases are essentially on par with dmd releases in terms of release schedule of a particular language version. The slowdown in compilation times isn't enough to offset the benefits, as long as you're not compiling with, say, -O3 which *would* make the ldc optimizer run slower (but with the huge benefit of significantly better codegen -- I've seen performance improvements of up to ~200% with ldc -O3 vs. dmd -O -inline). And template-heavy code is slow across all D compilers anyway, so the relatively small compilation time difference between dmd and ldc doesn't really matter that much anymore once you have a sufficiently large codebase with heavy template use. T -- What doesn't kill me makes me stranger.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 8 February 2019 at 23:58:49 UTC, H. S. Teoh wrote: Yep, the moral of the story is, if codegen quality is important to you, use ldc (and presumably gdc too) rather than dmd. That's definitely true, but that leaves the question whether lowering rvalue references to lambdas is acceptable. There's the 'dmd for fast builds, gdc/ldc for fast code' motto, but if your debug builds of your game make it run at 15 fps it becomes unusable. I don't want the gap between dmd and compilers with modern back-ends to widen.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Fri, Feb 08, 2019 at 03:42:51PM -0800, H. S. Teoh via Digitalmars-d-announce
wrote:
> On Fri, Feb 08, 2019 at 11:34:47PM +, Dennis via Digitalmars-d-announce
> wrote:
> > On Friday, 8 February 2019 at 23:02:34 UTC, Nicholas Wilson wrote:
> > > Immediately called lamdas are always inlined.
> >
> > ```
> > extern(C) void main() {
> > int a = (() => 1)();
> > }
> > ```
[...]
> Does LDC/GDC inline it?
>
> I no longer trust dmd for codegen quality. :-/
[...]
Just checked: LDC does inline it. In fact, LDC compiles the whole thing
out and just has `ret` for main(). :-D Forcing LDC not to elide the
whole thing by inserting a writeln(a) call reveals that the lambda is
indeed inlined.
Yep, the moral of the story is, if codegen quality is important to you,
use ldc (and presumably gdc too) rather than dmd.
T
--
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Fri, Feb 08, 2019 at 11:34:47PM +, Dennis via Digitalmars-d-announce
wrote:
> On Friday, 8 February 2019 at 23:02:34 UTC, Nicholas Wilson wrote:
> > Immediately called lamdas are always inlined.
>
> ```
> extern(C) void main() {
> int a = (() => 1)();
> }
> ```
>
> dmd -inline -O -release -betterC
>
> asm:
> ```
> main:
> pushRBP
> mov RBP,RSP
> callqword ptr pure nothrow @nogc @safe int
> onlineapp.main().__lambda1()@GOTPCREL[RIP]
> xor EAX,EAX
> pop RBP
> ret
> ```
>
> https://run.dlang.io/is/lZW9B6
>
> Still a lambda call :/
Does LDC/GDC inline it?
I no longer trust dmd for codegen quality. :-/
T
--
Customer support: the art of getting your clients to pay for your own
incompetence.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 8 February 2019 at 23:02:34 UTC, Nicholas Wilson wrote:
Immediately called lamdas are always inlined.
```
extern(C) void main() {
int a = (() => 1)();
}
```
dmd -inline -O -release -betterC
asm:
```
main:
pushRBP
mov RBP,RSP
call qword ptr pure nothrow @nogc @safe int
onlineapp.main().__lambda1()@GOTPCREL[RIP]
xor EAX,EAX
pop RBP
ret
```
https://run.dlang.io/is/lZW9B6
Still a lambda call :/
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 8 February 2019 at 16:00:58 UTC, bitwise wrote: On Monday, 4 February 2019 at 20:08:39 UTC, Paul Backus wrote: On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote: [...] It's actually fine to leave the `return` there unconditionally--you're allowed to return an expression of type `void` from a function. Example: https://run.dlang.io/is/tnSGN4 Even better ;) No one else seems particularly excited about the rewrite though - what am I missing? I suppose a lambda cost significantly more, but I don't think the lambda should make it through the optimizer for this case though. Immediately called lamdas are always inlined.
Re: intel-intrinsics v1.0.0
On Friday, 8 February 2019 at 12:39:22 UTC, Guillaume Piolat wrote: On Friday, 8 February 2019 at 12:22:14 UTC, NaN wrote: On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat wrote: "intel-intrinsics" is a DUB package for people interested in x86 performance that want neither to write assembly, nor a LDC-specific snippet... and still have fastest possible code. Available through DUB: http://code.dlang.org/packages/intel-intrinsics Big thanks for this, it's been a massive help for me. cheers! You're welcome! I'd be interested to know what you are making with it, to feed the "users" list! https://github.com/AuburnSounds/intel-intrinsics/blob/master/README.md Im the guy from #graphics who's writing a software rasterizer. I'll let you know when I put it on github.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Monday, 4 February 2019 at 20:08:39 UTC, Paul Backus wrote: On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote: On Monday, 4 February 2019 at 18:32:56 UTC, Dominikus Dittes Scherkl wrote: I don't understand this. What does "(return)?" mean? Is this valid D syntax? What do I miss? I meant for that to be interpreted like a Regular expression, denoting conditional presence of the return statement. I'm not sure what the proper notation would be to express such a thing. It's actually fine to leave the `return` there unconditionally--you're allowed to return an expression of type `void` from a function. Example: https://run.dlang.io/is/tnSGN4 Even better ;) No one else seems particularly excited about the rewrite though - what am I missing? I suppose a lambda cost significantly more, but I don't think the lambda should make it through the optimizer for this case though.
Re: gtkDcoding Blog Post #0007 Now Live
On Friday, 8 February 2019 at 10:28:36 UTC, Ron Tarrant wrote: On Wednesday, 6 February 2019 at 19:09:57 UTC, Antonio Corbi wrote: The gnome project maintains a 'How Do I do this...' page, it's almost gtk and C related but (thank's to the wonderful binding from Mike Wey) the 'mental mapping' from C->D + gtk->gtkd is very straightforward: https://wiki.gnome.org/HowDoI/ Antonio. I seem to remember reading somewhere that it's gone out of vogue to thank people in forums. I get it; it adds noise to threads, but I still think it's the polite thing to do. So, thanks, Antonio. You are welcome, Ron ;) However, if this is now frowned upon on this forum, please let me know and I'll stop thanking people. Thank you for listening I mean: oh crap. I did it again. (sigh)
Re: intel-intrinsics v1.0.0
On Friday, 8 February 2019 at 12:22:14 UTC, NaN wrote: On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat wrote: "intel-intrinsics" is a DUB package for people interested in x86 performance that want neither to write assembly, nor a LDC-specific snippet... and still have fastest possible code. Available through DUB: http://code.dlang.org/packages/intel-intrinsics Big thanks for this, it's been a massive help for me. cheers! You're welcome! I'd be interested to know what you are making with it, to feed the "users" list! https://github.com/AuburnSounds/intel-intrinsics/blob/master/README.md
Re: intel-intrinsics v1.0.0
On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat wrote: "intel-intrinsics" is a DUB package for people interested in x86 performance that want neither to write assembly, nor a LDC-specific snippet... and still have fastest possible code. Available through DUB: http://code.dlang.org/packages/intel-intrinsics Big thanks for this, it's been a massive help for me. cheers!
Re: gtkDcoding Blog Post #0007 Now Live
On 08/02/2019 11:28 PM, Ron Tarrant wrote: I seem to remember reading somewhere that it's gone out of vogue to thank people in forums. I get it; it adds noise to threads, but I still think it's the polite thing to do. If you want to do it, go for it!
Re: gtkDcoding Blog Post #0007 Now Live
On Wednesday, 6 February 2019 at 19:09:57 UTC, Antonio Corbi wrote: The gnome project maintains a 'How Do I do this...' page, it's almost gtk and C related but (thank's to the wonderful binding from Mike Wey) the 'mental mapping' from C->D + gtk->gtkd is very straightforward: https://wiki.gnome.org/HowDoI/ Antonio. I seem to remember reading somewhere that it's gone out of vogue to thank people in forums. I get it; it adds noise to threads, but I still think it's the polite thing to do. So, thanks, Antonio. However, if this is now frowned upon on this forum, please let me know and I'll stop thanking people. Thank you for listening I mean: oh crap. I did it again. (sigh)
Blog Post #0008 Callbacks
Fellow programmers: 'Tis that day of the week again and nigh on time to post to the gtkDcoding blog once more. This time, I take a closer look at callbacks. And thanks to WebFreak001, I'm actually providing a link (Take advantage! Next time I might forget the link): http://gtkdcoding.com/2019/02/08/0008-callbacks.html
Re: gtkDcoding Blog Post #0007 Now Live
On Wednesday, 6 February 2019 at 16:12:25 UTC, WebFreak001 wrote: the link would have been nice :) http://gtkdcoding.com/2019/02/05/0007-button_release.html Senior moment. And I'm so young, too. (sigh)
