|
in reply to Re^3: Run Perl 5 in the Browser!
in thread Run Perl 5 in the Browser!
A general approach for performance enhancements could be to run Perl your way and to replace time consuming inner functions with direct JS translations.(kind of JIT if you want).
Yep, although I think it would only speed things up where the Perl<->JavaScript interface is involved, I suspect everything that's pure Perl 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. 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, I'm not going to worry too much about performance just yet.
From the Perl perspective these functions would have been monkey patched with XS code.
Yes, the interesting thing there is that "XS" code can include JavaScript code ;-) See WebPerl.xs, a mishmash of C, JS, and XS... (and my first real use of XS too!)
|
Re^5: Run Perl 5 in the Browser! (JIT Compilation)
by LanX (Saint) on Aug 22, 2018 at 21:28 UTC
|
> 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.)
| [reply] |
|
|
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] |
|
|
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] |
|
|
|
|
|
|
|
|
| |
|
| [reply] |
|
|
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] |
|
|
> 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.
| [reply] |
|
|
|
|
|
|
