<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 March 2014 10:49, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 3/14/2014 5:06 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In my experience, API layout is the sort of performance detail that library<br>
authors are much more likely to carefully consider and get right. It's higher<br>
level, easier to understand, and affects all architectures equally.<br>
It's also something that they teach in uni. People write books about that sort<br>
of thing.<br>
Not to say there aren't terrible API designs out there, but D doesn't make<br>
terrible-api-design-by-default a feature.<br>
Stuff like virtual is the sort of thing that only gets addressed when it is<br>
reported by a user that cares, and library authors are terribly reluctant to<br>
implement a breaking change because some user reported it. I know this from<br>
experience.<br>
I can say with confidence, poor API design has caused me less problems than<br>
virtual in my career.<br>
<br>
Can you honestly tell me that you truly believe that library authors will<br>
consider, as a matter of common sense, the implications of virtual (the silent<br>
default state) in their api?<br>
Do you truly believe that I'm making a big deal out of nothing; that I will<br>
never actually, in practise, encounter trivial accessors and properties that<br>
can't inline appearing in my hot loops, or other related issues.<br>
<br>
Inline-ability is a very strong API level performance influence, especially in a<br>
language with properties.<br>
<br>
Most programmers are not low-level experts, they don't know how to protect<br>
themselves from this sort of thing. Honestly, almost everyone will just stick<br>
with the default.<br>
</blockquote>
<br>
<br></div></div>
I find it incongruous to take the position that programmers know all about layout for performance and nothing about function indirection? It leads me to believe that these programmers never once tested their code for performance.<br>
</blockquote><div><br></div><div>They probably didn't. Library authors often don't if it's not a library specifically intended for aggressive realtime use. Like most programmers, especially PC programmers, their opinion is often "that's the optimisers job".</div>
<div><br></div><div>That said, function inlining is perhaps the single most important API level performance detail, and especially true in OO code (which advocates accessors/properties).</div><div>Function calls scattered throughout your function serialise your code; they inhibit the optimiser from pipelining properly in many cases, ie, rescheduling across a function call is often dangerous, and compilers will always take a conservative approach. Locals may need to be saved to the stack across trivial function calls. I'm certain it will make a big difference in many instances.<br>
</div><div><br></div><div>Compile some release code without -inline and see what the performance difference is, that is probably a fairly realistic measure of the penalty to expect in OO-heavy code.</div><div><br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I know what I'm doing, and even I, when I don't test things, always make some innocuous mistake that eviscerates performance. I find it very hard to believe that final-by-default will fix untested code.<br></blockquote>
<div><br></div><div>I don't find it hard to believe at all, infact, I find it very likely that there will be a significant benefit to client code that the library author will probably have never given a moments thought to. It's usually considered fairly reasonable for programmers to trust the optimiser to at least do a decent job. virtual-by-default inhibits many of the most important optimisations; inlining, rescheduling, pipelining, and also increases pressure on the stack and caches.</div>
<div><br></div><div>And that's the whole thing here... I just don't see this as obscure or unlikely at all. If I did, I wouldn't care anywhere near as much as I do. All code has loops somewhere.</div><div><br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And the library APIs still are fixable. Consider:<br>
<br>
class C {<br>
void foo() { ... }<br>
}<br>
<br>
and foo() needs to be final for performance, but we don't want to break existing users:<br>
<br>
class C {<br>
void foo() { foo2(); }<br>
final void foo2() { ... }<br>
}<br></blockquote><div><br></div><div>The length you're willing to go to to resist a relatively minor breaking change, with an unusually smooth migration path, that virtually everyone agrees with is surprising to me.</div>
<div>Daniel Murphy revealed that it only affects 13% of classes in DMD's OO heavy code. That is in line with my past predictions; most classes aren't base classes, so most classes aren't actually affected.</div>
<div><br></div><div>I understand that you clearly don't believe in this change, and I grant that is your prerogative, but I really don't get why... I just can't see it when considering the balance.</div><div>Obviously I care about the compiler's codegen more than the average guy; but as I see it, that's a compiler's primary purpose, and programmers are supposed to be able to trust that it can and will do it well.</div>
<div><br></div><div><br></div><div>My questions above, they were serious questions. Please, I would really like to hear you answer those questions, or rephrase them if you like...</div><div><br></div><div>Can you honestly tell me that you truly believe that library authors will consider, as a matter of common sense, the implications of virtual (the silent default state) in their api?<br>
</div><div><div>Or you don't consider that to be something worth worrying about, ie, you truly believe that I'm making a big deal out of nothing; that I will never actually, in practise, encounter trivial accessors and properties that can't inline appearing in my hot loops, or other related issues?</div>
</div><div><br></div><div><br></div><div>I won't post any more on the topic.</div></div></div></div>