Swift does away with pointers == pervasive ARC
Manu via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jun 17 05:40:32 PDT 2014
On 17 June 2014 22:26, w0rp via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d wrote:
>>
>>
>> -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.
Huh? I'm not sure what you mean?
But yes, it appears that -Ofast enabled RC optimisations, which seems
like an important optimisation for an ARC based language.
> 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.
Maybe. But 'hot' code would never be crafted so carelessly. It's very
easy to refactor reference capturing outside of loops. It would become
second nature in no time if it was a requirement for good performance.
More information about the Digitalmars-d
mailing list