5 ms·

I'm somewhat disappointed with how this presentation portrays rather negative things as being positive in some way. It's not encouraging or enticing in any way

I'm somewhat disappointed with how this presentation portrays rather negative things as being positive in some way. It's not encouraging or enticing in any way for me to learn that I can compile my C and C++ to JavaScript, and it'll be "just 2X slower than native code" (but not until "later this year"). I don't consider that an accomplishment. Having to use at least twice the processing power to get the same result isn't something to laud, for example. It's wasteful, not beneficial. It surely shouldn't be something to be proud about. As an industry, we need to be moving forward. This means doing better than the best we already have. It does not mean only doing things half as well as we can already do, and pretending that we've somehow done something impressive.

exit 13y ago
performance isn't the only dimension along which things can move forward
- PommeDeTerre 13y ago
  Improvements in runtime performance often translate directly to significant benefits in other areas, too. That's why it's one of the most important things to improve upon. Faster program execution means better CPU utilization. More processing resources becomes available for other uses sooner, or fewer resources are needed to begin with. Faster program execution means better memory utilization. A program that finishes faster holds memory for a shorter amount of time, freeing it up for other uses sooner. Faster program execution means saving more energy, as a given amount of work can be completed using less processing effort. Faster program execution means a better user experience, which means more satisfied users. Faster program execution means the users can be more productive, as they're not waiting as long for processing to complete. Runtime performance may even be the most important factor to improve upon, given how it impacts so many other factors.
bradtgmurray 13y ago
Half the speed of native, but you're not comparing apples to apples. This slower code is also run in an environment where it's safe to download a random blob from the internet and just start running. This comes at some cost.
- hobs 13y ago
  Also, I think the argument that "slow" isnt moving us forward is just not thinking the issue entirely through. Most people writing code today would not be if not for slower (and more human understandable) languages. Why dont we just remove all keys from a developer's device besides 0s and 1s so they can program in the fastest computer language!
rtpg 13y ago
but if it comes at a 10x productivity boost it's worth it.
- PommeDeTerre 13y ago
  So where exactly does the "10x productivity boost" come from in this case? It's the same C and/or C++ code being compiled in both cases. It doesn't become any easier to write said code, just because it's compiled down to a mangled form of JavaScript rather than a native binary.
  - yowmamasita 13y ago
    he might e thinking of writing another language, which he's comfortable with, vs javascript - for portability
  - pkroll 13y ago
    I'm not sure if this is what rtpg was referring to, but... In this case, the 10x productivity would come from suddenly being able to use C/C++/other code that can be compiled to asm.js, which was previously not useful for client-side web apps unless you rewrote it by hand into JavaScript.
wpietri 13y ago
You're optimizing for the wrong resource. Computers serve humans, not the other way around. That means that unless you're optimizing for something that benefits people, you're probably making things worse. So yeah, if a program is just the same but is twice as slow in a way that harms user experience, then sure, that's bad. But if a program uses twice the CPU but is easier to develop and deploy, that's a win. For example, if somebody uses the technology to make MAME and its library available in every browser in the world, then that's great, because somebody just enabled a hell of a lot of fun. Sure, they could try to get everybody in the world to download and install a native copy and save a bunch of CPU time that wasn't going to get used anyhow. But that'd be a big waste of human life, a much more precious resource than CPU time.
- camus 13y ago
  twice the cpu kills the battery on mobile/tablet => it is harming user experience. Instead of trying to be native in a browser just be native on the plateform you bring the product. The web is not good for everything.
  - jasonlotito 13y ago
    Neither is native. And frankly, if your app is actually worth something, you should have a web version. Not everyone can afford a shiny new iPhone. And that does a thing far worse than harm the UX. It prevents those that would benefit most from using the app. You make it seem like the battery life is the only thing that matters.
  - wpietri 13y ago
    Depends on how much CPU you're using. Any app that is using a lot of CPU on a phone will kill the battery regardless. So I agree that if you're doing something where using 2x CPU will make a significant difference and you've already optimized things heavily, then sure, go native. But I'm sure that most apps on my phone are already using 2x the CPU they could be, and I just don't care.
vidarh 13y ago
Half as slow as native IS a large step forward. It isn't twice the processing power to get the same result, it is twice the processing power to be able to deploy the same app across vastly more platforms than you would be likely to target without it, and using languages that means you can easily target your main platforms with native builds should you choose to. That's what you are missing. Nobody has the resources to build native versions for every available platform, and it means a lot of useful tools and fun stuff is entirely unavailable to large groups of users. The accomplishment is that we're now close to having a platform that makes most code usable in a much more portable environment. And it's twice as slow now; performance will continue to improve. By your argument, are you writing everything in assembler? Because modern compilers still leave a lot to be desired and are nowhere near achieving maximal performance. For starters, they create a ton of stack frames that are unnecessary if you hand-tune an assembly program. Yet most of us don't program assembly anymore for a reason: It is rarely worth the time.
- Tloewald 13y ago
  Yes but javascript is a higher level language than C++, so it's more like advocating programming in 680x0 assembler and compiling it to C because the tools for 680x0 development are awesome and it runs almost half as fast as handwritten C.

exit 13y ago

performance isn't the only dimension along which things can move forward

PommeDeTerre 13y ago
Improvements in runtime performance often translate directly to significant benefits in other areas, too. That's why it's one of the most important things to improve upon. Faster program execution means better CPU utilization. More processing resources becomes available for other uses sooner, or fewer resources are needed to begin with. Faster program execution means better memory utilization. A program that finishes faster holds memory for a shorter amount of time, freeing it up for other uses sooner. Faster program execution means saving more energy, as a given amount of work can be completed using less processing effort. Faster program execution means a better user experience, which means more satisfied users. Faster program execution means the users can be more productive, as they're not waiting as long for processing to complete. Runtime performance may even be the most important factor to improve upon, given how it impacts so many other factors.

bradtgmurray 13y ago

Half the speed of native, but you're not comparing apples to apples. This slower code is also run in an environment where it's safe to download a random blob from the internet and just start running. This comes at some cost.

hobs 13y ago
Also, I think the argument that "slow" isnt moving us forward is just not thinking the issue entirely through. Most people writing code today would not be if not for slower (and more human understandable) languages. Why dont we just remove all keys from a developer's device besides 0s and 1s so they can program in the fastest computer language!

rtpg 13y ago

but if it comes at a 10x productivity boost it's worth it.

PommeDeTerre 13y ago
So where exactly does the "10x productivity boost" come from in this case? It's the same C and/or C++ code being compiled in both cases. It doesn't become any easier to write said code, just because it's compiled down to a mangled form of JavaScript rather than a native binary.
- yowmamasita 13y ago
  he might e thinking of writing another language, which he's comfortable with, vs javascript - for portability
- pkroll 13y ago
  I'm not sure if this is what rtpg was referring to, but... In this case, the 10x productivity would come from suddenly being able to use C/C++/other code that can be compiled to asm.js, which was previously not useful for client-side web apps unless you rewrote it by hand into JavaScript.

wpietri 13y ago

You're optimizing for the wrong resource. Computers serve humans, not the other way around. That means that unless you're optimizing for something that benefits people, you're probably making things worse. So yeah, if a program is just the same but is twice as slow in a way that harms user experience, then sure, that's bad. But if a program uses twice the CPU but is easier to develop and deploy, that's a win. For example, if somebody uses the technology to make MAME and its library available in every browser in the world, then that's great, because somebody just enabled a hell of a lot of fun. Sure, they could try to get everybody in the world to download and install a native copy and save a bunch of CPU time that wasn't going to get used anyhow. But that'd be a big waste of human life, a much more precious resource than CPU time.

camus 13y ago
twice the cpu kills the battery on mobile/tablet => it is harming user experience. Instead of trying to be native in a browser just be native on the plateform you bring the product. The web is not good for everything.
- jasonlotito 13y ago
  Neither is native. And frankly, if your app is actually worth something, you should have a web version. Not everyone can afford a shiny new iPhone. And that does a thing far worse than harm the UX. It prevents those that would benefit most from using the app. You make it seem like the battery life is the only thing that matters.
- wpietri 13y ago
  Depends on how much CPU you're using. Any app that is using a lot of CPU on a phone will kill the battery regardless. So I agree that if you're doing something where using 2x CPU will make a significant difference and you've already optimized things heavily, then sure, go native. But I'm sure that most apps on my phone are already using 2x the CPU they could be, and I just don't care.

vidarh 13y ago

Half as slow as native IS a large step forward. It isn't twice the processing power to get the same result, it is twice the processing power to be able to deploy the same app across vastly more platforms than you would be likely to target without it, and using languages that means you can easily target your main platforms with native builds should you choose to. That's what you are missing. Nobody has the resources to build native versions for every available platform, and it means a lot of useful tools and fun stuff is entirely unavailable to large groups of users. The accomplishment is that we're now close to having a platform that makes most code usable in a much more portable environment. And it's twice as slow now; performance will continue to improve. By your argument, are you writing everything in assembler? Because modern compilers still leave a lot to be desired and are nowhere near achieving maximal performance. For starters, they create a ton of stack frames that are unnecessary if you hand-tune an assembly program. Yet most of us don't program assembly anymore for a reason: It is rarely worth the time.

Tloewald 13y ago
Yes but javascript is a higher level language than C++, so it's more like advocating programming in 680x0 assembler and compiling it to C because the tools for 680x0 development are awesome and it runs almost half as fast as handwritten C.