5 ms·

I always assumed that compiling code to run in the browser would be slow, but OP points out that this is not the case. As the Emscripten project describes: > T

I always assumed that compiling code to run in the browser would be slow, but OP points out that this is not the case. As the Emscripten project describes: > Thanks to the combination of LLVM, Emscripten, Binaryen, and WebAssembly, the output is compact and runs at near-native speed. https://emscripten.org/ https://emscripten.org/

RobRivera 1y ago
Yellow bus syndrom in action for me today. Last week I never heard of Emscripten. Integrating SDL for a project, there were CMake callouta for APPLE, MSVC, and EMSCRIPTEN. And here we are seeing it again on hn in a few days. I should put an afternoon aside for some deep diving on it for context.
- scubbo 1y ago
  > Yellow bus syndrome in action for me today There's a certain irony to being able to introduce you to the term "Baader-Meinhof Phenomenon" (which is the more-common name for what I assume you're referring to, as Google searches for "Yellow Bus Syndrome" didn't bring anything up for me). Now you know the name, you'll see it everywhere!
  - 57473m3n7Fur7h3 1y ago
    The colloquial term they were misremembering is “yellow car” effect.
    - phatskat 1y ago
      Funny, I always called it “the GTA effect” as in either Grand Theft Auto 1 or 2, one of the top-down ones, once you got a particular kind of car you would see more of that same car on the road. I don’t know if it was an optimization strategy or just me falling victim to the effect I ascribed to the game.
      - 57473m3n7Fur7h3 1y ago
        In GTA III for example, which I have played a lot, it is definitely the case that it spawns a lot more of the players car, whatever model of car the player happens to be in. Various sources online say that it’s because only a certain number of cars fit in memory at the same time so they use the car of the player along with some others. It makes sense, but it would be cool to get that confirmed from someone who actually worked on the GTA games/engine.
        detaro 1y ago
        Later GTAs do this too, and at least for San Andreas I'm fairly sure its been confirmed by reverse engineering that that's how the engine works. Speedrunners use tricks to manipulate that cache so they have a better chance of getting something good.
    - scubbo 1y ago
      Thank you, TI(2)L!
burningChrome 1y ago
>> the output is compact and runs at near-native speed. This kind of subjective, no? I wonder what they consider "near native speed"? I couldn't find any real numbers in their documentation.
- gspencley 1y ago
  Not only is it subjective but V8 does so much to optimize JavaScript code that I wouldn't be surprised if the benefits for most applications were negligible anyway. Although JavaScript is still an interpreted language, it basically gets "compiled" when the browser parses the bundle. On the surface, the only thing WebAssembly automatically gets you is you get to skip the runtime compilation phase. I might be talking out of my ass, so take this with a grain of salt, but I wouldn't be surprised if once we start collecting real data on this stuff, SOME WebAssembly code could actually run slower than just using JS code. My hypothesis is that if you're starting with non-JavaScript code, you might be doing things in that language that would be slower to do the same way in JavaScript. I'm thinking of things like Array.map(), .filter() etc. ... which are hyper-optimized in V8. If you're taking an algorithm from C code or something which then gets compiled to WebAssembly, it's not an automatic given that it's going to compile to WebAssembly that is just as optimized as what V8 would do when it comes across those API calls. Again, this is just a hypothesis and I could be way off base. In any case, what we need is real world data. I have no doubt that for certain applications you can probably avoid land mines by hiring devs who are experienced building certain performance-critical things at a lower-level than your average JS dev... and their experience in those languages may transfer very well to the browser. In this scenario, you're not getting huge perf wins from using WebAssembly per-se... you're getting huge perf wins for not doing typical stupid, lazy, ignorant things that most average JS devs do ... like cloning large objects using the spread operator and then doing that over and over and over again "because immutability."
  - aDyslecticCrow 1y ago
    WebAssembly is still a flavour of assembly. It's only nearly native performance to the real code because the interface to JavaScript has overhead. Every action in JavaScript incurs overhead due to dynamic types and objects, as well as dynamic memory allocation and garbage collection. Wasm can theoretically ignore it all and run as if it were compiled for the host system, except when it needs to interact with the JavaScript environment. It's astonishing how fast JavaScript has become. But even if it were fully compiled, it would still be a language with higher overhead. You can still write bad code, or compile a language with high overhead into WASM. This remains valuable for porting existing libraries into the browser and reducing bandwidth usage. But properly done with a fast compiled language like c or rust.... wasm can unlock some magical things into the web ecosystem.

RobRivera 1y ago

Yellow bus syndrom in action for me today. Last week I never heard of Emscripten. Integrating SDL for a project, there were CMake callouta for APPLE, MSVC, and EMSCRIPTEN. And here we are seeing it again on hn in a few days. I should put an afternoon aside for some deep diving on it for context.

scubbo 1y ago
> Yellow bus syndrome in action for me today There's a certain irony to being able to introduce you to the term "Baader-Meinhof Phenomenon" (which is the more-common name for what I assume you're referring to, as Google searches for "Yellow Bus Syndrome" didn't bring anything up for me). Now you know the name, you'll see it everywhere!
- 57473m3n7Fur7h3 1y ago
  The colloquial term they were misremembering is “yellow car” effect.
  - phatskat 1y ago
    Funny, I always called it “the GTA effect” as in either Grand Theft Auto 1 or 2, one of the top-down ones, once you got a particular kind of car you would see more of that same car on the road. I don’t know if it was an optimization strategy or just me falling victim to the effect I ascribed to the game.
    - 57473m3n7Fur7h3 1y ago
      In GTA III for example, which I have played a lot, it is definitely the case that it spawns a lot more of the players car, whatever model of car the player happens to be in. Various sources online say that it’s because only a certain number of cars fit in memory at the same time so they use the car of the player along with some others. It makes sense, but it would be cool to get that confirmed from someone who actually worked on the GTA games/engine.
      - detaro 1y ago
        Later GTAs do this too, and at least for San Andreas I'm fairly sure its been confirmed by reverse engineering that that's how the engine works. Speedrunners use tricks to manipulate that cache so they have a better chance of getting something good.
  - scubbo 1y ago
    Thank you, TI(2)L!

burningChrome 1y ago

>> the output is compact and runs at near-native speed. This kind of subjective, no? I wonder what they consider "near native speed"? I couldn't find any real numbers in their documentation.

gspencley 1y ago
Not only is it subjective but V8 does so much to optimize JavaScript code that I wouldn't be surprised if the benefits for most applications were negligible anyway. Although JavaScript is still an interpreted language, it basically gets "compiled" when the browser parses the bundle. On the surface, the only thing WebAssembly automatically gets you is you get to skip the runtime compilation phase. I might be talking out of my ass, so take this with a grain of salt, but I wouldn't be surprised if once we start collecting real data on this stuff, SOME WebAssembly code could actually run slower than just using JS code. My hypothesis is that if you're starting with non-JavaScript code, you might be doing things in that language that would be slower to do the same way in JavaScript. I'm thinking of things like Array.map(), .filter() etc. ... which are hyper-optimized in V8. If you're taking an algorithm from C code or something which then gets compiled to WebAssembly, it's not an automatic given that it's going to compile to WebAssembly that is just as optimized as what V8 would do when it comes across those API calls. Again, this is just a hypothesis and I could be way off base. In any case, what we need is real world data. I have no doubt that for certain applications you can probably avoid land mines by hiring devs who are experienced building certain performance-critical things at a lower-level than your average JS dev... and their experience in those languages may transfer very well to the browser. In this scenario, you're not getting huge perf wins from using WebAssembly per-se... you're getting huge perf wins for not doing typical stupid, lazy, ignorant things that most average JS devs do ... like cloning large objects using the spread operator and then doing that over and over and over again "because immutability."
- aDyslecticCrow 1y ago
  WebAssembly is still a flavour of assembly. It's only nearly native performance to the real code because the interface to JavaScript has overhead. Every action in JavaScript incurs overhead due to dynamic types and objects, as well as dynamic memory allocation and garbage collection. Wasm can theoretically ignore it all and run as if it were compiled for the host system, except when it needs to interact with the JavaScript environment. It's astonishing how fast JavaScript has become. But even if it were fully compiled, it would still be a language with higher overhead. You can still write bad code, or compile a language with high overhead into WASM. This remains valuable for porting existing libraries into the browser and reducing bandwidth usage. But properly done with a fast compiled language like c or rust.... wasm can unlock some magical things into the web ecosystem.