Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

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

by LanX (Saint)
on Aug 22, 2018 at 21:28 UTC ( [id://1220873]=note: print w/replies, xml ) Need Help??


in reply to Re^4: Run Perl 5 in the Browser!
in thread Run Perl 5 in the Browser!

> 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

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.

      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.

        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.

        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

      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

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 )

      > 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

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1220873]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2024-03-29 08:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found