Mike Ash

I can't really say it better than Mike Ash, so:

<quote>

Conclusion
The "64-bit" A7 is not just a marketing gimmic, but neither is it an amazing breakthrough that enables a new class of applications. The truth, as happens often, lies in between.

The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant.

The ARM architecture changed a bunch of other things in its transition to 64-bit. An increased number of registers and a revised, streamlined instruction set make for a nice performance gain over 32-bit ARM.

Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use.

</quote>

https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

Android's Java runtime is going to need a lot of work to make it pull off a runtime feat like tagged pointers.

I think the article vastly overstates its case. Nobody disputes that it's possible to have more-or-less working memory management in ref-counted Objective-C. But it's clearly harder than in a GC language, else it wouldn't need seven pages worth of "simple rules" to explain.

Moreover, the author glosses over many of subtleties of reference-counting. For example, accessors in Java are dead-simple, practically boilerplate. But in Cocoa, what looks like a perfectly reasonable implementation to a newcomer is in fact buggy:

- setFoo: (id)aFoo {
[foo release];
foo = [aFoo retain];
}

Look closely, and you'll realize that if foo and aFoo are in fact the same object, it will be freed, and foo will have an invalid pointer assigned to it. Pretty much every Cocoa programmer knows about this, but we shouldn't ahve to.

One of the better Cocoa blogs is written by Mike Ash, and he has quite a few posts that illustrate some of these issues. For example, the first half of http://www.mikeash.com/pyblog/friday-qa-2010-12-03-accessors-memory-management-and-thread-safety.html talks about whether or not accessors should autorelease their return values, with pros and cons for each option. Later on, the money quote: "If you're using garbage collection, this whole question becomes vastly simpler."

Our author here says that "Cyclic object graphs in Objective-C are not a problem. At all." But another post by Mike Ash illustrates that it can be harder to deal with:…

Here's some very personal advice. This is my opinion, and others won't agree. However, for what it's worth ...

I would suggest that you would benefit from learning how to ask questions. Here's a start:

http://www.catb.org/~esr/faqs/smart-questions.html

However, there's more advice than that, and that, although a good start, is not to be taken as gospel. You probably also should read the site-specific commentary, and suggested alternatives:

https://mikeash.com/getting_answers.html

https://news.ycombinator.com/item?id=2911381

The point is this - you said:

Well, TCP is a very simple protocol so I can't imagine
what the OP means by "all of TCP" unless he's talking
about IP and it's associated services.

Here's an alternative:

I'm not sure I understand what's been left out of this.
Could someone provide a synopsis, and a pointer to more
details?

Your comment comes across as "Well I know everything, so the only thing that's left out must be all the internet." The second admits that you don't know what people are talking about, and asks for more information.

And just as a final question - why do you think you've been hell-banned? Are you sure? In particular, I've turned on "Show dead", and you don't seem to have made any comments that have been auto-killed. The evidence suggests you are not hell-banned.

"The "64-bit" A7 is not just a marketing gimmic, but neither is it an amazing breakthrough that enables a new class of applications. The truth, as happens often, lies in between.

The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant.

The ARM architecture changed a bunch of other things in its transition to 64-bit. An increased number of registers and a revised, streamlined instruction set make for a nice performance gain over 32-bit ARM.

Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use."

[1] https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

> Not everyone is using linux.

Correct, it also fails on IOS the same way ( https://www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html#comment-6f3b9bf689eaf4ddec5473dd6dc1dce4 ), I haven't checked on more recent IOS versions, but it used to. I imagine that sooner than later apple may merge IOS and OSX kernels, who knows.

If the solution proposed is not to work on the 3 of the common operating systems(IOS, ANDROID, LINUX) adoption may be a problem.

> malloc can fail,

Yes, only if you allocate greater than the virtual address space in a process, or if you don't use an optimistic allocator (or disable overcommit) it could, I suggest you try this to find some REAL shady offenders that just abuse memory use, lodge bugs and then record the response (or lack thereof).

I have tried this for a bunch of utilities, and have had a hard time convincing software developers that they don't need to do insane things.

> and should fail.

I absolutely agree, fixing this problem means 'fixing and solving the problem for all software' which is something that is a very hard problem to solve, if you do find a way let me know.

"If we use a single bit dedicated to signalling NaN, the overhead might be worth it. Of course, we lose half of our range in doing so."

You don't need to lose half your range; you can also add a bit. You only need to add a sticky overflow bit to each register, keep the arithmetic hardware as-is, and modify loads to set the sticky overflow when reading the NaN pattern, and modify writes to write 0b1000...000 when writing a register whose sticky overflow bit is set.

Hardware cost would, I think, be very small, as you would only need a bit per register, and keep memory as-is.

Given that Apple has non-wrap around ints in Swift and designs its own CPUs, it wouldn't surprise me if they added something similar or their CPUs, just as I expect them to add instructions for loading from tagged pointers (https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html)