binaryen
sokol
Our great sponsors
binaryen | sokol | |
---|---|---|
14 | 38 | |
7,038 | 5,694 | |
1.4% | - | |
9.8 | 9.7 | |
7 days ago | 1 day ago | |
WebAssembly | C | |
Apache License 2.0 | zlib License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
binaryen
-
Bring garbage collected programming languages efficiently to WebAssembly
Interesting article, thanks!
Notes on the issues mentioned there:
* The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions).
* Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/...
* Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example).
* Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061
* The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet.
* Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority.
The author is right that stack walking, signals, and memory control are important areas that could help here.
Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.
The Binaryen wasm optimizer (mentioned in the article) is always open for contributions,
-
Random Testing of WebAssembly Implementations Using Semantically Valid Programs
The end of the related work section cites both wasm-smith and the Binaryen fuzzer (https://github.com/WebAssembly/binaryen/wiki/Fuzzing) and says, "They both provide a fuzzer that turns a stream of bytes into a WebAssembly module in order to test implementations. Their fuzzers always generate semantically valid test cases, but lack the targeting and tuning that Xsmith provides."
I look forward to reading more about how they do the targeting and tuning.
-
Web assembly book?
Binaryen or the LLVM of wasm: https://github.com/WebAssembly/binaryen
-
What's the best way to generate WASM programmatically?
Probably https://github.com/WebAssembly/binaryen/, there were various rust bindings to it.
-
Build a WebAssembly Language for Fun and Profit: Code Generation
The final phase of our compiler is code generation. This phase takes the AST and converts it to a set of executable instructions. In our case, WebAssembly. To accomplish this, we are going to use a popular WebAssembly compiler toolchain called binaryen.
-
Build a WebAssembly Language for Fun and Profit: Lexing
In this guide, we will be using TypeScript and NodeJS. The concepts are highly portable, so feel free to use the environment you're most comfortable with. Our only major dependency, binaryen, has a simple C API. You are welcome to skip ahead to the next section if you're using a different language.
-
Rust and WebAssembly without a Bundler
What are the size and performance benefits of processing the Wasm payload with wasm-opt?
-
Is WebAssembly Text (WAT) Just Another IR?
I would recommend looking into binaryen as it has it's own IR and can perform optimizations over it. It's also simpler than LLVM and has the option to produce binaries with debug names.
-
What are the advantages or disadvantages of compiling to VM Bytecode vs native machine code?
You can also use binaryen to optimize your wasm output
sokol
- STB: Single-file public domain libraries for C/C++
-
Container2wasm: Convert Containers to WASM Blobs
I'm using Dear ImGui for my cross-platform code (which includes running in browsers):
- https://floooh.github.io/visual6502remix/
- https://floooh.github.io/tiny8bit/c64-ui.html
- (start these samples by clicking on the little "UI" icon) https://floooh.github.io/sokol-html5/
Platform abstraction is handled through the sokol headers: https://github.com/floooh/sokol
-
New Vulkan Documentation Website
I wonder if using your library (https://github.com/floooh/sokol) instead of OpenGL will alleviate some of these issues for newcomers! There's already a sokol port of the learnopengl.com code (https://github.com/GeertArien/learnopengl-examples), so it shouldn't be too hard to match between the tutorial articles and these.
-
Meta Releases Intermediate Graphics Library
If you're looking for something like this, Sokol is a much simpler alternative:
https://github.com/floooh/sokol
It doesn't support vulkan though, but if that's important to you you're probably much better off just using vulkan directly since it's supported on all the major platforms.
-
Why glibc 2.34 removed libpthread
All I can do is give you a couple of Github ticket links where users of my libraries stumbled over the issue (and with different symptoms):
- https://github.com/floooh/sokol/issues/376
- https://github.com/floooh/sokol/issues/404
- https://github.com/floooh/cimgui-sokol-starterkit/issues/6
We then added a dummy call to a no-op pthread function, so that users can better figure out that they need to use -pthread because now they get a linker error instead of a runtime crash or hang. This has since reduced the 'support overhead' quite a bit:
-
File for Divorce from LLVM
My stuff for instance:
https://github.com/floooh/sokol
...inspired by:
https://github.com/nothings/stb
But it's not so much about the build system, but requiring a separate C/C++ compiler toolchain (Rust needs this, Zig currently does not - unless the proposal is implemented).
-
Website with Godot?
And I asked floooh for similar thoughts on making a website with sokol here: https://github.com/floooh/sokol/issues/825
-
I want to talk about WebGPU
It's not Rust and TS, instead C and JS, but Emscripten has a very nice way of integrating C/C++ and JS (you can just embed snippets of Javascript inside C/C++ source files), e.g. starting at this line, there's a couple of embedded Javascript functions which can be called like C functions directly from the "C side":
https://github.com/floooh/sokol/blob/4535a3b4be59eb912e77e04...
- Learn WebGPU
-
Looking for a C++ 2D/3D rendering engine/api.
Try sokol, but maybe it's look like low level for you https://github.com/floooh/sokol
What are some alternatives?
bgfx - Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.
raylib - A simple and easy-to-use library to enjoy videogames programming
tinyrenderer - A brief computer graphics / rendering course
LearnOpenGL - Code repository of all OpenGL chapters from the book and its accompanying website https://learnopengl.com
v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
nanovg - Antialiased 2D vector drawing library on top of OpenGL for UI and visualizations.
microui - A tiny immediate-mode UI library
gunslinger - C99, header-only framework for games and multimedia applications
computer-graphics-csc317 - Course Page for Computer Graphics course
wasm-bindgen - Facilitating high-level interactions between Wasm modules and JavaScript
imgui - Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
stb - stb single-file public domain libraries for C/C++