[stdlib] Implement the new _modify accessor in Dictionary.subscript

[lorentey]

This enables in-place mutations of the key-based subscript.
These get rid of one of two full hash table lookup operations (including hashing the key) relative to the getter+setter approach. They can also eliminate COW copies in code like this:

dictionary[foo]?.append(bar)

(Admittedly this isn’t a very useful example.)

[lorentey]

@swift-ci smoke test

[lorentey]

Tests, motivating examples are not yet done. Implementation details will improve with #18790.

[slavapestov]

General question for @rjmccall - are we going to use this with arrays too, or are we going to keep addressors around as a language feature and synthesize a ‘modify’ out of them?

[rjmccall]

Addressors can't completely disappear because we have to bootstrap unsafe pointers somehow. But yes, #18840 can synthesize a modify from a mutable addressor.

[airspeedswift]

@swift-ci please smoke benchmark staging

[swift-ci]

Build comment file:

Performance: -O

TEST	OLD	NEW	DELTA	SPEEDUP
Improvement
IterateData	1756	1566	-10.8%	1.12x

Performance: -Osize

TEST	OLD	NEW	DELTA	SPEEDUP
Improvement
IterateData	1904	1690	-11.2%	1.13x (?)

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

---

[airspeedswift]

Huh. If we really were avoiding double-hashing, I'd have expected more signal from the benchmarks. Surely we must be doing lots of dictionary subscript assigns in them.

[lorentey]

We have benchmarks setting values, but simple subscript assigns (dict[foo] = bar) already hash just once - they don’t benefit from the new accessor. To demonstrate an improvement, we need to find an algorithm that performs in-place mutations on Optionals.

[lorentey]

Good thing benchmarks don’t exercise this yet — this should use self.count, not capacity. (As it stands, this causes a full 2x storage reallocation & rehash on every insertion.) 😳

[airspeedswift]

I guess the trouble is that nearly all the useful in-place mutations happen via the subscript(_:default:) version. dictionary[foo]?.append(bar) isn't useful but dictionary[foo, default: []).append(bar) is. As is histogram[name, default: 0] += 1.

[jrose-apple]

You should be able to use basically the same logic for subscript(_:default:), no? By the time you get to a modify accessor, you know you want to do the writeback.

[rjmccall]

subscript(_:default:) is already implemented with a mutable addressor. It could switch to a read instead of a getter, but that won't show any benefits until we optimize the SILGen of read a little.

It can switch to using an unsafe addressor, though.

[airspeedswift]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 653b68c

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 653b68c

[airspeedswift]

Trying again now #19085 is merged.

@swift-ci please test

[airspeedswift]

@swift-ci please smoke test

[airspeedswift]

@swift-ci please smoke benchmark

[airspeedswift]

Bout to merge this, just testing it one more time since it's been a couple of weeks

[lorentey]

@swift-ci smoke test and merge

[swift-ci]

Build comment file:

Performance: -O

TEST	OLD	NEW	DELTA	SPEEDUP
Regression
COWArrayGuaranteedParameterOverhead	9720	11718	+20.6%	0.83x

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

---