Re^5: Run Perl 5 in the Browser! (JIT Compilation)

> I suspect everything that's pure Perl is may even be as fast or even faster than regular JavaScript, since WebAssembly should be faster than JavaScript, and it's a WebAssembly perl binary.

Really? Is WASM JIT-optimized?

I mean if a Perl Op-Code deals with Scalars will it automatically be optimized to integer if some tracker finds that all calls to the surrounding function always result to paths using Int?

That would surprise me...

> OTOH, at the moment I just want to use this for UI's, so as long as button clicks etc. don't cause 100% CPU or noticeable delays,

Don't you think that for little UI callbacks handling some AJAX compiling the whole Perl core to 4 MB WASM is kind of overkill?

Gimme some example Perl code for a start and I'll try to "B::Deparse" it into working JS.

> monkey patched with XS code.

Actually I'm wondering why this is not generally used for JITing Perl. (Probably some weird side effects or performance brakes of calling subs.)

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

Comment on Re^5: Run Perl 5 in the Browser! (JIT Compilation)

Replies are listed 'Best First'.
Re^6: Run Perl 5 in the Browser! by chromatic (Archbishop) on Aug 22, 2018 at 23:16 UTC
Actually I'm wondering why this is not generally used for JITing Perl. Three semi-informed guesses: Perl's internal data structures (SVs and casting between similarly shaped structs) don't make JITting easy. Perl's internal implementation (opcodes being a big mass of macros calling functions calling macros) doesn't make JITting easy. Code paths and function bodies are too long to JIT well. These can all be solved, but it would surprise me if they were solved easily.	[reply]
Re^7: Run Perl 5 in the Browser! by ikegami (Patriarch) on Aug 23, 2018 at 01:45 UTC
I think the fundamental problem is that Perl has too many hooks (operation overloading, constant overloading, variable type overloading, custom opcodes, etc) that prevent optimizations without changing the language. We can't even guarantee that `2` returns a number (e.g. when using `use bigint;`), so we're stuck with fat opcodes that must be able to accept any kind of value.	[reply] [d/l] [select]
Re^8: Run Perl 5 in the Browser! by chromatic (Archbishop) on Aug 23, 2018 at 17:59 UTC
Yeah, given that observing a variable at the Perl level could cause SV upgrades within an opcode, maybe it's better to say the challenges are: Polymorphic data structures at the C level; with SV upgrades in opcodes; leading to Large opcode function sizes We're not talking about JITting a five line Smalltalk method that's monomorphic across 80% of calls here. It would surprise me if the average opcode didn't expand to a size larger—and quite a few basic blocks more‐than LLVM wants to try to JIT.	[reply]
Re^9: Run Perl 5 in the Browser! by ikegami (Patriarch) on Aug 23, 2018 at 20:42 UTC
Re^8: Run Perl 5 in the Browser! by LanX (Saint) on Aug 23, 2018 at 04:26 UTC
JIT is about optimizing the main cases and observing the edge cases. You don't need guarantees because you just fall back to the generic solution if the input variables become unusual. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^9: Run Perl 5 in the Browser! by ikegami (Patriarch) on Aug 23, 2018 at 20:39 UTC
Re^10: Run Perl 5 in the Browser! by LanX (Saint) on Aug 24, 2018 at 12:49 UTC
Re^7: Run Perl 5 in the Browser! by LanX (Saint) on Aug 23, 2018 at 00:37 UTC
I'm not a JIT expert, but if one of the strategies is to reduce a dynamic type to a static one, one could use Inline::C to generate a static version of a functions body. I also remember Steffen Müller giving a talk demonstrating some Perl JIT. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^6: Run Perl 5 in the Browser! by haukex (Archbishop) on Aug 22, 2018 at 21:47 UTC
Is WASM JIT-optimized? I'm not an expert, but WebAssembly really is meant for running stuff much faster than JavaScript. Copy-and-pasting some quotes from https://webassembly.org/ and https://en.wikipedia.org/wiki/WebAssembly (see also https://developer.mozilla.org/en-US/docs/WebAssembly): WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. It is meant to enable executing code nearly as fast as running native machine code. The Wasm stack machine is designed to be encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms. And from https://bellard.org/jslinux/ (the original author of QEMU): ... I converted the JSLinux asm.js code to C and converted it back to Javascript with emscripten ! With a careful tuning, the new version is now faster than the hand-coded asm.js version. Here are some more virtual machines in the browser (although I'm not sure if they're WebAssembly, I just think it's cool): https://copy.sh/v86/ I haven't tested yet whether the 2-3x slowdown I measured compared to native code might be due to the debug assertions that I currently still have enabled. Don't you think that for little UI callbacks handling some AJAX compiling the whole Perl core to 4 MB WASM is kind of overkill?* It sure is! But it's Perl! :-D Seriously though, I think the overhead of loading WebPerl is fine for my use case: a single-page, long-running application that does a lot of data exchange with the server. Writing all the data-handling code in JavaScript was getting tiresome, something that Perl can really help with. If a web application consists of a lot of single pages, loading WebPerl into each of them is probably not going to be particularly performant. (* Update: In fact, I figured that if I can't get `perl` compiled with Emscripten, in the worst case I can boot a VM in the browser, run a `perl` in there, and communicate with that, and yes I'm aware of how insane that is `;-D` )	[reply] [d/l] [select]
Re^7: Run Perl 5 in the Browser! by LanX (Saint) on Aug 22, 2018 at 22:01 UTC
> It is meant to enable executing code nearly as fast as running native machine code. This means Perl's op-codes are executed at "native speed". But JS code is normally far better optimized by using JIT. The same algorithm in JS and Perl will normally run (much) faster in JS. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^8: Run Perl 5 in the Browser! by haukex (Archbishop) on Aug 22, 2018 at 22:08 UTC
This means Perl's op-codes are executed at "native speed". But JS code is normally far better optimized by using JIT. The same algorithm in JS and Perl will normally run (much) faster in JS. True, with Perl there's the additional layer of the execution of opcodes. I don't know much about JavaScript JIT, but if it's compiling to native machine code (and not something internal like WebAssembly), then yes, the same algorithm in JS should be faster than WebPerl.	[reply]
Re^9: Run Perl 5 in the Browser! by LanX (Saint) on Aug 22, 2018 at 22:23 UTC