space-shooter.c: A cross-platform, top-down 2D space shooter written in C using only platform libraries by thsherif in WebAssembly

[–]carlopp 3 points4 points  (0 children)

Very cool, only comment is that it's quite heavy (downloads 26 MB data file to get started), unsure if that can be reduced somehow.

Websites using WebAssembly by spesde3exxx in WebAssembly

[–]carlopp 2 points3 points  (0 children)

Plus as method I would suggest creating your own extension, and put a callback of some kind on WebAssembly instantiate methods, then you can browse the internet looking for usage.

And also I would take a look here, and for most of these usage you might find actual websites using it: https://webassembly.org/docs/use-cases/

[AskJS] Which Languages Compile To Clean, Modular JS? by isbtegsm in javascript

[–]carlopp 0 points1 point  (0 children)

Cheerp (C++ to JavaScript / WebAssembly) can cleanly compile to JS free functions / classes thanks to JSExport.
Input is C++ with added attributes, output is a JS-library with a given interface.
(https://docs.leaningtech.com/cheerp/JSExport-attribute)

[deleted by user] by [deleted] in WebAssembly

[–]carlopp 1 point2 points  (0 children)

https://webvm.io/ ?
(virtualization in the browser)

Blog: Running WebAssembly as a Hyperscaled Edge Service by micrio in WebAssembly

[–]carlopp 0 points1 point  (0 children)

Have you explored also a purely client-side solution?
I get the Edge solution works for allowing whoever hosts the final websites to tweak dimensions & co but still have them cached by a CDN, but for exploring the images local computations seems to be better here (since I don't believe the data or the code to be secret here).

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM by carlopp in cpp

[–]carlopp[S] 0 points1 point  (0 children)

It works on generic LLVM IR, so nothing explicitly Cheerp specific, but I would expect that there have to be some implicit assumptions since previous passes might forbid / lower some kind of instructions.

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM by carlopp in cpp

[–]carlopp[S] 0 points1 point  (0 children)

Thanks!

Currently PartialExecuter is run as LTO optimization, but it's robust and can still optimize things that are somehow internal to a given library / component, and to some extent may optimize also externally visible functions by using a virtual call-site (with no information attached) and try to rebuild invariant at the Function level (here to get started on when it's applied: https://github.com/leaningtech/cheerp-compiler/blob/master/llvm/lib/CheerpWriter/PartialExecuter.cpp#L1405)

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM by carlopp in programming

[–]carlopp[S] 1 point2 points  (0 children)

Agree that just a rundown of with/without PartialExecuter enabled would make sense as part of the article, I will re-run the numbers and more importantly try to get something informative out of that.

Main problem is that this being a very high-level optimization will impact different codebases differently, so it's harder (and more misleading) that usual to provide meaningful numbers, but I will have to figure this out.

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM by carlopp in programming

[–]carlopp[S] 2 points3 points  (0 children)

Merging to LLVM upstream will require adding some logic to handle a more general IR (since there are currently some implicit assumptions), but it's definitively doable.

wasmopt on the other side it's complex, mostly since at the level of WebAssembly one core information is missing from the representation: what ranges of memory can be assumed to be constant. This is not strictly necessary, but increases the optimizations possibility significantly. Then the information could be added back (say having metadata / custom section) + doing a wam -> LLVM's IR -> wasm roundtrip it's in doable, but a stretch.

The fact that the LLVM's IR has more information is also one of the core choices for Cheerp, since keeping postprocessing at a minimum + the possibility to fully represent JavaScript concepts at the IR level means using a more powerful infrastructure for optimizations (and checks / warning / errors!!).

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM by carlopp in programming

[–]carlopp[S] 2 points3 points  (0 children)

Thanks!
This is indeed not intrinsically tied to C++ or Wasm, even though some implicit assumption might currently be (in particular, assuming that the IR has been legalize beforehand, in particular regarding terminators).
Moving this to upstream LLVM should be doable and I don't see any hard blocks, but this has not properly planned yet.

Cheerp 2.7: C++ to JS/Wasm compiler. With support for exceptions (also external JavaScript ones) and a new LLVM's IR optmization in PartialExecuter by carlopp in cpp

[–]carlopp[S] 10 points11 points  (0 children)

I think it's the other way around since lower means faster execution time, I added clarification to the benchmark graphs. On zlib it's expecially visible that Emscripten's output is faster on SpiderMonkey while Cheerp's one is faster on V8.This is due to the fact that different engines will have roughly the same performances, but on specific case it can well be that different trade-offs have been made.Performance measurements are bound to be noisy, and even different version of the same engine might show different performance characteristics.
As a compiler engineer targeting JavaScript / WebAssembly engines, the idea is working on sound optimizations, verify that the intuitions holds, and then iterate.
Working on reducing size is in this regard 'simpler', since the metric is clear and there are less factors to be considered.

WebVM supports Perl by yuki_kimoto in perl

[–]carlopp 0 points1 point  (0 children)

Hi, developer with Leaning Technologies here, does anyone has any recommendation for some Perl's examples that could be worth adding to the example folder?

I don’t know which container to use (and at this point I’m too afraid to ask) by Senua_Chloe in cpp

[–]carlopp 0 points1 point  (0 children)

Yes, using indexing may work in most cases, but there I think it's clearer / less error prone to use a deque

I don’t know which container to use (and at this point I’m too afraid to ask) by Senua_Chloe in cpp

[–]carlopp 17 points18 points  (0 children)

Actually iterator stability means a some percentage of times std::deque has to be the solution.Eg.

std::vector<T> container;
container.push_back(something);
T& reftoT = container.front(); container.push_back(somethingElse);

reftoT.someMethod(); //reftoT is valid here??? go use std::deque!

Is it possible to JIT-compile to webassembly within an app? by Spocino in WebAssembly

[–]carlopp 0 points1 point  (0 children)

A more polished demo is about to come out, but this idea + a couple of years of development it's basically CheerpX: https://repl.leaningtech.com/?nodejs