Last time I checked on blink, it couldn't run dynamic executables (or ELFs that run with the dynamic interpreter), and would result in a segfault. How has it improved since then?
Is it actually 2x faster or 2x faster at starting up? QEMU does so much stuff, running cc1 on hello world isn't really a stress of the interpreter IMO as much as all the crap that goes around it.
Blink actually does run the GCC9 CC1 command from start to finish twice as fast. Qemu takes 600ms to run it and Blink takes 300ms. Both Qemu and Blink use a JIT approach. Since GCC CC1 is a 33mb binary, a lot of the time it takes to run it, it stresses the JIT pretty hard. https://twitter.com/JustineTunney/status/1610276286269722629
That's partly what I meant though, how fast is it at a longer running process? C doesn't require all that much semantic analysis so there usually isn't all that much hot code in the compiler, so it would suit a simple-fast JIT whereas QEMU does do some basic optimizations.
I've only ever really skimmed the TCG source code but it wouldn't surprise me if a new-er JIT could smack it's arse given that with these old C codebases (it's probably one of Bellard's few flaws) it's pretty hard to actually make true architectural changes.
The Java/script (I think more Javascript but I'm hedging my bets by including jvms too) JITs are probably the cutting edge but I'd imagine still quite beatable for a few cases.
Looks like it itself is not yet able to be compiled with Cosmopolitan Libc (though it emulates programs compiled with it) but it's planned - very cool!
Does it require cosmopolitan libc? I compiled a hello world example in C with `zig cc --target=x86_64-linux-musl` but when running it with Blink, nothing happened.
With memory safety turned on, could Blink be used as an alternative to WebAssembly?
At a glance, the debugger user interface looks much nicer than gdb's terminal ui. How tightly coupled is the debugger interface to the emulator/debugger engine? How much work would it be to plug in a different debugger, say lldb or gdb, into the ui instead of blink?
I think the user experience of cli debuggers is generally somewhat dreadful when compared to their gui cousins -- they seem to display a much narrower view of what's going on. Could the big blinkenlights debugger view be useful outside of blink itself?
Readit News
> Blink is now outperforming Qemu by 13% when emulating GCC.
Nice work. But isn't QEMU notoriously slow?
Dead Comment
It's a nice test also and can be useful for debugging.
https://www.youtube.com/watch?v=c6hnQ1RKhbo
Dead Comment
I've only ever really skimmed the TCG source code but it wouldn't surprise me if a new-er JIT could smack it's arse given that with these old C codebases (it's probably one of Bellard's few flaws) it's pretty hard to actually make true architectural changes.
The Java/script (I think more Javascript but I'm hedging my bets by including jvms too) JITs are probably the cutting edge but I'd imagine still quite beatable for a few cases.
Looks like it itself is not yet able to be compiled with Cosmopolitan Libc (though it emulates programs compiled with it) but it's planned - very cool!
My favorite FAQ
Deleted Comment
With memory safety turned on, could Blink be used as an alternative to WebAssembly?
I think the user experience of cli debuggers is generally somewhat dreadful when compared to their gui cousins -- they seem to display a much narrower view of what's going on. Could the big blinkenlights debugger view be useful outside of blink itself?
* https://github.com/pwndbg/pwndbg * https://github.com/longld/peda * https://github.com/hugsy/gef