On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d
wrote:
On 17 June 2014 10:08, deadalnix via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via
Digitalmars-d wrote:
What say you to that, Walter?
Apple have committed to pervasive ARC, which you consistently
argue is
not feasible...
Have I missed something, or is this a demonstration that it is
actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does
basically what '-release -noboundscheck' does. You'd never try
and
benchmark D code without those flags.
The thing which slowed his loop down was the compiler not
removing the retain and release calls for ARC in that case. As he
says.
With -O3 I get something that was beyond my wildest
imagination. The inner loop spans 88 lines of assembly code. I
did not try to understand all of it, but the most suspicious
parts are 13 invocations of "callq _swift_retain" and another
13 invocations of "callq _swift_release". That is, 26
subroutine calls in the inner loop!
Obviously they can optimise these retain and release calls away.
However, I don't believe it will work with the right
optimisations in place for hot code. I think the only thing which
can work reliably in hot code is memory you manage yourself. I
don't think there's an automatic memory management scheme which
will do all of the work for you in most situations without
incurring some additional runtime cost.
