He literally said "Most women in the Bay Area are ... generally full of shit". How can you work with someone that thinks that, specially if you are a woman, say, in the Bay Area? And how can he do the job if people can't effectively work with him?
According to a review of New York Times: "Mr. García is not just a keen observer of corporate and social culture, but a thoughtful business and policy analyst armed with a highly refined detector for pretentious nonsense."
(https://www.nytimes.com/2016/06/29/business/dealbook/review-...)
It's much easier to market 64-bit than ARMv8. But what really matters are a new instruction set, more registers and better SIMD.
You have to give credit to Apple as they are indeed the first one to come out with a commercial SOC based on this and the first to get the OS support added.
fleitz's and eddieplan9's replies are generally accurate, so I won't repeat them.
The revised instruction set is the main thing. ARM's 32-bit instruction set is a bit odd, and the better 64-bit one will give a decent speed boost.
The ability to expand the address space beyond 4GB is nice, although not yet killer. The device still doesn't have enough RAM to need it, surely, but it still lets you do interesting things like memory map large files or play other fun address space games.
In addition to that, 64 bits also lets Apple make various improvements on their end, such as adopting tagged pointers (already seen on 64-bit Mac), which can be a big performance and memory win for certain kinds of code.
What 64-bit doesn't do:
1. Make code vastly faster. The performance increase will be somewhere in the neighborhood of 10-20%, not the huge gain some people seem to think. Some code could end up being slightly slower due to not doing anything that benefits from the new architecture while using up more memory and cache due to larger pointers, although this probably won't happen often.
2. Allow qualitatively different things to be done with the devices. For example, the linked article implies that fingerprint recognition and VPNs are both made possible by the 5S's 64-bitness, neither of which is even remotely true. Fingerprinting might be a bit slower without it, but not much. VPNs have been on iPhones for years, and 64 bits makes nearly no difference there, as CPU load isn't high for network-limited crypto anyway.
3. Make code easier to port or more compatible. For any halfway decent halfway modern code, the 32/64 divide is not a big deal at all. Maintaining a code base that works in both 32 and 64 is trivial.
4. Signal anything about future iOS/Mac convergence at Apple. A 64-bit CPU in an iPhone was inevitable. It's pretty much required once you want to go beyond 4GB of RAM, and extrapolating forward, iPhones will hit that limit soon. The only surprise (and let's not downplay it, it was a pretty big surprise) is that it happened now, and there's no real difference in terms of hypothetical Apple plans between a 64-bit ARM in 2013 and a 64-bit ARM in 2015.
64-bits has little to do with amount of addressable memory. In fact, 32-bit and 64-bit processors can address just as much. For example, 32-bit ARMv7 Cortex A15 can address up to 1TB of memory.
The only difference is amount of physical RAM you can map at once. Only virtual address space is limited in 32-bit processors. But even then, you can change the virtual-to-physical mappings at runtime. It's only inconvenient.
In theory true, but in a practical sense, roughly no real-world programs are going to use more RAM than they can actually address with a raw pointer, which means that roughly no real-world programs are going to take advantage of more than 4GB of RAM on a 32-bit CPU.
There are two things where the bit width of a processor matters. First there is the width of the address bus determining how much memory and I/O ports you can address - 32 bit buy you a maximum of 4 GiB, 64 bit a whole lot more, 16 EiB, that is 16 million TiB.
The other thing is the width of the registers determining the maximum size of the numbers you can process with a single mathematical or logical operation. The register width is also related to the addressable memory space because you have to store your memory addresses somewhere but this is not a hard relationship - you can stuff all kind of mapping logic between the registers and the address bus or combine several smaller registers to form a wider address - but it is quite common that the register width and the address bus width match.
Beyond more addressable memory you gain not that much. If you write your code carefully with no dependency on the bit width of the processor the compiler will happily perform the necessary transformations to make your code run even if you perform 64 bit math on a 8 bit processor. It will take a couple of instructions instead of just one, but it will work and be transparent for well written code.
If you have tight numerical code that requires 64 bit floats/integers you may see a speed up.
If your code is for some reason register starved you may see a speedup.
Take the case of an app that downloads some JSON and makes a UITableView, it's not going to run much faster on 64 bit vs. 32 bit unless you're doing some extremely compute intensive image transforms.
Given that Apple designs its own CPUs, I guess it would make sense to have a specific instruction for 'read 64 bits from this pointer, or, if it is a tagged pointer, extract the value from the tag'. Is that a good idea?
The question of hardware support for tagged pointers is interesting. Currently, objc_msgSend basically does (in pseudo-C):
if(self & 1) {
tagged_class_index = self & 0xf;
class = tagged_class_table[tagged_class_index]
} else {
class = *self;
}
And the rest is all common code that looks up the method implementation and jumps to it.
Within the method implementation itself, there will be some shifting to extract the value, but not much, since the method implementation already knows what class it's in:
value = self >> 4;
Producing new "instances" of the class as tagged pointers involves some shifting and logical ORing:
new_tagged_pointer = value << 4 | class_index;
(Note that class_index is conceptually a 3-bit value, but the runtime treats it as a 4-bit value for which the bottom bit is always 1. The tagged_class_table has 16 entries but only the odd-numbered ones are used.)
Most of this is really fast on any modern CPU. The one part that could potentially be slow is the if statement up at the top, since that's a candidate for mispredicted branches. I don't know how much it matters, but I'd say that that would be the one place where a dedicated instruction might potentially be of use. You could eliminate the branch yourself, except for the fact that dereferencing self when it's a tagged pointer will likely crash, so you have to avoid reading that value when you aren't going to use it.
My guess is that the penalty for the branch there is small, but you'd have to do some benchmarking to say for sure. If modern CPUs are indeed able to predict that branch (or run both sides to completion internally, since they're short), then there's no need for a new instruction.
At my office they have fruity tea options and I can tell you that the flavour gets into the coffee if someone previously brewed such teas. I don't want to imagine what a coffee brewed after one of this soups would taste like.
What I don't get is how come there are no such violence problems with drug cartels in the United States where surely they must be as large if not larger since the drugs get somehow distributed there (I'm assuming there's where most drugs handled by Mexican cartels end up).
The US police/government/courts are less corrupt and have more resources to crack down on the more visible violence.
There is more violence in America than most people realize. It's considered mundane so you don't see it in the news as much.
The US is selling arms to the cartels in Mexico, so their violence is escalated there.
Mexican cartels aren't larger in the US than in Mexico because their supply sources are in Mexico, they lose momentum over distance and face domestic competition as they move across the US.
I didn't mean Mexican cartels in the US, just cartels in the US in general. I don't buy that it just doesn't show up in the news, if people appeared decapitated or hanging from overpasses in the US I think you would see it mentioned in the news. The corruption and incompetence of Mexican police makes the problem more obvious since the government has to put the army and federal police on the streets to keep some control.
I think maybe in the US the cartels have reached some equilibrium that allows them to operate without so much violence and be discrete enough that they don't get bothered so much by the police.
a mom and kids gets caught in the crossfire. this was an accident, and how much news coverage does it get? had you heard about this story before?
the war is outside your house right now and you don't even know, because the casualties are almost universally poor people (okay maybe not outside your house because you might not be in the USA)...
The difference is that these apps were downloaded thousands of times before being removed. Getting thousands of people to go to your malicious website is probably much harder.
One of the benefits of this could be allowing them to drive-test private APIs in order to eventually make (or not, or alternative ones) them public eventually.
