Re: ARC vs Manual Reference Counting
Re: ARC vs Manual Reference Counting
- Subject: Re: ARC vs Manual Reference Counting
- From: Louis Gerbarg <email@hidden>
- Date: Wed, 11 Sep 2013 14:59:54 -0400
On Wed, Sep 11, 2013 at 6:58 AM, Dave <email@hidden> wrote:
>
> On 11 Sep 2013, at 05:04, Jens Alfke <email@hidden> wrote:
>
> >
> > On Sep 10, 2013, at 12:33 PM, Dave <email@hidden> wrote:
> >
> >> You with all this talk of memory management, you'd think that Apple (or
> someone) would have come up with a hardware solution for this by now. In
> the 70's and 80's I worked on some firmware and hardware that would handle
> garbage collection in real time (with a little help from OS Software).
> >
> > I’ve read through a lot of GC papers in the past, and I’m not sure what
> you’re talking about here, unless it’s something that allows extra tag bits
> to be stored in pointers. This was used a lot in old LISP systems; it can
> be useful with interpreted languages but I don’t think it’d be applicable
> to a C-based language. (A lot of the more sophisticated GC techniques
> simply don’t work with C-like code because it’s too low-level and makes too
> many assumptions about memory. For example, you can’t use compaction or
> copying collectors at all because objects can’t be relocated. The Obj-C
> garbage collector had to rely on inefficient conservative mark/sweep
> algorithms.)
>
> This was using aUnix Box/MS-DOS box and it was our own hardware, and yes
> it worked with C and Assembler (via a set of Macro's). Basically it was a
> lump of hardware that controlled allocating memory from a pool. It wasn't
> used for system memory (although it could have been), but as a way of
> speeding up certain Image Processing operations. Basically it could
> allocate or free a memory block in one machine cycle - it could also copy
> or fill a block much faster then the CPU too.
The world is a very different place than it was then, in the 80s RAM was a
lot faster relative to the CPU. There is absolutely no way something like
you describe today could be done today, most deeply pipelined OoOE CPUs can
barely forward a register in 1 CPU cycle. Getting out to L3 cache is often
on the order of 20-40 cycles depending on the part, and main memory can
literally be hundreds of cycles. Algorithms designed to work in an
environments with single cycle ram access simply don't hold up on modern
pipelined cache coherent multi-process systems where the processing logic
runs at significant multiples of the memory.
>
>> If Apple were to implement something like this I think there would be a
> massive increase in performance and reliability
> >
> > Nothing personal, but I think you’re falling into the common fallacy of
> thinking that Apple engineers are naive and/or ignorant. It happens all the
> time on these lists. In general, you should assume that the people working
> on system software are pretty damn smart and experienced, and are aware of
> all the techniques that an interested but non-expert outsider would know
> of. If they’re not using them, there’s probably a good reason for it.
>
> I'm sure the engineers are a mixture of good, mediocre, and not so good
> the same as any where else, why should Apple be different? But engineers
> don't get much say on what projects/features are implemented (especially
> somewhere like Apple, MS or any of the big 5 technology companies).
If you mean user features then sure, often engineers have little say. If
you mean runtime and developer features then you are wrong, the developers
at Apple have a lot of say in how what happens. Tim Cook and Phil Schiller
didn't sit down in a meeting and say "Let's implemented tagged pointers,
users will love those," and yet somehow we have them ;-)
Louis
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden