5 ms·

Mobile web apps may be slow because Moore's law is ending

35 points by iProject 13y ago

aswanson 13y ago
Maybe the slowing of this Law, which I am not convinced of per this article, will slow new hardware introduction. If this happens, perhaps this will allow closer optimization of applications to a small, relatively static hardware complement.
andrewflnr 13y ago
The original title is more accurate. This edited one doesn't do the piece justice. He really is talking about the end of an age. I was expecting some kind of snark, but not this. I'm glad I suffered through the page crashing my iOS browser once.
mtgx 13y ago
I think we have another 10 years or so until 2-3nm chips.
cliveowen 13y ago
Even if this is true, this only spells the end of exponential growth in hardware performance and the start of the more efficient software era. Engineering is all about finding the right compromises to get the job done given a set of restraints. When the HW performance becomes the major restraint then you just have to design around that.
nawitus 13y ago
>So Moore’s Law might be right after all, but it is right in a way that would require the entire mobile ecosystem to transition to x86. It’s not entirely impossible–it’s been done once before. But it was done at a time when yearly sales were around a million units, and now they are selling 62 million per quarter. It was done with an off-the-shelf virtualization environment that could emulate the old architecture at about 60% speed, meanwhile the performance of today’s hypothetical research virtualization systems for optimized (O3) ARM code are closer to 27%. Why do you need virtualization if the code is Java bytecode? Sure, this doesn't work for iPhone, but Android should be able to easily change the processor architecture. (If I'm not missing something here). There's already Android-x86 project.
- brokenparser 13y ago
  Besides ARM and x86, Android also runs on MIPS and PPC.
  - jordanthoms 13y ago
    And even for native code, it's generally easy to support multiple architectures (unless your code is arch-specific).
williamcotton 13y ago
Ok dudes, enough is enough. What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory? All I see are some carefully selected quotes from some "hardware engineers" who are doing nothing more than offering up their opinion. An "ex-Intel engineer" and a "robotics engineer" have a single paragraph. Really, this is your research? Some anonymous quotes, probably taken out of context? > I have consulted many such qualified engineers for this article, and they have all declined to take the position on record. This suggests to me that the position is not any good. Really. Do I have to go on?
- ippisl 13y ago
  You're right. There's a lot of interesting work on memristor memory, which is much cheaper and faster (and probably lower power) than RAM ,And a lot of interesting work on faster, lower power 3D memory interfaces. Those and other hardware innovations could have a huge effect on the garbage collection issue, and this whole debate.
- poutine 13y ago
  Agreed. If you look at the evidence we're doing quite well: http://browser.primatelabs.com/ios-benchmarks http://browser.primatelabs.com/ios-benchmarks (The iPhone 5 is 2.5x faster than the 4S and 12x faster than the iPhone 1)
  - deleted 13y ago
    [deleted]
- anon1385 13y ago
  >What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory? Could you quote the part where the author of this article or the original Why mobile web apps are slow article say that we have reached a hard "limit of performance and memory", because I don't see where they say that at all. The article I'm reading says this: Unchecked exponential growth has to end sometime, by definition, and this is how it would happen; not with a bang, but with a whimper. We won’t hit a wall, we’ll just…start…to…slow…down.
PavlovsCat 13y ago
“in a memory constrained environment garbage collection performance degrades exponentially.” The obvious solution, then, is to throw memory at the problem, no? Isn't the obvious solution to avoid garbage collection whenever possible? Just consider 'Date.now()' vs 'new Date().getTime()' - are we even trying? Shouldn't we start considering unnecessary garbage a bug, like a memory leak? That might not change everything, but it surely would help, no?
- mherkender 13y ago
  That's an interesting idea, but how does a language distinguish between memory leaks and regular non-leaks? Maybe some kind of metadata that informs the GC about how memory will be used so it can optimize memory usage and issue errors when the code fails to follow these rules? If we really start hitting these kinds of walls, I think that Javascript subsets (like asm.js) will become more prominent, but it's an interesting idea.
  - PavlovsCat 13y ago
    Then know that it was your interesting idea, since I wasn't thinking of anything automatic myself :) Maybe is possible to automate things like generating code that minimizes branching, or re-uses objects instead of destroying and allocating them all the time... but it's definitely possible, in some cases at least, to rethink the approach and reduce GC. Especially since there are usually trade-offs (using a fixed amount of memory "just in case" is distasteful for its own reasons), and the programmer might need to make an informed decision. But people still need to be aware of it first; making new objects for one time use is handy, and the normal way to go about things. It's certainly the default way tutorials tell you to get the time (even in game loops). At least personally, before today I didn't even know about Date.now(), and I never saw a discussion about any of this stuff in regards to libraries (how good or sloppy they are with GC)... it just doesn't seem to be on the radar, outside of gamedev. And by the time stuff gets sluggish by the accumulated little objects here and there, there is no easy fix, other than a whole lot refactoring or rewriting from scratch with it in mind.
nawitus 13y ago
One additional point is that even if .js doesn't improve much, mobile browsers can get a lot faster. iPhone's webview is a lot faster than Android's webview, so there's plenty of progress to be made especially with rendering.
poutine 13y ago
Even if you accept that giving web apps 10x more CPU than today they'd be equal to today's native apps (I don't accept this), you must acknowledge you've given 10x more CPU to the native apps too. And clever people will find impressive ways to use that CPU in native's advantage (witness all the neat physics stuff in IOS7).
andyl 13y ago
Performance anxiety for a whole class of devices that DIDN'T EVEN EXIST a few years ago, enabling GIANT NEW MARKETS. 'Our world is coming to an end.' Gotta love it.
sixQuarks 13y ago
Moore's law won't necessarily be progressing in a steady line. We will probably see more jumps and spikes as technology advances. Do you think computing power will only merely double once we take advantage of quantum computing? No, it will go up orders of magnitude in a short period of time. Our current progression with silicon based computing is slowing because we're reaching the physical limitations of that technology.
unono 13y ago
Phones should be thin clients anyway, the cloud provides the muscle. What use is packing compute into it. You just want it get smaller and zero energy use (using ambient energy for charging).
- walshemj 13y ago
  You will still have problems with latency and you cant get way from the fact that you need power to communicate via radio your not going to be able to cut down the power that the radio needs to use that much.
- mwcampbell 13y ago
  > What use is packing compute into it. 1. Do computation locally on local data, thus avoiding round-trips to a far away server. 2. Distribute an app to lots of people without having to pay for a lot of server resources to match, since the computation is done on each user's device. 3. Enable users to keep more data private, by keeping it on the user's own device.
malandrew 13y ago
Mobile web apps are slow because of layers upon layers of leaky abstractions and algorithms at each layer that still have a lot of room to be optimized. If you want a consistent 60 frames a second, you need to architect systems that complete the work that needs to render each frame within 16.6ms. If you can't complete all your computations within 16.6ms, you need to prioritize computations and spread them across frames.
cromwellian 13y ago
The article is right about Javascript, but wrong about why mobile web apps are slow. Most mobile web apps are not games nor image processing apps, they are simple content sites or form-driven applications that are not CPU bound and don't use a lot of JS. These apps are subjectively slower because of browser layout engine performance. Even on "heavy" JS apps, I've heard it said they only use 30% CPU. So if 70% time is not spent in JS, even if you run that 30% 50 times faster, at best you get a 42% speedup from 50 times better CPU performance. I feel the author has caused many to have the wrong take-away message, and the anti-web contingent are lapping it up. Mobile Wep Apps can be made to perform fast today, but it takes way way too much effort to tweak the CSS/DOM manipulations to avoid jank. Consider for example the need to manually "hint" you want GPU compositing by using identity CSS3 transforms. The rendering engines need to get better with leveraging the GPU and avoiding work when they don't need to. If you want to see what a herculean effort can achieve, see Sencha's FastBook. Basically, the author is right, but I think it's a red herring given that when people talk about "slow mobile web apps", 99% of the time, they are not talking about an Instagram written in JS, or AngryBirds in Javascript, but some basic news feed app.
ThomPete 13y ago
It is my experience that the biggest reason for why things are slow is that they need to fetch content from outside it's environment. I don't know if this affects JS ability to render it but it is at least my experience that JS based apps are simply not able to give me the same non-interupted feel as natively build ones, this includes even apps like RSS readers.
_random_ 13y ago
I think it's a favour. Coders shouldn't settle for a mediocre language and a dated platform just because they are ubiquitous.

35 points by iProject 13y ago

Maybe the slowing of this Law, which I am not convinced of per this article, will slow new hardware introduction. If this happens, perhaps this will allow closer optimization of applications to a small, relatively static hardware complement.

andrewflnr 13y ago

The original title is more accurate. This edited one doesn't do the piece justice. He really is talking about the end of an age. I was expecting some kind of snark, but not this. I'm glad I suffered through the page crashing my iOS browser once.

mtgx 13y ago

I think we have another 10 years or so until 2-3nm chips.

cliveowen 13y ago

Even if this is true, this only spells the end of exponential growth in hardware performance and the start of the more efficient software era. Engineering is all about finding the right compromises to get the job done given a set of restraints. When the HW performance becomes the major restraint then you just have to design around that.

nawitus 13y ago

>So Moore’s Law might be right after all, but it is right in a way that would require the entire mobile ecosystem to transition to x86. It’s not entirely impossible–it’s been done once before. But it was done at a time when yearly sales were around a million units, and now they are selling 62 million per quarter. It was done with an off-the-shelf virtualization environment that could emulate the old architecture at about 60% speed, meanwhile the performance of today’s hypothetical research virtualization systems for optimized (O3) ARM code are closer to 27%. Why do you need virtualization if the code is Java bytecode? Sure, this doesn't work for iPhone, but Android should be able to easily change the processor architecture. (If I'm not missing something here). There's already Android-x86 project.

brokenparser 13y ago
Besides ARM and x86, Android also runs on MIPS and PPC.
- jordanthoms 13y ago
  And even for native code, it's generally easy to support multiple architectures (unless your code is arch-specific).

williamcotton 13y ago

Ok dudes, enough is enough. What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory? All I see are some carefully selected quotes from some "hardware engineers" who are doing nothing more than offering up their opinion. An "ex-Intel engineer" and a "robotics engineer" have a single paragraph. Really, this is your research? Some anonymous quotes, probably taken out of context? > I have consulted many such qualified engineers for this article, and they have all declined to take the position on record. This suggests to me that the position is not any good. Really. Do I have to go on?

ippisl 13y ago
You're right. There's a lot of interesting work on memristor memory, which is much cheaper and faster (and probably lower power) than RAM ,And a lot of interesting work on faster, lower power 3D memory interfaces. Those and other hardware innovations could have a huge effect on the garbage collection issue, and this whole debate.
poutine 13y ago
Agreed. If you look at the evidence we're doing quite well: http://browser.primatelabs.com/ios-benchmarks http://browser.primatelabs.com/ios-benchmarks (The iPhone 5 is 2.5x faster than the 4S and 12x faster than the iPhone 1)
- deleted 13y ago
  [deleted]
anon1385 13y ago
>What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory? Could you quote the part where the author of this article or the original Why mobile web apps are slow article say that we have reached a hard "limit of performance and memory", because I don't see where they say that at all. The article I'm reading says this: Unchecked exponential growth has to end sometime, by definition, and this is how it would happen; not with a bang, but with a whimper. We won’t hit a wall, we’ll just…start…to…slow…down.

PavlovsCat 13y ago

“in a memory constrained environment garbage collection performance degrades exponentially.” The obvious solution, then, is to throw memory at the problem, no? Isn't the obvious solution to avoid garbage collection whenever possible? Just consider 'Date.now()' vs 'new Date().getTime()' - are we even trying? Shouldn't we start considering unnecessary garbage a bug, like a memory leak? That might not change everything, but it surely would help, no?

mherkender 13y ago
That's an interesting idea, but how does a language distinguish between memory leaks and regular non-leaks? Maybe some kind of metadata that informs the GC about how memory will be used so it can optimize memory usage and issue errors when the code fails to follow these rules? If we really start hitting these kinds of walls, I think that Javascript subsets (like asm.js) will become more prominent, but it's an interesting idea.
- PavlovsCat 13y ago
  Then know that it was your interesting idea, since I wasn't thinking of anything automatic myself :) Maybe is possible to automate things like generating code that minimizes branching, or re-uses objects instead of destroying and allocating them all the time... but it's definitely possible, in some cases at least, to rethink the approach and reduce GC. Especially since there are usually trade-offs (using a fixed amount of memory "just in case" is distasteful for its own reasons), and the programmer might need to make an informed decision. But people still need to be aware of it first; making new objects for one time use is handy, and the normal way to go about things. It's certainly the default way tutorials tell you to get the time (even in game loops). At least personally, before today I didn't even know about Date.now(), and I never saw a discussion about any of this stuff in regards to libraries (how good or sloppy they are with GC)... it just doesn't seem to be on the radar, outside of gamedev. And by the time stuff gets sluggish by the accumulated little objects here and there, there is no easy fix, other than a whole lot refactoring or rewriting from scratch with it in mind.

nawitus 13y ago

One additional point is that even if .js doesn't improve much, mobile browsers can get a lot faster. iPhone's webview is a lot faster than Android's webview, so there's plenty of progress to be made especially with rendering.

poutine 13y ago

Even if you accept that giving web apps 10x more CPU than today they'd be equal to today's native apps (I don't accept this), you must acknowledge you've given 10x more CPU to the native apps too. And clever people will find impressive ways to use that CPU in native's advantage (witness all the neat physics stuff in IOS7).

andyl 13y ago

Performance anxiety for a whole class of devices that DIDN'T EVEN EXIST a few years ago, enabling GIANT NEW MARKETS. 'Our world is coming to an end.' Gotta love it.

sixQuarks 13y ago

Moore's law won't necessarily be progressing in a steady line. We will probably see more jumps and spikes as technology advances. Do you think computing power will only merely double once we take advantage of quantum computing? No, it will go up orders of magnitude in a short period of time. Our current progression with silicon based computing is slowing because we're reaching the physical limitations of that technology.

unono 13y ago

Phones should be thin clients anyway, the cloud provides the muscle. What use is packing compute into it. You just want it get smaller and zero energy use (using ambient energy for charging).

walshemj 13y ago
You will still have problems with latency and you cant get way from the fact that you need power to communicate via radio your not going to be able to cut down the power that the radio needs to use that much.
mwcampbell 13y ago
> What use is packing compute into it. 1. Do computation locally on local data, thus avoiding round-trips to a far away server. 2. Distribute an app to lots of people without having to pay for a lot of server resources to match, since the computation is done on each user's device. 3. Enable users to keep more data private, by keeping it on the user's own device.

malandrew 13y ago

Mobile web apps are slow because of layers upon layers of leaky abstractions and algorithms at each layer that still have a lot of room to be optimized. If you want a consistent 60 frames a second, you need to architect systems that complete the work that needs to render each frame within 16.6ms. If you can't complete all your computations within 16.6ms, you need to prioritize computations and spread them across frames.

cromwellian 13y ago

The article is right about Javascript, but wrong about why mobile web apps are slow. Most mobile web apps are not games nor image processing apps, they are simple content sites or form-driven applications that are not CPU bound and don't use a lot of JS. These apps are subjectively slower because of browser layout engine performance. Even on "heavy" JS apps, I've heard it said they only use 30% CPU. So if 70% time is not spent in JS, even if you run that 30% 50 times faster, at best you get a 42% speedup from 50 times better CPU performance. I feel the author has caused many to have the wrong take-away message, and the anti-web contingent are lapping it up. Mobile Wep Apps can be made to perform fast today, but it takes way way too much effort to tweak the CSS/DOM manipulations to avoid jank. Consider for example the need to manually "hint" you want GPU compositing by using identity CSS3 transforms. The rendering engines need to get better with leveraging the GPU and avoiding work when they don't need to. If you want to see what a herculean effort can achieve, see Sencha's FastBook. Basically, the author is right, but I think it's a red herring given that when people talk about "slow mobile web apps", 99% of the time, they are not talking about an Instagram written in JS, or AngryBirds in Javascript, but some basic news feed app.

ThomPete 13y ago

It is my experience that the biggest reason for why things are slow is that they need to fetch content from outside it's environment. I don't know if this affects JS ability to render it but it is at least my experience that JS based apps are simply not able to give me the same non-interupted feel as natively build ones, this includes even apps like RSS readers.

_random_ 13y ago

I think it's a favour. Coders shouldn't settle for a mediocre language and a dated platform just because they are ubiquitous.