The Tablet Turning Point

OK, I’m late to the x64 party, so I’ll be more constructive. ARM calls its new 64-bit instruction set (which the iPad Air runs and to which all Apple iOS software has been updated) A64 (what AMD called x86-64 in the case of x86 chips) and calls the corresponding execution mode AArch64 (what AMD called “64-bit mode”).

But one is ambiguous and the other is a mouthful, so we in the iOS development community use what Apple suggested, ARM64 (which is, to keep the parallel, the equivalent of what Microsoft’s “x64” was for 64-bit x86)

EDIT: As far as I can tell, Google uses the term ARM64 as well for Android.

1 Like

For context, here are the default browser (IE11) scores of a Surface Pro 3 with Core i5 that I just ran myself. Next to each number is the iPad Air 2 results AnandTech reported using its default browser (Mobile Safari):

  • Google Octane 2 – 8745 / 9430
  • Mozilla Kraken 1.1 – 3310 ms / 4014 ms
  • Sunspider – 106 ms / 285 ms

Notice the iPad is faster than the Surface Pro 3 in one of those tests! And it is close in Kraken. The two major JS tests agree. Sunspider isn’t a terribly accurate test these days.

Hopefully MS can close the gap here in IE12, but if you use the default browser in Windows, you could get better web performance on an iPad now in some cases. This blows my mind.

Are there corresponding statistics on how desktop/laptop environments have improved over time? The relative stats between the two are more interesting to me. Say if you had a series of stock Macbook Airs and you saw that Chrome performance had hit a wall while tablet performance somehow was doubling.

Jeff, something is wrong with your Surface. My i5 (Surface Pro 3) just scored 19091 in Octane 2 in IE 11. Never mind that it’s a benchmark specifically tuned to Google’s priorities.

In the real world, I have more issues making things run smoothly in Chrome than IE. I was just complaining earlier on Twitter than Chrome can’t even do a simple CSS3 translate animation smoothly on my 4k monitor, where IE is like butter. Chrome also can’t handle something as simple as keeping a position:fixed element in place while scrolling with the mouse wheel or touch. And it doesn’t even support CSS3 animations without a prefix still.

The days of knocking IE for being behind are long over. Even legacy support is as bad or worse for me these days with iOS 6.0 users outnumbering IE <9 users, and it lacking more CSS features I find myself missing.

Interesting. I terminated the browser from task manager and tried again:

  • Kraken – 2160 ms
  • Octane – 11914

I do tend to have a ton of IE11 tabs open at any given time, though I use my Surface Pro 3 mostly as a browser, so that’d be all that was running. Let me install pending Windows updates, reboot, and try yet again.

edit: after reboot and Windows updates applied. All tabs closed except for the ones with the two benchmarks

  • Kraken – 2164 ms
  • Octane – 11666

I am running this from the touch / modern / x64 IE11, on battery, with afaik default settings. I haven’t tweaked anything that I know of.

Hmm, forgot that mine is on the Win10 preview, so it’s a newer build of IE (though it still calls itself 11 it’s probably got a good chunk of IE 12 work). It’s possible they’ve started tuning for some of the Octane tests like Chrome and Safari do. But that’s a pretty big jump from your number.

Are you closing all IE instances and pasting the URL of the page with the Start Octane 2.0 button into a new one, as they suggest?

Being on battery will make a small difference, but for me it only dipped down a few hundred points.

You are both comparing one tablet to another tablet. The article suggests tablets are getting closer to pc’s.

They are not because modern pc’s are still much faster.

Sadly though due to the lack of competition on the high end PC market that may change. Intel is not feeling any pressure to improve there. While they are feeling tons of pressure to improve on processors used in smaller devices, like tablets…

I’ve been hearing that argument for at least the last 7-8 years. Despite a few, mostly aborted, pushes in that direction we still seem as far away as ever. Don’t get me wrong - if offline caching and storage ever really get off the ground that will address at least half my argument (there’s more to it - but the offline part is by far the biggest).
Honestly I think it’s a shame the RIA movement has died out (for now) as that seemed to show the most promise (much as I hate Flash - but Silverlight was actually quite good. Well, potentially). I know that raises issues of its own but I hope to see another go in that direction in the next few years. I agree with the sentiment in that xkcd, just not the current execution.

I wrote about about all this a few years ago (some of what I wrote is already cringe-worthily out of date - especially my faith, at the time, in iCloud - but that’s all in-line with the title).

Towards the end of your post you mention issues with Chrome’s V8 engine on Android. Have you tried running the same benchmarks using a different engine / browser, e.g. Firefox? Of course it wouldn’t be representative of user experience, as few people use it, but it would be a good indication of what that tablet could do.

Most everyone I know already use their phone as their primary devices outside of work. I don’t even see that many tablets now, and I’m seeing newer and cheaper tv’s running Android which replace my need for even a media center machine.

I’d be interested to see how competing Android devices would rate on those charts, like the new Nexus devices or the LG G3. Of course it is progress for Apple to start outperforming Android devices that are a year or two older than them.

Yes, Firefox is even slower. From the Android based Nexus 7 (2013) on the Ember benchmark:

Chrome Beta: 1589ms
Chrome: 1750ms
Firefox for Android: 2446ms

That’s the same benchmark that the Nexus 9 scores 750ms, and the iPhone 6 scores 250ms.

1 Like

Bah, it’s sad to see this happen. The hardware on some of the newer / flagship devices kicks serious ass and it could probably overtake the latest iPad, but without proper code it’s useless.

Without impressive battery upgrades I don’t think we will see mobile devices catching PCs this year:
Javascript will never be as fast as native code (interpreted, hyper-flexible…), and mobile CPU’s won’t be as fast as desktop ones (unless batteries improve a lot), so web apps are not going to be as smooth as native apps in my opinion.
Also, native apps have more tools and integrate better with the system.

I think it is not the time yet.

Which carrier are you with? I frequently get 4G in the city and rarely less than 3G.

That said, I agree with your general point. It’s one of the Google Maps app’ biggest limitations, as far as I’m concerned, that it can’t display map data offline but relies on an always on connection.

Back with O2 now, who are slightly better (importantly I am usually reachable in the office now). For the last two years I’ve been with EE. No signal most of the time in the office - often nothing within half a mile of the office!

That’s why they invented asm.js, a statically-typed subset of JavaScript that’s intended to be written by compilers. While only Mozilla officially supports it, asm.js code (from C source) is part of the standard benchmarks all the JavaScript interpreters use.

Garbage collection does slow things down, which is why Apple ultimately got rid of it in Objective-C, but not for the reasons you might imagine. (Android still garbage collects.) On average, well-written garbage collection is faster in most cases than non-GC (in part because you don’t need to release if you only created temporary objects.) The cost is in predictable latency. A smooth mobile app is 60 frames per second, meaning the main thread needs to finish every 16ms. That’s not enough time for garbage collection. (Smooth non-touch apps can feel smooth with more latency.)

I don’t think you have to be at Google to fix bugs. It’s open source. Just send your patch, no?

Yeah, but this kind of hardcore JS language / compiler design stuff is way beyond my skill level.

1 Like

I can’t disagree with your information about performance of tablets versus some other form factor. However, you haven’t addressed something I find more compelling as I get older and my eyesite isn’t what it one was - display size.

As an example, I recently decided to replace my failing Nook HD+ 10" tablet with something else. I wasn’t interested in going smaller after enjoying the 10" display size and resolution of the Nook. I was looking for a tablet I could use as a reader (in portrait mode). What I discovered is that most tablets use screens with the aspect ratio of 16:9 or 16:10 meaning that when you use them in portrait mode, the screens are long and narrow. If you’re viewing a magazine on a 10" screen with a 16:9 aspect ration, the page is scaled to the display width reducing the page size to about what it would be on a 7 or 8" tablet. My Nook didn’t have this issue because the ratio was 3:2 which is a nice comfortable page size for reading which approximates that of a physical book. Here’s a comparison of different aspect ratios. My options came down to a small number of tablets where there wasn’t some trade-off I was forced into.

My point here is that since that majority of tablets and mobile devices are in the 8" range, they’re limited in use due to the size of the display. While we could run pretty much any app in a web browser on such a device, I don’t see that one could effectively use Photoshop on devices of this size. I see tablets as interim devices. Good enough for when using a full size device isn’t a practical option. As such, I don’t really see them entirely replacing full size devices.

3 years later, this is finally being fixed!

I can confirm we’re seeing big big improvements; excellent technical background here and here.