assert semantic change proposal
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Sun Aug 3 20:22:54 PDT 2014
On 8/3/14, 6:59 PM, David Bregman wrote:
> w.r.t the one question about performance justification: I'm not
> necessarily asking for research papers and measurements, but based on
> these threads I'm not aware that there is any justification at all. For
> all I know this is all based on a wild guess that it will help
> performance "a lot", like someone who optimizes without profiling first.
> That certainly isn't enough to justify code breakage and massive UB
> injection, is it? I hope we can agree on that much at least!
I think at this point (without more data) a bit of trust in one's
experience would be needed. I've worked on performance on and off for
years, and so has Walter. We have plenty of war stories that inform our
expertise in the matter, including weird stuff like "swap these two enum
values and you'll get a massive performance regressions although code is
correct either way".
I draw from numerous concrete cases that the right/wrong optimization at
the right/wrong place may as well be the difference between winning and
losing. Consider the recent php engine that gets within 20% of hhvm;
heck, I know where to go to make hhvm 20% slower with 50 lines of code
(compare at 2M+). Conversely, gaining those 20% were months multiplied
by Facebook's best engineers.
Efficiency is hard to come by and easy to waste. I consider Walter's
take on "assert" a modern, refreshing take on an old pattern that nicely
preserves its spirit, and a good opportunity and differential advantage
for D. If anything, these long threads have strengthened that belief. It
has also clarified to me that:
(a) We must make sure we don't transform @safe code into unsafe code; in
the first approximation that may simply mean assert() has no special
meaning in release mode. Also bounds checking would need to probably be
not elided by assert. I consider these challenging but in good, gainful
ways.
(b) Deployment of optimizations must be carefully staggered and documented.
Andrei
More information about the Digitalmars-d
mailing list