Hacker News Reader

Comment by drivebyacct2 | Hacker News Reader

Can you give more technical details, I don't really understand at all how iOS would run worse on a similarly spec'd phone? I can understand how hardware component design would affect the physical build, but I don't see how it makes the processor or memory faster.

View on HN

It's things like bandwidth between components (EDIT and, in general, "fit" between components, and fit with the end-goal rather than with intermediate interfaces). I don't know Apple's internal design details, but they consistently out-perform competitors with higher specs. A good example is the Transformer Prime (quad-core) performing about the same as the iPad 2 (dual-core) - even though the Prime has a higher clock rate.

I think this is the review: http://www.anandtech.com/show/5163/asus-eee-pad-transformer-... While it's true that Apple has its own SoC, this is built from existing components: it's just that the components are packaged together, instead of distributed across a mobo.

When you have a very limited set of hardware, and work side by side with the people that made it, it's far easier to optimize your software vs. one company writing software for 20 other hardware companies they don't have direct contact with.

Months ago on Hypercritical [1], John Siracusa had a series of episodes where he was talking about weaknesses of programming in Objective C vs more dynamic runtimes like C#/Java, like garbage collection, dynamic typing, etc.

One of the advantages he cited & partially dismissed, though, was that since Objective C compiles directly onto the hardware, performance & battery life is better on ram- and cpu-limited phones compared to the added overhead of Dalvik or another virtual machine or JIT. (His theory was that that bought them time in the short term but is still a long term issue for Apple; I'm not sure I agree, but don't disagree Apple needs to be evaluating this stuff.)

[1]: http://5by5.tv/hypercritical/14

It probably helped more in 2007 vs. now; modern phones have a bit more horsepower to where they can afford to shrug off a VM. The narrow field of hardware helps significantly in terms of /feeling/ fast if not actually being faster. You'll note that Windows Phones are fairly snappy besides running on effectively year-old hardware and running everything* (including games, WinPhone doesn't support native code) on top of the CLR; since WinPhone only supports two SoCs (the Snapdragon 8x50 and 8x55), MS can pour all their energy into optimizing every last drop of performance out of that chipset.

* There's at least one exception in Trident (the IE rendering engine). Assuming most of the stock apps are CLR-based unless proven otherwise.

One marginal example: Rumor has it that the A5 ARM chip used in the iPhone 4S integrated technology from a company named "Audience" to better handle voice recognition for Siri:

http://www.macrumors.com/2012/02/06/audiences-earsmart-techn...

As time goes by, I'd expect "third party" SoC vendors to offer their customers an ever wider range of custom silicon, but there will likely always be advantages to being the "first party".

Reports indicate Siri computes primarily in the cloud (the whole sound file is sent), and that it's not on iPhone 4 for other reasons (e.g. reduce server load, increase 4S sales)

It computes in the cloud, but there's good evidence that the signal it computes on has at least been cleverly noise-filtered.

That is true, as people have ported Siri to the iPod Touch and iPhone 4, and it is performing exactly the same. Therefore, they either emulated a whole chip (highly unlikely) or everything is processed in the cloud/on the A4/5/#.

The A5 has several integrated processors for specific purposes, specifically relating to audio and video. The Audience chip is likely one, but there are also processors specifically for the purposes of handling video encoding or decoding, and other things, probably like cryptography.

Apple was not specific about what all the coprocessors are or what they do, which is why I'm being vague, but they have publicly announced that these are integrated into the SoC.

So the "Rumor" part is that one of them is from Audience. That there are custome co-processors has been revealed publicly.

I don't know much about iPhone hardware, but a good example of this is on the 2010 13-inch MacBook. Apple has been a leader in enabling their software to offload tasks to the GPU (see OpenCL, etc). This enabled them to stay a generation behind on their CPUs for MacBooks (keeping the Core 2 Duo alive longer than expected, giving several advantages) without falling too far behind on overall performance.

It would not run worse. The stuttering nature of Android is because of the software architecture decisions that were made early in development. The same is true with iOS. iOS places much higher priority on rendering and handling user input which is why it always appears so smooth.

That theory was debunked by members of the Android team shortly after that G+ post made its way around the internet. It has more to do with the number of drawable contexts and the limitations (still) of how they're handled in mobile processors.

Would you be able to link me to said post? If true I'd love to read it to correct my flawed understanding.

http://www.theverge.com/2012/1/14/2706760/the-mythical-ios-s...

Reply on news.ycombinator.com