6 ms·

Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc

Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction. Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary builds). So, this seems to be interesting to (primarily) web applications. However, I try to avoid web apps, because they are typically proprietary, a moving target, the owner can randomly decide to charge me for things, or (ab)use my data, and they feel non-native. (I do see the benefit for people who use web apps, since WebAssembly is typically faster than Javascript and opens up web app programming to more languages.)

cjfd 7y ago
People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.
- not_a_cop75 7y ago
  Lol. Well, I mean nothing is outside of the realm of possibility, but remember those native Java chips! Some thought those were going to be a big win. And then you had companies like Transmeta trying to do the exact opposite - interpretively optimize all the things....or something like that.
  - microcolonel 7y ago
    Ultimately the features involved in optimizing WebAssembly are even more variable than they are for Java, so a Jazelle approach is probably even less useful.
  - CalChris 7y ago
    Transmeta JIT'd x86 into VLIW. That was right before the Power Wall became an obstacle and CPUs were already burning up. Transmeta in a sense invented low power computing but then Intel said thank you very much; we'll take it from here. It wasn't that they didn't deliver. It's just that they were competing against Intel in the x86 space. A lot of the Transmeta team moved to nVidia and work on Denver but that's different and they got an architecture license from ARM to do that.
- Ididntdothis 7y ago
  A long time ago they were talking about Java chips. That didn’t materialize and as far as I know there are no chips that run JavaScript natively so I wouldn’t hold my breath for WebAssembly chips.
  - CalChris 7y ago
    The Java chips were for, well, they were for Java. If ARM had designed Jazelle to be more general, it would have been useful for Javascript and Python and .... But they designed it for Java bytecode. The licensing was too expensive and so it didn't catch on and Jazelle got dropped from ARMv8.
- RubenSandwich 7y ago
  I don't know you are being downvoted. There are already instructions in ARM chips to help with JS floating-point conversion [1]. Yes, while the "Java chips" never got into the mass market[2], JS and it's ecosystem is eatting the world in a way Java never did and the trajectory is only increaing. P.S. I know WASM isn't JS, but I'd still consider it in the JS ecosystem. [1]: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... [2]: I did hear about some "Java Chips" for garbage collection back in the day.
- smallWheel 7y ago
  The web assembly application could also be compiled to a native binary, right? (something like an AOT compiled electron app)
not_a_cop75 7y ago
The point is obviously that web apps can be directly competitive with binaries, sans the same level of security, given they operate a lite version of the application. This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.
- danieldk 7y ago
  This makes it theoretically possible to run everything via cloud, if you didn't already see that coming. Yes. But my question is why would I want this? I won't own the software anymore. The web has shown over and over again to have far less privacy. The vendor could disappear, change their terms, change their fees any time. As a customer/user you become basically powerless. And for non-cloud applications: what's the point. My distribution already compiles and provides most of the software that I need and my machine doesn't need to waste time/energy on JITing.
  - kristiandupont 7y ago
    > The web has shown over and over again to have far less privacy This may be inherent to the web but a native app would (given the current level of sandboxing) have more freedom to make http requests than a webapp. So there would be no win in forcing the bad actors to make native apps. The argument about owning the software is a valid one, and I for one am not terribly excited about the continuous updates to everything which sometimes changes the UI of a tool that I use and know and cost me time out of the blue. However, I am using wallabyjs, a "native" app (plugin to vscode) and it updates itself practically every other day. I think that reality is hitting all kinds of software anyway.
  - wtetzner 7y ago
    As I understand it, WASM binaries have a well defined interface and can easily be sandboxed. Perhaps there would then be a way to just download WASM binaries from the web and run them locally, with your own sandbox restrictions imposed on them. I think the ability to sandbox these applications (even if they're not delivered over the web) might actually be the more valuable aspect of WASM.
usefulcat 7y ago
> Slower at an average of 50% looks acceptable to me for many applications. Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..
- tracker1 7y ago
  Native device platforms could do a system optimized AOT compile of WASM to Native as part of install. The distribution can be the same per platform, that doesn't stop a given platform from further optimization. Also, the single biggest battery use for most people is the screen, the CPU time is minimal by comparison and that 50% is only for the narrow CPU time the app isn't just waiting for input, and for many apps, that's most of the time (idle).
em-bee 7y ago
sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows) and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative. in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that. several apps run only on windows. some on mac and windows, some others on mac and linux. occasionally there is a mac or linux only application. and once in a while an application binary is available on all three. this is not even an issue of portability. even if the application is easily portable, i still depend on the developers choice of which OS they support. and i can't blame them. unless i am going to make money off the application i am not going to bother with supporting windows or macos. and most others will continue to ignore linux because the smaller market is still not always worth the effort. with webassembly we finally get a unified binary architecture. if an application run on webassembly, then the OS no longer matters. as someone that prefers to use linux. webassembly is like the holy grail. because if it manages to take hold, then hopefully the days of needing windows or a mac will be gone. that's the point.
- ScottFree 7y ago
  > sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows) Is that really a big deal, though? From what I understand (and I could be wrong, so correct me if I am), most of the headaches involved in multi-platform development is the OS specific UI. Video games, for example, don't find porting to multiple architectures all that challenging because 1) they design for it and 2) they're not expected to adhere to OS UI guidelines.
  - runevault 7y ago
    Games are also expected to be battery pigs, so doing 60+ FPS GPU rendering instead of however native UIs are rendered helps. Everyone certainly COULD just write their apps as 2d OpenGL but laptop battery life would suffer for it.
  - billti 7y ago

cjfd 7y ago

People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.

not_a_cop75 7y ago
Lol. Well, I mean nothing is outside of the realm of possibility, but remember those native Java chips! Some thought those were going to be a big win. And then you had companies like Transmeta trying to do the exact opposite - interpretively optimize all the things....or something like that.
- microcolonel 7y ago
  Ultimately the features involved in optimizing WebAssembly are even more variable than they are for Java, so a Jazelle approach is probably even less useful.
- CalChris 7y ago
  Transmeta JIT'd x86 into VLIW. That was right before the Power Wall became an obstacle and CPUs were already burning up. Transmeta in a sense invented low power computing but then Intel said thank you very much; we'll take it from here. It wasn't that they didn't deliver. It's just that they were competing against Intel in the x86 space. A lot of the Transmeta team moved to nVidia and work on Denver but that's different and they got an architecture license from ARM to do that.
Ididntdothis 7y ago
A long time ago they were talking about Java chips. That didn’t materialize and as far as I know there are no chips that run JavaScript natively so I wouldn’t hold my breath for WebAssembly chips.
- CalChris 7y ago
  The Java chips were for, well, they were for Java. If ARM had designed Jazelle to be more general, it would have been useful for Javascript and Python and .... But they designed it for Java bytecode. The licensing was too expensive and so it didn't catch on and Jazelle got dropped from ARMv8.
RubenSandwich 7y ago
I don't know you are being downvoted. There are already instructions in ARM chips to help with JS floating-point conversion [1]. Yes, while the "Java chips" never got into the mass market[2], JS and it's ecosystem is eatting the world in a way Java never did and the trajectory is only increaing. P.S. I know WASM isn't JS, but I'd still consider it in the JS ecosystem. [1]: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... [2]: I did hear about some "Java Chips" for garbage collection back in the day.
smallWheel 7y ago
The web assembly application could also be compiled to a native binary, right? (something like an AOT compiled electron app)

not_a_cop75 7y ago

The point is obviously that web apps can be directly competitive with binaries, sans the same level of security, given they operate a lite version of the application. This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.

danieldk 7y ago
This makes it theoretically possible to run everything via cloud, if you didn't already see that coming. Yes. But my question is why would I want this? I won't own the software anymore. The web has shown over and over again to have far less privacy. The vendor could disappear, change their terms, change their fees any time. As a customer/user you become basically powerless. And for non-cloud applications: what's the point. My distribution already compiles and provides most of the software that I need and my machine doesn't need to waste time/energy on JITing.
- kristiandupont 7y ago
  > The web has shown over and over again to have far less privacy This may be inherent to the web but a native app would (given the current level of sandboxing) have more freedom to make http requests than a webapp. So there would be no win in forcing the bad actors to make native apps. The argument about owning the software is a valid one, and I for one am not terribly excited about the continuous updates to everything which sometimes changes the UI of a tool that I use and know and cost me time out of the blue. However, I am using wallabyjs, a "native" app (plugin to vscode) and it updates itself practically every other day. I think that reality is hitting all kinds of software anyway.
- wtetzner 7y ago
  As I understand it, WASM binaries have a well defined interface and can easily be sandboxed. Perhaps there would then be a way to just download WASM binaries from the web and run them locally, with your own sandbox restrictions imposed on them. I think the ability to sandbox these applications (even if they're not delivered over the web) might actually be the more valuable aspect of WASM.

usefulcat 7y ago

> Slower at an average of 50% looks acceptable to me for many applications. Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..

tracker1 7y ago
Native device platforms could do a system optimized AOT compile of WASM to Native as part of install. The distribution can be the same per platform, that doesn't stop a given platform from further optimization. Also, the single biggest battery use for most people is the screen, the CPU time is minimal by comparison and that 50% is only for the narrow CPU time the app isn't just waiting for input, and for many apps, that's most of the time (idle).

em-bee 7y ago

sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows) and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative. in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that. several apps run only on windows. some on mac and windows, some others on mac and linux. occasionally there is a mac or linux only application. and once in a while an application binary is available on all three. this is not even an issue of portability. even if the application is easily portable, i still depend on the developers choice of which OS they support. and i can't blame them. unless i am going to make money off the application i am not going to bother with supporting windows or macos. and most others will continue to ignore linux because the smaller market is still not always worth the effort. with webassembly we finally get a unified binary architecture. if an application run on webassembly, then the OS no longer matters. as someone that prefers to use linux. webassembly is like the holy grail. because if it manages to take hold, then hopefully the days of needing windows or a mac will be gone. that's the point.

ScottFree 7y ago
> sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows) Is that really a big deal, though? From what I understand (and I could be wrong, so correct me if I am), most of the headaches involved in multi-platform development is the OS specific UI. Video games, for example, don't find porting to multiple architectures all that challenging because 1) they design for it and 2) they're not expected to adhere to OS UI guidelines.
- runevault 7y ago
  Games are also expected to be battery pigs, so doing 60+ FPS GPU rendering instead of however native UIs are rendered helps. Everyone certainly COULD just write their apps as 2d OpenGL but laptop battery life would suffer for it.
- billti 7y ago