6 ms·

This is such a great demonstration of both how fast JS engines have become in the browser, and how much less efficient native software has become overall. Runni

by normac 11y ago

This is such a great demonstration of both how fast JS engines have become in the browser, and how much less efficient native software has become overall. Running on top of an x86 emulator in JavaScript, it's still faster to pop open a file browser and click around than it is on some modern smartphones.

tkinom 11y ago
I agree it is a very cool demo. Is there anyway I can find out the call flow of this JS program? Like to see the actual dynamic call flow graph instead of just simple static flow analysis output.
- tomc1985 11y ago
  That's because the Win98 code is that much simpler. It has less to do with speed and more to do with complexity. Your phone is doing all sorts of weird shit behind your back as you poke about. Stuff that it's not supposed to be doing if app-makers were actually respectful of their users... On that note, why does that crap take so long on smartphones anyway?
  - lukeadams 11y ago
    One tweak that made my G2 feel much more responsive is simply turning down the UI animation length in Dev Settings. That's not to say that app developers don't love their non-native webview apps crammed to the brim with ads, though...
    - tomc1985 11y ago
      UI animations have a lot to do with it, but I'm more referring to UI jank over simple stuff like 'enumerating a list of sharing targets' or 'swiping to the next page of the launchboard' when the phone is otherwise idle. Or, my favorites: the multi-second pause from unlocking my phone during a phone/skype call, or the taking of an actual eternity just to answer said fucking Skype call, of which half the time the call has already hung up once my phone is finally responding...
      - bitJericho 11y ago
        That's why I switched to windows phone. It's a whole new experience. I can actually answer my phone without the obligatory wait for catch up before I can swipe to answer.
  - orbitingpluto 11y ago
    Had a client who later wanted me to do add all sorts of nasty things to an Android app template that I had made for him: Locking out primary navigation buttons, partially replacing the home app, spying on the user, and the capability to send out very expensive SMS texts and auto dial long distance phone calls. Unfortunately I was unavailable to do the addons he wanted, despite him asking repeatedly over the next 18 months. Never trust an Android app...
  - rtpg 11y ago
    I think a big part of it is simply loading in resources and the like. Smartphones try to keep a _lot_ of apps in memory, so there's a lot of switching around. Another thing is that Windows would put certain native widgets (like file selection) on a higher priority than other program code. Android, at least, tries to put as much stuff in userspace as possible, so you might be experiencing the reality if everything run at the same priority.
  - agumonkey 11y ago
    I miss the shitty machinery of win9x days[1]. The weird part is that I was deep into CGI, and compositors made so much sense to allow for all kind of graphical operations; yet.. I miss the refreshed icons, blinking cursor .. as if I was one to one with that simple machine. That's very subjective, I'm in a minimalist passeist phase. [1] Except for the non isolated driver model.
    - i336_ 11y ago
      > I'm in a minimalist passeist phase. > ...one to one with that simple machine. Recommendation: Forth (cf. colorForth) Warning: Save snapshot of current mental state/perspective/worldview first, to guarantee sustained mental health :P
      - agumonkey 11y ago
        I regularly scan (ansi|gnu|color|*)Forth webpages. Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it.
        i336_ 11y ago
        > I regularly scan (ansi|gnu|color|)Forth webpages. I occasionally do too :P > Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it. I know the feeling... but I'm still at the "Lisp looks like parenthetical line noise, and what even is* ML?" stage, so I haven't yet tackled those. Forth, to me, seems to be bring out the "mechanicalness" of the computer, in a weird sort of way. Of course it's just another programming language, but the philosophy and mentality behind it seems to lean in that direction. I like it for that, and its minimalism. :D
        agumonkey 11y ago
        I love lisp and ml to bits, it's more that there's a whole cosmos to learn from there (type systems, macros, logic resolution, you name it). I kinda understand the mechanicalness of Forth, if you mean that there's only a few principles and that even 'syntax' is built on that. The kind of less is more that frees your mind
toyg 11y ago
Most modern smartphones run Android, which means they have a bastardized Java VM between your "native code" and actual metal... not unlike having a JS VM. It's not that "native software" has become less efficient, but rather that it is slowly disappearing.
- mwcampbell 11y ago
  As of Android 5.0, the Android Runtime (ART) compiles Dex bytecode ahead of time to native code. That probably still isn't as efficient as C++ or the like, because there's still a garbage collector, and Java methods are virtual by default.
drewcrawford 11y ago
You might think it's a great demonstration if you try it in a desktop browser. Meanwhile, on actual mobile hardware, the performance is so atrocious it's completely unusable. No knock on the implementors of course. But the idea that this demo has some deep insight about the performance of native smartphone software is just inaccurate. http://cl.ly/2O0L3t290s37 http://cl.ly/2O0L3t290s37
- normac 11y ago
  I didn't mean to compare native mobile apps to web apps (though I see now how it could be read that way). I'm talking about native software in general. I chose smartphones for the comparison because they're the most notorious about being slow, even as their hardware performance approaches what PCs were like just a few years ago. Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast. In general there's an arms race between hardware getting faster and native developers getting more and more lazy about efficiency. On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.
  - drewcrawford 11y ago
    > Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast. It is easy to take potshots at e.g. iTunes, but the real reason software "got worse" is not developers getting lazy. What happened is that expectations for CPU-intensive features rose (memory protection, ASLR, NX, encryption, low-latency audio, high-efficiency codecs, ClearType) while willingness to pay vanished. In Win98 times, you bought your music player from the developer (remember Winamp?) whereas now it comes free with your OS, which is itself probably free. So of course it is all half-assed now, but it's not "lazy" to spend resources on software someone will pay for, and not on software nobody will pay for. You could absolutely reverse this, but it has nothing to do with native or web technology, and everything to do with changing consumer attitudes about choosing software. > On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too. From 1995 until today, power consumption in desktop processors grew about 5-15x, depending on how exactly you measure. 5-15x more power on mobile devices is simply not an option, unless we have a "new physics" kind of breakthrough in both battery and thermal technology.
agumonkey 11y ago
I suspect smartphones to have crippled IO and memory subsystem. Marketing emphasize on "Hexa Core 128 bit Samsung silicon from the future" while the rest is subpar, leading to weird performance. JS engines are beautiful these days, especially given the adhoc nature of js, but a JVM should beat it hands down (based on blogs claiming reaching 1-3x C perf).
bitJericho 11y ago
I ran this successfully on my smartphone...
shultays 11y ago
how fast JS engines have become in the browser I am not so sure. It is more like "JS barely runs a software that has a recommendation of 66 mhz CPU". Maybe it is about emulation the whole system but still I was expecting better.

by normac 11y ago

tkinom 11y ago

I agree it is a very cool demo. Is there anyway I can find out the call flow of this JS program? Like to see the actual dynamic call flow graph instead of just simple static flow analysis output.

tomc1985 11y ago
That's because the Win98 code is that much simpler. It has less to do with speed and more to do with complexity. Your phone is doing all sorts of weird shit behind your back as you poke about. Stuff that it's not supposed to be doing if app-makers were actually respectful of their users... On that note, why does that crap take so long on smartphones anyway?
- lukeadams 11y ago
  One tweak that made my G2 feel much more responsive is simply turning down the UI animation length in Dev Settings. That's not to say that app developers don't love their non-native webview apps crammed to the brim with ads, though...
  - tomc1985 11y ago
    UI animations have a lot to do with it, but I'm more referring to UI jank over simple stuff like 'enumerating a list of sharing targets' or 'swiping to the next page of the launchboard' when the phone is otherwise idle. Or, my favorites: the multi-second pause from unlocking my phone during a phone/skype call, or the taking of an actual eternity just to answer said fucking Skype call, of which half the time the call has already hung up once my phone is finally responding...
    - bitJericho 11y ago
      That's why I switched to windows phone. It's a whole new experience. I can actually answer my phone without the obligatory wait for catch up before I can swipe to answer.
- orbitingpluto 11y ago
  Had a client who later wanted me to do add all sorts of nasty things to an Android app template that I had made for him: Locking out primary navigation buttons, partially replacing the home app, spying on the user, and the capability to send out very expensive SMS texts and auto dial long distance phone calls. Unfortunately I was unavailable to do the addons he wanted, despite him asking repeatedly over the next 18 months. Never trust an Android app...
- rtpg 11y ago
  I think a big part of it is simply loading in resources and the like. Smartphones try to keep a _lot_ of apps in memory, so there's a lot of switching around. Another thing is that Windows would put certain native widgets (like file selection) on a higher priority than other program code. Android, at least, tries to put as much stuff in userspace as possible, so you might be experiencing the reality if everything run at the same priority.
- agumonkey 11y ago
  I miss the shitty machinery of win9x days[1]. The weird part is that I was deep into CGI, and compositors made so much sense to allow for all kind of graphical operations; yet.. I miss the refreshed icons, blinking cursor .. as if I was one to one with that simple machine. That's very subjective, I'm in a minimalist passeist phase. [1] Except for the non isolated driver model.
  - i336_ 11y ago
    > I'm in a minimalist passeist phase. > ...one to one with that simple machine. Recommendation: Forth (cf. colorForth) Warning: Save snapshot of current mental state/perspective/worldview first, to guarantee sustained mental health :P
    - agumonkey 11y ago
      I regularly scan (ansi|gnu|color|*)Forth webpages. Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it.
      - i336_ 11y ago
        > I regularly scan (ansi|gnu|color|)Forth webpages. I occasionally do too :P > Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it. I know the feeling... but I'm still at the "Lisp looks like parenthetical line noise, and what even is* ML?" stage, so I haven't yet tackled those. Forth, to me, seems to be bring out the "mechanicalness" of the computer, in a weird sort of way. Of course it's just another programming language, but the philosophy and mentality behind it seems to lean in that direction. I like it for that, and its minimalism. :D
        agumonkey 11y ago
        I love lisp and ml to bits, it's more that there's a whole cosmos to learn from there (type systems, macros, logic resolution, you name it). I kinda understand the mechanicalness of Forth, if you mean that there's only a few principles and that even 'syntax' is built on that. The kind of less is more that frees your mind

toyg 11y ago

Most modern smartphones run Android, which means they have a bastardized Java VM between your "native code" and actual metal... not unlike having a JS VM. It's not that "native software" has become less efficient, but rather that it is slowly disappearing.

mwcampbell 11y ago
As of Android 5.0, the Android Runtime (ART) compiles Dex bytecode ahead of time to native code. That probably still isn't as efficient as C++ or the like, because there's still a garbage collector, and Java methods are virtual by default.

drewcrawford 11y ago

You might think it's a great demonstration if you try it in a desktop browser. Meanwhile, on actual mobile hardware, the performance is so atrocious it's completely unusable. No knock on the implementors of course. But the idea that this demo has some deep insight about the performance of native smartphone software is just inaccurate. http://cl.ly/2O0L3t290s37 http://cl.ly/2O0L3t290s37

normac 11y ago
I didn't mean to compare native mobile apps to web apps (though I see now how it could be read that way). I'm talking about native software in general. I chose smartphones for the comparison because they're the most notorious about being slow, even as their hardware performance approaches what PCs were like just a few years ago. Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast. In general there's an arms race between hardware getting faster and native developers getting more and more lazy about efficiency. On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.
- drewcrawford 11y ago
  > Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast. It is easy to take potshots at e.g. iTunes, but the real reason software "got worse" is not developers getting lazy. What happened is that expectations for CPU-intensive features rose (memory protection, ASLR, NX, encryption, low-latency audio, high-efficiency codecs, ClearType) while willingness to pay vanished. In Win98 times, you bought your music player from the developer (remember Winamp?) whereas now it comes free with your OS, which is itself probably free. So of course it is all half-assed now, but it's not "lazy" to spend resources on software someone will pay for, and not on software nobody will pay for. You could absolutely reverse this, but it has nothing to do with native or web technology, and everything to do with changing consumer attitudes about choosing software. > On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too. From 1995 until today, power consumption in desktop processors grew about 5-15x, depending on how exactly you measure. 5-15x more power on mobile devices is simply not an option, unless we have a "new physics" kind of breakthrough in both battery and thermal technology.

agumonkey 11y ago

I suspect smartphones to have crippled IO and memory subsystem. Marketing emphasize on "Hexa Core 128 bit Samsung silicon from the future" while the rest is subpar, leading to weird performance. JS engines are beautiful these days, especially given the adhoc nature of js, but a JVM should beat it hands down (based on blogs claiming reaching 1-3x C perf).

bitJericho 11y ago

I ran this successfully on my smartphone...

shultays 11y ago

how fast JS engines have become in the browser I am not so sure. It is more like "JS barely runs a software that has a recommendation of 66 mhz CPU". Maybe it is about emulation the whole system but still I was expecting better.