Hacker News new | past | comments | ask | show | jobs | submit login

Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine.

As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it




Well, the difference between "interpreted" and "compiled" has become very blurry during the last 20 years. These days, most "interpreted" programming languages are actually compiled to machine code on the client system.

This includes the JVML, of course, but also JavaScript, Python (with PyPy), etc. PHP isn't quite there yet, but it's coming.

> As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

It's slightly different, but native code is typically compiled concurrently, too. The meat of it is often handled by the build system rather than the compiler itself, but that's not so different.


It was always like that on the mainframe world.

Assembly was actually bytecode, with a micro-coded CPU doing the actual execution.

All Xerox computers were like that. The first boot step was to load the right kind of micro-code for the environment being started.

The AS/400 native environment (nowadays known as IBM i), is based on bytecode TIMI, which gets AOT compiled via a kernel level JIT.


PHP is there with HHVM


Which ironically isn't really any faster than PHP7 in the real world outside of benchmarks.

7 was a phenomenal release, I saw 50% reductions in processing time across the board and on old array heavy systems 5-10x memory reduction.


Thanks to pressure from HHVM I assume. Nothing was happening in the PHP language for freaking three years.

To be fair the benchmarks usually take a wordpress or drupal installation and do a requests per second measurement, which IMO is a real world benchmark.

No hate, I just don't get why hhvm doesn't get any love for what they did. Maybe because from HPHPc to HHVM they seriously gave the PHPc a competition and people kind of got mad.

https://kinsta.com/blog/the-definitive-php-7-final-version-h...


> Nothing was happening in the PHP language for freaking three years.

To be fair that's not because they where sleeping, but because they attempted to do something that proved too hard (unicode support) and they had to abandon it. That's why PHP skipped version 6.


>No hate, I just don't get why hhvm doesn't get any love for what they did.

I don't know - I expected to see a ton of Hack projects show up here but it's like no one cared about the language except as a wake-up call to PHP. Maybe the involvement of Facebook put people off.


My bad, I hadn't looked at that project in some time and I hadn't realized they had advanced that far.


And then modern microprocessors receive x86-64 instructions and decode them into underlying microcode.


> As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

Well, that's because typically all cores are maxed out during a parallel build of large-scale C++ software, so there's no need to go any further.

With link-time optimization it's a different story…hence the work some compilers (like rustc for Rust) are doing to parallelize builds of single compilation units.


There's a simple-but-useful WebAssembly Explorer at https://mbebenita.github.io/WasmExplorer/ that interactively shows the C/C++ -> WASM Text -> x86 ASM path that WebAssembly takes.

I wrote up a short article and video demonstrating it last year at https://hacks.mozilla.org/2017/03/previewing-the-webassembly...


> I did not realize that the WASM needs to be compiled into machine code on the client system

It doesn't need to be. This is a choice they've made. Other implementations of WASM could interpret it they wanted.

The Church-Turing thesis tells us that any program you can compile to machine code can also be interpreted, so it is not possible that any language needs to be compiled into machine code.


You can interpret wasm if you want, but considering the motivation for wasm is performance that kind of defeats the point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: