Conversation
|
Thanks for your pull request, @WalterBright! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
e4780dd to
d0fd9ab
Compare
spec/declaration.dd
Outdated
| ) | ||
|
|
||
| $(RATIONALE Alias reassignment can result in significantly faster compile times | ||
| and lowered memory consumption than the alternative recursive method.) |
There was a problem hiding this comment.
Citation? I was under the impression that this is currently inconclusive.
There was a problem hiding this comment.
I don't need a test to know that:
malloc(5);
is faster and uses less memory than:
malloc(5);
malloc(5);
:-)
There was a problem hiding this comment.
dlang/phobos#7756 (comment) Some plots on this. The performance increase is measurable but not particularly dramatic for staticMap
There was a problem hiding this comment.
I don't need a test to know that:
malloc(5);is faster and uses less memory than:
malloc(5); malloc(5);:-)
But that's exactly what static foreach is doing, it will syntaxCopy the foreach body N-times.
The rationale should simply be to provide an imperative alternative for constructing alias sequences vs the recursive way.
The performance is just an implementation detail. I hope it gives more performance though.
There was a problem hiding this comment.
@WalterBright The consensus appears to be to revise this bit as:
$(RATIONALE Alias reassignment can result in faster compile times and lowered memory consumption,
and requires significantly simpler code than the alternative recursive method.)
|
@atilaneves there is a lot of spec pull requests that @WalterBright has made that needs review from you as you took over @andralex leadership position on this. Can you spare some time and review this PR and other PR likes this that Walter has made? |
d0fd9ab to
99a7dbb
Compare
|
@atilaneves The text looks good editorially. I'm good for merging this if you and @ibuclaw are good now with the objection you raised. |
|
Merge? |
Needs WalTila approval. It's been something like 7 months now, needs a decision. There are probably lessons to be learned from how this has been handled. I say just merge, if something bad happens due to Alias Assign down the line it will likely be due to the implementation, and if we decide it's bad language design then the design itself can be deprecated reasonably smoothly as its use should be both fairly limited and mostly by the hands of people who know what they're doing and are either maintainers or in direct contact with maintainers. |
|
Does anyone have numbers on the actual impact on compile-times due to this? |
I have some nice graphs on some microbenchmarks, I spoke to John and Stefan about it IRL a few days ago, must have forgotten to post them. Will do so tomorrow (exam today) . Rough summary is that AliasAssign seems like a win in all but the extreme (when it becomes really really bad, but it's almost definitely an implementation issue, but sufficiently weird dynamics that it's hard to work out from what) |
|
@maxhaton So what's the verdict? Is the performance claim good to go? |
|
FWIW in all my real-world testing (building large apps) AliasAssignment has been a win or break even, with huge gains in code size and readability. |
|
Then I propose: |
s/fewer lines of/simpler/ |
|
Paging @WalterBright. |
Then perhaps also s/requires/results in/. |
I agree/concur with Andrei. This feature is still a little raw (Different syntax? It's a bit weird as is in the sense that it's not quite an assignment given the restrictions), but the code-size wins are really nice, and the blow-up losses seem to be an implementation problem which we can nail down (they are awful when you hit them, but we're talking staticMaps over thousands and thousands of elements here). |
How big was the median win? |
Say some 5%-7% but on a rather noisy setup that measured only the whole project bottom line. Let me know if precision is needed and I can set up a more rigorous experimental rig. |
|
Either the compiler behavior needs to be put behind a We can help prevent incidents like these from happening in the future by requiring (i.e. enforcing as part of CI) that the compiler test suite / Phobos / etc. are valid according to the official grammar. This will require first making a pull request to dlang.org, describing the language change, which only then will allow any changes to the reference implementation (DMD) to be merged. |
spec/declaration.dd
Outdated
| ) | ||
|
|
||
| $(RATIONALE Alias reassignment can result in significantly faster compile times | ||
| and lowered memory consumption than the alternative recursive method.) |
There was a problem hiding this comment.
@WalterBright The consensus appears to be to revise this bit as:
$(RATIONALE Alias reassignment can result in faster compile times and lowered memory consumption,
and requires significantly simpler code than the alternative recursive method.)
99a7dbb to
bdd2d2b
Compare
| $(GNAME AliasReassignment): | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK StorageClasses)$(OPT) $(GLINK Type) | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK2 expression, FunctionLiteral) | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK StorageClasses)$(OPT) $(GLINK BasicType) $(GLINK2 function, Parameters) $(GLINK2 function, MemberFunctionAttributes)$(OPT) |
There was a problem hiding this comment.
Sorry, how is this different from the AliasAssign rule added in #2868?
Furthermore, AliasReassignment is not referenced anywhere in the spec, which effectively makes this syntax not a part of the language. What does this grammar block describe exactly?
|
|
||
| $(GRAMMAR | ||
| $(GNAME AliasReassignment): | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK StorageClasses)$(OPT) $(GLINK Type) |
There was a problem hiding this comment.
Type is declared in type.dd, not in this file.
| $(GNAME AliasReassignment): | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK StorageClasses)$(OPT) $(GLINK Type) | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK2 expression, FunctionLiteral) | ||
| $(GLINK_LEX Identifier) $(D =) $(GLINK StorageClasses)$(OPT) $(GLINK BasicType) $(GLINK2 function, Parameters) $(GLINK2 function, MemberFunctionAttributes)$(OPT) |
Implementation: dlang/dmd#11846