Befunge
qbe-rs
Our great sponsors
Befunge | qbe-rs | |
---|---|---|
5 | 29 | |
18 | 66 | |
- | - | |
3.5 | 3.3 | |
7 months ago | 8 months ago | |
JavaScript | Rust | |
- | GNU General Public License v3.0 or later |
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.
Befunge
-
The Rust Performance Book
1. C compilers don't do a good job, & thus even CPython, which has historically stuck to rather vanilla C, uses computed goto, as described in https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...
I resorted to similar techniques in optimizing Befunge: https://github.com/serprex/Befunge (See bejit.c & marsh.c/marsh.h)
2. Rust enums are not variable sized, think of them as tagged C unions, where the Rust compiler can sometimes apply tricks to make Option> the same size as Vec
3. match can specialize for straight forward cases, when in doubt use https://godbolt.org
- Ask HN: Recommendation for general purpose JIT compiler
-
Why asynchronous Rust doesn't work
I've found async to be straight forward anytime I've used it. Promise#then is equivalent to callbacks
async/await often requires very little changes compared to synchronous code, whereas reworking a program into callbacks is much more impactful. & the async/await compilation process tends to produce better performance in addition to this. My first async/await work was a few years ago to increase a data importer's performance by an order of magnitude compared to the blocking code
Here's an example where looping made for a callback that recursively called, using async/await I get to use a plain loop:
before: https://github.com/serprex/Befunge/blob/946ea0024c4d87a1b75d...
after: https://github.com/serprex/Befunge/blob/9677ddddb7a26b7a17dd...
I don't see why people find it so complicated to separate begin-compute & wait-on-compute
I've since rewritten a nodejs game server into rust, https://github.com/serprex/openEtG/tree/master/src/rs/server... handleget/handlews are quite straight forward
- Python interpreter written in rust reaches 10000 commits
-
Compilers Are Hard
You'll also find them used in CPython's ceval.c
I use them in both my C befunge implementations:
https://github.com/serprex/Befunge/blob/c97c8e63a4eb262f3a60...
https://github.com/serprex/Befunge/blob/c97c8e63a4eb262f3a60...
qbe-rs
-
Odin Programming Language
> I think it uses a different backend than LLVM
harec uses https://c9x.me/compile/
-
Frontend for GCC?
Have you considered QBE?
- QBE – Compiler Back End
-
What do C programmers think of the Zig language in 2023?
I really hope other new projects (like QBE) can really grow and become widely used
-
Toy C compiler, worth having an IR stage?
I really liked targetting QBE (https://c9x.me/compile/) as an IR, as it gave me lots of back-end optimisations for free 😊.
-
C or LLVM for a fast backend?
There is: QBE.
-
A whirlwind tour of the LLVM optimizer
You might be underestimating the accuracy of the CPU models LLVM uses.
For x86, the same data the code generator uses drives llvm-mca[1], which given a loop body can tell you the throughput, latency, and microarchitectural bottlenecks (decoding, ports, dependencies, store forwarding, etc.)—if not always precisely, then still not worse then IACA, the tool written at Intel by people who presumably knew how the CPUs work, unlike LLVM contributors and the rest of us who can only guess and measure. This separately for Haswell, Sandy Bridge, Skylake, etc.; not “x86”.
Now, is this the best model you can get? Not exactly[2], but it’s close enough to not matter. Do we often need machine code to be optimized to that level of detail? Perhaps not[3], and with that in mind you can shave at least a factor of ten off LLVM’s considerable bulk at the cost of 20—30% of performance[4,5]. But if you do want those as well, it seems that the complexity of LLVM is a fair price, or has the right order of magnitude at least.
(Frontend not included, C++ frontend required to bootstrap sold separately, at a similar markup compared to a C-only frontend with somewhat worse ergonomics.)
[1] https://llvm.org/docs/CommandGuide/llvm-mca.html
[2] https://www.uops.info/
[3] https://briancallahan.net/blog/20211010.html
[4] https://c9x.me/compile/
[5] https://drewdevault.com/talks/qbe.html
-
Made my first LLVM front-end… Now what?
You can try buildling you own backend like llvm. A good example or starting point is probably QBE since it is extremely small but very functional.
- Best book on writing an optimizing compiler (inlining, types, abstract interpretation)?
-
Rust port of B3 from WebKit, LLVM-like backend
How big is the whole backend? I've heard that it is small but I wanted to compare it to QBE which is around 8 KLoC and it is quite interesting too.
What are some alternatives?
openEtG
ubpf - Userspace eBPF VM
Rustler - Safe Rust bridge for creating Erlang NIF functions
mir - A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR
minivm - A VM That is Dynamic and Fast
rune - An embeddable dynamic programming language for Rust.
c4 - C in four functions
well - The Future of Assembly Language. https://wellang.github.io/well/
bug - Scala 2 bug reports only. Please, no questions — proper bug reports only.
wasmtime - A fast and secure runtime for WebAssembly