Skip to content

spec: add AliasReassignment#2919

Merged
mdparker merged 1 commit intodlang:masterfrom
WalterBright:AliasReassignment
Jul 3, 2021
Merged

spec: add AliasReassignment#2919
mdparker merged 1 commit intodlang:masterfrom
WalterBright:AliasReassignment

Conversation

@WalterBright
Copy link
Member

Implementation: dlang/dmd#11846

@dlang-bot
Copy link
Contributor

dlang-bot commented Dec 17, 2020

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

)

$(RATIONALE Alias reassignment can result in significantly faster compile times
and lowered memory consumption than the alternative recursive method.)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Citation? I was under the impression that this is currently inconclusive.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So was I.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't need a test to know that:

malloc(5);

is faster and uses less memory than:

malloc(5);
malloc(5);

:-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dlang/phobos#7756 (comment) Some plots on this. The performance increase is measurable but not particularly dramatic for staticMap

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.)

@12345swordy
Copy link

@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?

@mdparker
Copy link
Member

@atilaneves The text looks good editorially. I'm good for merging this if you and @ibuclaw are good now with the objection you raised.

@Imperatorn
Copy link
Contributor

Merge?

@maxhaton
Copy link
Member

maxhaton commented May 4, 2021

Merge?

Needs WalTila approval.

@WalterBright @atilaneves

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.

@atilaneves
Copy link
Contributor

Does anyone have numbers on the actual impact on compile-times due to this?

@maxhaton
Copy link
Member

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)

@mdparker
Copy link
Member

@maxhaton So what's the verdict? Is the performance claim good to go?

@andralex
Copy link
Member

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.

@mdparker
Copy link
Member

mdparker commented May 21, 2021

Then I propose:

$(RATIONALE Alias reassignment can result in faster compile times and lowered memory consumption, 
and requires significantly fewer lines of code than the alternative recursive method.)

@andralex
Copy link
Member

Then I propose:

$(RATIONALE Alias reassignment can result in faster compile times and lowered memory consumption, 
and requires significantly fewer lines of code than the alternative recursive method.)

s/fewer lines of/simpler/

@mdparker
Copy link
Member

Paging @WalterBright.

@mdparker
Copy link
Member

s/fewer lines of/simpler/

Then perhaps also s/requires/results in/.

@maxhaton
Copy link
Member

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.

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).

@atilaneves
Copy link
Contributor

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.

How big was the median win?

@andralex
Copy link
Member

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.

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.

@CyberShadow
Copy link
Member

Either the compiler behavior needs to be put behind a -preview flag (I'm guessing not doable because Phobos is using this) or this needs to be merged, because right now the reference implementation's behavior does not correspond to the official specification.

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.

)

$(RATIONALE Alias reassignment can result in significantly faster compile times
and lowered memory consumption than the alternative recursive method.)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.)

@WalterBright WalterBright dismissed mdparker’s stale review July 3, 2021 06:12

Implemented suggested change.

@mdparker mdparker merged commit 969ceb1 into dlang:master Jul 3, 2021
Comment on lines +509 to +512
$(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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@WalterBright

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


$(GRAMMAR
$(GNAME AliasReassignment):
$(GLINK_LEX Identifier) $(D =) $(GLINK StorageClasses)$(OPT) $(GLINK Type)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto for BasicType.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Comments