digitalmars.D - Reference value of structs not optimized or inlined?
- Jeremie Pelletier (27/27) Aug 26 2009 I just noticed that when a method has a ref parameter for a struct, it d...
- Bill Baxter (5/6) Aug 26 2009 Here's the bug you want to vote up:
- Jeremie Pelletier (3/13) Aug 26 2009 Just voted, it should be marked as urgent, I can't even begin to imagine...
- Jeremie Pelletier (3/19) Aug 26 2009 Just to stress out how important this is; I have a small loop calculatin...
- bearophile (4/5) Aug 26 2009 Are you in a situation where you use the LDC compiler?
- Jeremie Pelletier (3/11) Aug 26 2009 DMD 2.031 here on windows 7 x64, I'm writing a Direct2D backend for my d...
- bearophile (4/7) Aug 26 2009 OK, I'm really impressed now.
- Walter Bright (18/20) Aug 27 2009 No, and it doesn't work for C++ either. Consider:
- Jeremie Pelletier (4/30) Aug 27 2009 Yes but that would be a logic error from the programmer, as it would be ...
- Walter Bright (5/9) Aug 28 2009 The thing about const is it only specifies a read only view of an
- downs (9/20) Aug 28 2009 To elaborate on this, consider this case:
- Jeremie Pelletier (24/49) Aug 28 2009 Ok, I understand why it cant be done for 'in S' but I don't see why 'con...
- Jarrett Billingsley (5/10) Aug 28 2009 You're addressing the 'const' issue, but you haven't addressed the
- Walter Bright (2/5) Aug 28 2009 Because I never updated the inlining code to handle it.
- Jarrett Billingsley (3/9) Aug 28 2009 Well I'm glad it's that simple, and I'm sure Jeremie is too ;)
- Walter Bright (3/12) Aug 28 2009 There are a lot of D specific optimization opportunities that are left
- Ary Borenszweig (12/25) Aug 28 2009 Why?
- Bill Baxter (12/39) Aug 28 2009 ut
- Walter Bright (2/6) Aug 28 2009 Which of the thousand things people want done in D should be done first?
- Christopher Wright (2/9) Aug 28 2009 Those that the askers are willing to implement first, I'd say.
- Ary Borenszweig (4/11) Aug 29 2009 Those that you feel like doing first.
-
Walter Bright
(3/17)
Aug 29 2009
But I'm not kidding about the thousand things. There are more than - Jeremie Pelletier (4/22) Aug 29 2009 The core feature set should be more important for now, since they drive ...
- Jarrett Billingsley (6/28) Aug 29 2009 t
- davidl (5/34) Aug 29 2009 Good point.
- Walter Bright (2/21) Aug 29 2009 Inlining of functions with ref arguments has gotten 0 votes.
- Jarrett Billingsley (6/40) Aug 29 2009 You said "which of the thousand things people want done should be done
- Walter Bright (7/11) Aug 29 2009 I'll let you decide that based on stats from Bugzilla and the changelog....
- davidl (8/19) Aug 30 2009 If you've been consistently following the voting system as an indicator,...
- Bill Baxter (12/24) Aug 30 2009 I
- Dominik (3/9) Aug 29 2009 for example releasing memory back to the OS on windows now and then
- dsimcha (11/17) Aug 29 2009 I'd say things should get a priority bump if they're either:
- Steven Schveighoffer (10/21) Aug 29 2009 This is fine with me. I think the OP just wants to be sure that not
- Walter Bright (9/15) Aug 29 2009 C++ lacks it, too. The "inline" keyword is a hint which the compiler is
- Bill Baxter (10/16) Aug 28 2009 Wow. That's it? So let's get it done already! This is really a
- Brad Roberts (3/22) Aug 28 2009 Ok.. so we should expect a patch from you sometime soon? You did includ...
- Bill Baxter (11/33) Aug 28 2009 I'm actually surprised Don hasn't jumped on this one, given that it's
- Don (6/39) Aug 30 2009 I imagined it would require deep understanding of the compiler back-end,...
- Jason House (2/4) Aug 30 2009 The focus on CTFE is pretty obvious from Walter's recent update to the c...
- Walter Bright (2/7) Aug 30 2009 Don has been contributing a lot to the compiler work lately.
I just noticed that when a method has a ref parameter for a struct, it doesn't get inlined: union Matrix4x4 { struct { float _11, _12, ...} float[4][4] m; float[16] v; Matrix4x4 opMul(const ref Matrix4x4 m) const { ... } void opMulAssign(const ref Matrix4x4 m) { this = opMul(m); } void Translate(float x, float y, float z) { const m = GetTranslation(x, y, z); opMulAssign(m); } static Matrix4x4 GetTranslation(float x, float y, float z) { ... } } // RVO and inlining works like a charm here Matrix4x4 m1 = Matrix4x4.GetTranslation(10, 0, 0); // No inlining whatsoever here m1.Translate(0, 1, 0); I know in C++ when passing by reference (const Matrix4x4& m) the code gets inlned. It's even worse when using the in (I know it means const scope) storage class for these members: Matrix4x4 opMul(in Matrix4x4 m) const { ... } void opMulAssign(in Matrix4x4 m) { this = opMul(m); } void Translate(float x, float y, float z) { opMulAssign(GetTranslation(x, y, z)); } Not only does it not get inlined, but the whole 64bytes of the struct is copied into every stack frame using a bunch of MOVS instructions. Isn't there a way to implement RVO to work on parameters (PVO?) too if the storage is const? The compiler could even detect that GetTranslation() is going to write to the stack frame of opMulAssign and inline the entire sequence. Even in debug compiles you could skip the whole data copy thing. For now I pass all my references to any struct larger than 8bytes in my code by explicitely dereferencing (in Matrix4x4* m) to get the inline to work, but that kind of kills the newer syntax of D for such things. I think this should be left for compatibility with C and get the D storage classes working properly to prevent having to use pointers all over D too.
Aug 26 2009
On Wed, Aug 26, 2009 at 11:01 AM, Jeremie Pelletier<jeremiep gmail.com> wrote:I just noticed that when a method has a ref parameter for a struct, it doesn't get inlined:Here's the bug you want to vote up: http://d.puremagic.com/issues/show_bug.cgi?id=2008 It is indeed a sad situation. --bb
Aug 26 2009
Bill Baxter Wrote:On Wed, Aug 26, 2009 at 11:01 AM, Jeremie Pelletier<jeremiep gmail.com> wrote:Just voted, it should be marked as urgent, I can't even begin to imagine the amount of code that will need to be converted back to D syntax once it is fixed. Thanks.I just noticed that when a method has a ref parameter for a struct, it doesn't get inlined:Here's the bug you want to vote up: http://d.puremagic.com/issues/show_bug.cgi?id=2008 It is indeed a sad situation. --bb
Aug 26 2009
Jeremie Pelletier Wrote:Bill Baxter Wrote:Just to stress out how important this is; I have a small loop calculating a 3x2 rotation matrix used with either Direct2D or Cairo every 10ms which transform the text "Hello World" in a window. CPU usage drops by 7-10% when using C style pointers instead of D storage classes. I haven't even optimized with SSE and whatnot yet, just removing the stack frame initialization overhead. It would be way worse with the out storage class since the memory also has to be zero filled, which is overkill to me since its much better to just throw an error "out variable x used before initialization".On Wed, Aug 26, 2009 at 11:01 AM, Jeremie Pelletier<jeremiep gmail.com> wrote:Just voted, it should be marked as urgent, I can't even begin to imagine the amount of code that will need to be converted back to D syntax once it is fixed. Thanks.I just noticed that when a method has a ref parameter for a struct, it doesn't get inlined:Here's the bug you want to vote up: http://d.puremagic.com/issues/show_bug.cgi?id=2008 It is indeed a sad situation. --bb
Aug 26 2009
Jeremie Pelletier:Just to stress out how important this is; I have a small loop calculating a 3x2 rotation matrix used with either Direct2D or Cairo every 10ms which transform the text "Hello World" in a window. CPU usage drops by 7-10% when using C style pointers instead of D storage classes. I haven't even optimized with SSE and whatnot yet, just removing the stack frame initialization overhead.<Are you in a situation where you use the LDC compiler? Bye, bearophile
Aug 26 2009
bearophile Wrote:Jeremie Pelletier:DMD 2.031 here on windows 7 x64, I'm writing a Direct2D backend for my display package. I don't mind not having 64-bit support for now, but I definitely care about being on the bleeding edge of the D2 language. I also use the same compiler on Ubuntu. I use a customized runtime forked from D1 in '06 and almost entirely rewritten kepping up to date with every new D release. I dropped support for D1 last year. Last I heard LDC only supported D1 under unix, haven't checked it in a while.Just to stress out how important this is; I have a small loop calculating a 3x2 rotation matrix used with either Direct2D or Cairo every 10ms which transform the text "Hello World" in a window. CPU usage drops by 7-10% when using C style pointers instead of D storage classes. I haven't even optimized with SSE and whatnot yet, just removing the stack frame initialization overhead.<Are you in a situation where you use the LDC compiler? Bye, bearophile
Aug 26 2009
Jeremie Pelletier:DMD 2.031 here on windows 7 x64, I'm writing a Direct2D backend for my display package. I don't mind not having 64-bit support for now, but I definitely care about being on the bleeding edge of the D2 language. I also use the same compiler on Ubuntu. I use a customized runtime forked from D1 in '06 and almost entirely rewritten kepping up to date with every new D release. I dropped support for D1 last year. Last I heard LDC only supported D1 under unix, haven't checked it in a while.<OK, I'm really impressed now. Bye, bearophile
Aug 26 2009
Jeremie Pelletier wrote:Isn't there a way to implement RVO to work on parameters (PVO?) too if the storage is const?No, and it doesn't work for C++ either. Consider: struct S { int a; } void foo(const ref S s) { assert(s.a == 3); bar(); assert(s.a == 3); // OOPS! } S g; void bar() { g.a = 4; } void main() { foo(g); }
Aug 27 2009
Walter Bright Wrote:Jeremie Pelletier wrote:Yes but that would be a logic error from the programmer, as it would be possible to do the very same thing had foo been declared as void foo(in S* s). Isn't it possible to make 'const ref S' or 'in S' generate the same machine code as 'in S*'? To me it would seem the semantics of the two are the same, with 'const S*' being useful syntax for C compatibility while 'in S' and 'const ref S' are both D syntax. I don't use ref and out whatsoever in D because of their overhead and inability to inline, which is sad because the first time I read about D I pictured having every single parameter in my programs having at least one of in, ref or out and finally saying bye bye to pointers.Isn't there a way to implement RVO to work on parameters (PVO?) too if the storage is const?No, and it doesn't work for C++ either. Consider: struct S { int a; } void foo(const ref S s) { assert(s.a == 3); bar(); assert(s.a == 3); // OOPS! } S g; void bar() { g.a = 4; } void main() { foo(g); }
Aug 27 2009
Jeremie Pelletier wrote:Isn't it possible to make 'const ref S' or 'in S' generate the same machine code as 'in S*'? To me it would seem the semantics of the two are the same, with 'const S*' being useful syntax for C compatibility while 'in S' and 'const ref S' are both D syntax.The thing about const is it only specifies a read only view of an object, it does *not* specify that the referenced object will not change. That is why pass by value cannot be "optimized" to be pass by reference.
Aug 28 2009
Walter Bright wrote:Jeremie Pelletier wrote:To elaborate on this, consider this case: import std.stdio; struct X { int v; } void test(X x, void delegate() dg) { writefln(x.v); dg(); writefln(x.v); } void main() { X ecks; test(ecks, { ecks.v = 17; }); }Isn't it possible to make 'const ref S' or 'in S' generate the same machine code as 'in S*'? To me it would seem the semantics of the two are the same, with 'const S*' being useful syntax for C compatibility while 'in S' and 'const ref S' are both D syntax.The thing about const is it only specifies a read only view of an object, it does *not* specify that the referenced object will not change. That is why pass by value cannot be "optimized" to be pass by reference.
Aug 28 2009
downs Wrote:Walter Bright wrote:Ok, I understand why it cant be done for 'in S' but I don't see why 'const ref S' cannot have the same semantics as 'in S*', unless 'ref' doesn't mean that the struct is implicitly dereferenced. Here is some code to illustrate my point of view: struct S { int i; } S s; void Stuff() { s.i++; } void Foo(in S* s) { writefln(s.i); Stuff(); writefln(s.i); } void Bar(const ref S s) { writefln(s.i); Stuff(); writefln(s.i); } int main() { // Those both do the exact same thing Foo(&s); Bar(s); } If they are meant to have different semantics, then when is a good time to use ref? It would seem to me 'in S*' and 'S*' carry both behaviors you want in a referenced parameter: const and mutable. In any case only the reference is passed by value, not the struct itself. If the method calls another method which modifies the const view on the reference, then it should be a logic error from the programmer (good old shooting yourself in the foot) without the compiler getting in the way. Making fool-proof language semantics is a good idea, but IMO it shouldn't impact performance, or else any bit of code looking for time critical performance will never use the syntax that makes D shine, and a lot of confusion will spread around as both types of syntax are used. It also makes it confusing to interface with IDL. Alls I'm suggesting is that 'const ref S' and 'ref S' generate the same machine code as 'in S*' and 'S*', which would prevent us from using different syntax to get the performance boost, when in the end the intended behavior is the same.Jeremie Pelletier wrote:To elaborate on this, consider this case: import std.stdio; struct X { int v; } void test(X x, void delegate() dg) { writefln(x.v); dg(); writefln(x.v); } void main() { X ecks; test(ecks, { ecks.v = 17; }); }Isn't it possible to make 'const ref S' or 'in S' generate the same machine code as 'in S*'? To me it would seem the semantics of the two are the same, with 'const S*' being useful syntax for C compatibility while 'in S' and 'const ref S' are both D syntax.The thing about const is it only specifies a read only view of an object, it does *not* specify that the referenced object will not change. That is why pass by value cannot be "optimized" to be pass by reference.
Aug 28 2009
On Thu, Aug 27, 2009 at 8:17 PM, Walter Bright<newshound1 digitalmars.com> wrote:Jeremie Pelletier wrote:You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Isn't there a way to implement RVO to work on parameters (PVO?) too if the storage is const?No, and it doesn't work for C++ either. Consider:
Aug 28 2009
Jarrett Billingsley wrote:You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 28 2009
On Fri, Aug 28, 2009 at 4:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:Jarrett Billingsley wrote:Well I'm glad it's that simple, and I'm sure Jeremie is too ;)You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 28 2009
Jarrett Billingsley wrote:On Fri, Aug 28, 2009 at 4:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:There are a lot of D specific optimization opportunities that are left undone for now.Jarrett Billingsley wrote:Well I'm glad it's that simple, and I'm sure Jeremie is too ;)You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 28 2009
Walter Bright escribi�:Jarrett Billingsley wrote:Why? Seeing D as "a systems language with features form high-level languages but without the performance penalty so you can prefer it over much competition for people coming from either sides that expect high performance. bearophile and others from time to time complain about performance issues in D, just because D promises performance. I think this is more important that adding more features that won't give you higher performance. performance (sorry, had to repeat that word one more time :-P)On Fri, Aug 28, 2009 at 4:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:There are a lot of D specific optimization opportunities that are left undone for now.Jarrett Billingsley wrote:Well I'm glad it's that simple, and I'm sure Jeremie is too ;)You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 28 2009
On Fri, Aug 28, 2009 at 5:01 PM, Ary Borenszweig<ary esperanto.org.ar> wrot= e:Walter Bright escribi=F3:utJarrett Billingsley wrote:Why? Seeing D as "a systems language with features form high-level languages b=On Fri, Aug 28, 2009 at 4:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:There are a lot of D specific optimization opportunities that are left undone for now.Jarrett Billingsley wrote:Well I'm glad it's that simple, and I'm sure Jeremie is too ;)You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.etc.", if D's performance isn't that good then there's not much competiti=onfor people coming from either sides that expect high performance. bearophile and others from time to time complain about performance issues=inD, just because D promises performance. I think this is more important th=atadding more features that won't give you higher performance.I think it's perfectly justified to put off optimizations that are tricky or only pay off in odd circumstances. But from Walter's comment it sounds like this one shouldn't be any harder than enabling the pointer inlining path for ref args too. And the payoff would be decent. --bb
Aug 28 2009
Ary Borenszweig wrote:Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 28 2009
Walter Bright wrote:Ary Borenszweig wrote:Those that the askers are willing to implement first, I'd say.Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 28 2009
Walter Bright escribi�:Ary Borenszweig wrote:Those that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
Ary Borenszweig wrote:Walter Bright escribi�:<g> But I'm not kidding about the thousand things. There are more than that in Bugzilla.Ary Borenszweig wrote:Those that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
Walter Bright Wrote:Ary Borenszweig wrote:The core feature set should be more important for now, since they drive D2 closer to a stable specification, and I know how adding new features can break optimizations and whatnot. I would rather see T[new] arrays and working shared qualifiers myself. However, proper ref semantics would also allow us to switch back from C to D syntax for these. Maybe I should get familiar with dmd2's source and see if I can contribute to those issues once I get more free time, but even in its current development state, I have more fun coding in D than I ever had in C or C++.Walter Bright escribi�:<g> But I'm not kidding about the thousand things. There are more than that in Bugzilla.Ary Borenszweig wrote:Those that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
On Sat, Aug 29, 2009 at 4:56 AM, Walter Bright<newshound1 digitalmars.com> wrote:Ary Borenszweig wrote:tWalter Bright escribi=F3:Ary Borenszweig wrote:Walter Bright escribi=F3:There are a lot of D specific optimization opportunities that are lef=?Which of the thousand things people want done in D should be done first=undone for now.Why?atThose that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)<g> But I'm not kidding about the thousand things. There are more than th=in Bugzilla.So uh, how's the Bugzilla voting system working out then?
Aug 29 2009
�� Sat, 29 Aug 2009 22:01:53 +0800��Jarrett Billingsley <jarrett.billingsley gmail.com> д��:On Sat, Aug 29, 2009 at 4:56 AM, Walter Bright<newshound1 digitalmars.com> wrote:Good point. -- ʹ�� Opera �����Եĵ����ʼ��ͻ�����: http://www.opera.com/mail/Ary Borenszweig wrote:So uh, how's the Bugzilla voting system working out then?Walter Bright escribi��:<g> But I'm not kidding about the thousand things. There are more than that in Bugzilla.Ary Borenszweig wrote:Those that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)Walter Bright escribi��:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
Jarrett Billingsley wrote:On Sat, Aug 29, 2009 at 4:56 AM, Walter Bright<newshound1 digitalmars.com> wrote:Inlining of functions with ref arguments has gotten 0 votes.Ary Borenszweig wrote:So uh, how's the Bugzilla voting system working out then?Walter Bright escribi�:<g> But I'm not kidding about the thousand things. There are more than that in Bugzilla.Ary Borenszweig wrote:Those that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
On Sat, Aug 29, 2009 at 3:42 PM, Walter Bright<newshound1 digitalmars.com> wrote:Jarrett Billingsley wrote:You said "which of the thousand things people want done should be done first?" And we already tried to solve this problem with the Bugzilla voting feature. Has it been working out well? Have the issues that people want to get fixed been getting more attention than the others?On Sat, Aug 29, 2009 at 4:56 AM, Walter Bright<newshound1 digitalmars.com> wrote:Inlining of functions with ref arguments has gotten 0 votes.Ary Borenszweig wrote:So uh, how's the Bugzilla voting system working out then?Walter Bright escribi=F3:<g> But I'm not kidding about the thousand things. There are more than that in Bugzilla.Ary Borenszweig wrote:Those that you feel like doing first. Ok, you win. :-) (I use the same reasoning most of the time when coding Descent)Walter Bright escribi=F3:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
Jarrett Billingsley wrote:You said "which of the thousand things people want done should be done first?" And we already tried to solve this problem with the Bugzilla voting feature. Has it been working out well? Have the issues that people want to get fixed been getting more attention than the others?I'll let you decide that based on stats from Bugzilla and the changelog. I suspect about everyone's conclusion on that would be different. I just wish to point out that while ref inlining has been pointed out as very important here, that isn't reflected in the Bugzilla votes. In other words, while the votes are important, they are not the only indicator of what is important.
Aug 29 2009
�� Sun, 30 Aug 2009 06:23:38 +0800��Walter Bright <newshound1 digitalmars.com> д��:Jarrett Billingsley wrote:If you've been consistently following the voting system as an indicator, people would just go to bugzilla and vote for this ref inlining bug instead of shouting here and playing the attracting Walter game. And you don't need to play the identifying the most important bug game either. -- ʹ�� Opera �����Եĵ����ʼ��ͻ�����: http://www.opera.com/mail/You said "which of the thousand things people want done should be done first?" And we already tried to solve this problem with the Bugzilla voting feature. Has it been working out well? Have the issues that people want to get fixed been getting more attention than the others?I'll let you decide that based on stats from Bugzilla and the changelog. I suspect about everyone's conclusion on that would be different. I just wish to point out that while ref inlining has been pointed out as very important here, that isn't reflected in the Bugzilla votes. In other words, while the votes are important, they are not the only indicator of what is important.
Aug 30 2009
On Sat, Aug 29, 2009 at 3:23 PM, Walter Bright<newshound1 digitalmars.com> wrote:Jarrett Billingsley wrote:IYou said "which of the thousand things people want done should be done first?" And we already tried to solve this problem with the Bugzilla voting feature. Has it been working out well? Have the issues that people want to get fixed been getting more attention than the others?I'll let you decide that based on stats from Bugzilla and the changelog. =suspect about everyone's conclusion on that would be different. I just wish to point out that while ref inlining has been pointed out as very important here, that isn't reflected in the Bugzilla votes. In other words, while the votes are important, they are not the only indicator of what is important.It's now up to 4 votes, which puts it in the top ~25. But just 3 more votes would put it in the top 10. http://d.puremagic.com/issues/show_bug.cgi?id=3D2008 http://d.puremagic.com/issues/buglist.cgi?bug_status=3DNEW&bug_status=3DASS= IGNED&bug_status=3DREOPENED&field-1-0-0=3Dvotes&field-1-1-0=3Dbug_status&qu= ery_format=3Dadvanced&type-1-0-0=3Dgreaterthan&type-1-1-0=3Danyexact&value-= 1-0-0=3D0&value-1-1-0=3DNEW%2CASSIGNED%2CREOPENED&votes=3D1&order=3Dbugs.vo= tes%2Cmap_assigned_to.login_name%2Cbugs.bug_id&query_based_on=3DMostVotes --bb
Aug 30 2009
"Walter Bright" <newshound1 digitalmars.com> wrote in message news:h7a1td$6n0$1 digitalmars.com...Ary Borenszweig wrote:for example releasing memory back to the OS on windows now and thenWalter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
== Quote from Walter Bright (newshound1 digitalmars.com)'s articleAry Borenszweig wrote:I'd say things should get a priority bump if they're either: 1. Major breaking changes. Let's get these out of the way so the spec can stabilize. 2. Bugs that substantially reduce the functionality of new/D-specific features, thus preventing comments on how these features might be improved, etc. 3. High bang for buck, i.e. something that, given the background of the person implementing it, would help a lot of people/situations for relatively little effort. For the most part, I agree that performance optimizations can wait. It's just that, when ref params are used at a very low level in Phobos (think swap() ), and it's easy for someone with the right background to implement ref inlining, that makes it a very high bang for buck optimization.Walter Bright escribi�:Which of the thousand things people want done in D should be done first?There are a lot of D specific optimization opportunities that are left undone for now.Why?
Aug 29 2009
On Fri, 28 Aug 2009 16:51:03 -0400, Walter Bright <newshound1 digitalmars.com> wrote:Jarrett Billingsley wrote:This is fine with me. I think the OP just wants to be sure that not inlining functions with ref args isn't a design decision. I think these kinds of limitations make people more sour than others because D lacks a manual inlining mechanism, with the explanation that the compiler knows how to inline better. Clearly, the compiler isn't there yet, and I understand why, I just wanted to bring to light why this might be a thorn in some sides. -SteveOn Fri, Aug 28, 2009 at 4:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:There are a lot of D specific optimization opportunities that are left undone for now.Jarrett Billingsley wrote:Well I'm glad it's that simple, and I'm sure Jeremie is too ;)You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 29 2009
Steven Schveighoffer wrote:I think these kinds of limitations make people more sour than others because D lacks a manual inlining mechanism, with the explanation that the compiler knows how to inline better.C++ lacks it, too. The "inline" keyword is a hint which the compiler is free to ignore - the C++ compiler can also inline functions with no such annotation.Clearly, the compiler isn't there yet, and I understand why, I just wanted to bring to light why this might be a thorn in some sides.Off the top of my head, I could list at least a hundred things people list as why they don't use D. I'd like to knock all those reasons down, and each release makes progress in doing so. But it is worthwhile to bring these things up. It helps in trying to gauge their relative importance.
Aug 29 2009
On Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:Jarrett Billingsley wrote:Wow. That's it? So let's get it done already! This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed. It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code. If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion. --bbYou're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 28 2009
On Fri, 28 Aug 2009, Bill Baxter wrote:On Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:Ok.. so we should expect a patch from you sometime soon? You did include yourself in the 'us' inside "let's", right?Jarrett Billingsley wrote:Wow. That's it? So let's get it done already! This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed. It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code. If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion. --bbYou're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.
Aug 28 2009
On Fri, Aug 28, 2009 at 3:21 PM, Brad Roberts<braddr puremagic.com> wrote:On Fri, 28 Aug 2009, Bill Baxter wrote:deOn Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:Ok.. so we should expect a patch from you sometime soon? =A0You did inclu=Jarrett Billingsley wrote:Wow. =A0That's it? =A0So let's get it done already! =A0This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed. =A0 It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code. =A0If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion. --bbYou're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.yourself in the 'us' inside "let's", right?I'm actually surprised Don hasn't jumped on this one, given that it's primarily numerical code that it seems to be affecting. If I were still at my old job using D heavily, I would probably take a whack at fixing this one, just because it has been such an annoyance to me. I put up with it figuring it would be fixed someday, and I assumed there must be something tricky about it or else it would have been done already. But given Walter's answer just now, it sounds like a quick fix for him or someone else familiar with the compilers internals. --bb
Aug 28 2009
Bill Baxter wrote:On Fri, Aug 28, 2009 at 3:21 PM, Brad Roberts<braddr puremagic.com> wrote:I imagined it would require deep understanding of the compiler back-end, which I don't currently have. Based on Walter's comment, perhaps it's not so difficult. I do have an FP performance patch in the next DMD. But I've been focussing more on ICE bugs and CTFE, which have been annoying me more.On Fri, 28 Aug 2009, Bill Baxter wrote:I'm actually surprised Don hasn't jumped on this one, given that it's primarily numerical code that it seems to be affecting.On Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1 digitalmars.com> wrote:Ok.. so we should expect a patch from you sometime soon? You did include yourself in the 'us' inside "let's", right?Jarrett Billingsley wrote:Wow. That's it? So let's get it done already! This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed. It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code. If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion. --bbYou're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?Because I never updated the inlining code to handle it.If I were still at my old job using D heavily, I would probably take a whack at fixing this one, just because it has been such an annoyance to me. I put up with it figuring it would be fixed someday, and I assumed there must be something tricky about it or else it would have been done already. But given Walter's answer just now, it sounds like a quick fix for him or someone else familiar with the compilers internals. --bb
Aug 30 2009
Don Wrote:I've been focussing more on ICE bugs and CTFE, which have been annoying me more.The focus on CTFE is pretty obvious from Walter's recent update to the changelog.
Aug 30 2009
Jason House wrote:Don Wrote:Don has been contributing a lot to the compiler work lately.I've been focussing more on ICE bugs and CTFE, which have been annoying me more.The focus on CTFE is pretty obvious from Walter's recent update to the changelog.
Aug 30 2009