On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
Any hint/numbers showing that this is actually useful?
Also doesn't a good backend optimizer already fuse writes?
Yes but you have this myth flying around that it is necessary
for good RC, because language like C++ do implicit sharing, so
RC must be done atomically, so the optimizer can't optimize.
Yes, ARC does the atomic RC too, but ARC is bound by prior focus
on manual RC without compiler support and should not be used as
an example to be followed.
D could go for a more generic solution with specialized
restricted integer types for resource tracking with different
capabilites. Same amount of work, but much more versatile.
The library could then use templated RCPointers with the
capabilites as parameters which recast the resource tracking
integer to the desired type which injects the appropriate
assumptions to the optimizer before/after each operation on the
integer.
E.g. for the non-transfer-to-other-threads/fiber integer counter
type:
1. the optimizer needs to know that below a specific
block/stackframe the test "counter==0" always fails.
2. semantics that ensures that contexts (fiber/thread) only are
allowed to subtract a value they already have added. Easy way out
is RAII.
