10 ms·
Blink sounds cool, but this blog post is pretty thin. It's just restating a handful of tweets about Blink by its author.
by mtlynch 4y ago
Blink sounds cool, but this blog post is pretty thin. It's just restating a handful of tweets about Blink by its author.
- jart 4y agoAuthor of Blink here. Ask me anything :-)
- worthless443 4y agoLast 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?
- jart 4y agoIt has improved! What happens now is it prints an error: $ o//blink/blink /bin/ls error: unsupported executable; we need: - flat executables (.bin files) - actually portable executables (MZqFpD/jartsr) - statically-linked x86_64-linux elf executables Blink really isn't intended to run the binaries that come with your distro, because you're already able to run them. Blink is intended to let you transplant x86-Linux executables onto non x86-Linux systems. For example, I like to build programs on my x86 Alpine Linux machine and then scp them onto my M1 MacBook, Raspberry Pi, FreeBSD, and Windows machines. Blink lets me run them once I do that. Copying program files only makes sense if the program files are static. Linux distro executables can't be distributed to somewhere other than the distros that created them, unless a tool like Docker is used which recreates the whole distro. Blink is for people who want to be able to distribute Linux software without having to be in the Linux Distributor business too.
- forty 4y agoIf the binary is linked against a old enough version of glibc, it should run on most non exotic Linux distributions, shouldn't it? At least I feel I'm regularly installing things from people that are not in the Linux Distributor business and are not huge go binaries either (though admittedly, those seems to be trendy as well :) )
- flohofwoe 4y agoThose binaries might also just be statically linked with MUSL (at least that's how I'm building my distro-agnostic Linux command line tools). Same idea as Go binaries though (except that I haven't noticed that such binaries are particularly big versus binaries that link against glibc - of course you need some 'meat' in the tool, not just a plain 'hello world', but the difference is measured in kilobytes, not megabytes).
- jart 4y agoYes... You can technically spin up a RHEL5 VM and compile your code using GCC 4.2.1. That's what I think the Python community still does for manylinux1. The problem with that is GCC got so much better in the last fifteen years, that you might as well be programming with one hand. We shouldn't need to do that. There's nothing wrong with modern GCC 9+ which can produce backwards compatible binaries just fine. The problem is the policy decisions made by the Glibc developers. So if you can avoid Glibc and dynamic linking, then distributing to many distros and operating systems while using modern tools becomes easy.
- sidewndr46 4y agoWhere is the getting started guide for this?
- jart 4y agoHere's a gentle introduction. https://github.com/jart/blink/tree/master/third_party/sectorlisp#running-sectorlisp-in-blinkenlights https://github.com/jart/blink/tree/master/third_party/sector... See also https://justine.lol/sectorlisp2/ https://justine.lol/sectorlisp2/
- monocasa 4y agoWhat do you account for the perf win over Qemu? A bunch of micro optimizations, less abstraction layers, or something more systemic?
- jart 4y agoBlink is like a Tesla sports car whereas Qemu is like a locomotive. I think what may be happening, is Qemu has a lot of heavy hitting optimizations that benefit long-running compute intensive programs. But if you just want to run an big program like GCC ephemerally as part of your build system, the cost of the the locomotive gaining speed doesn't pay off, since there's nothing to amortize over. Blink's JIT also accelerates quickly because it uses a printf-style DSL and it doesn't relocate. The tradeoff is that JIT path construction sometimes fails and needs to be retried. Another great example of this tinier is better phenomenom, would be v8 vs. quickjs. Fabrice Bellard singlehandedly wrote a JavaScript interpreter that runs the Test262 suite something like 20x faster Google's flagship V8 software, because once again, tests are ephemeral. It's amazing how much quicker QuickJS is. But if you wanted to do something like write a JS MPEG decoder to show television advertisements without a <video> tag then v8 is going to be faster, since it's a locomotive. Fabrice Bellard wrote Qemu too. But I suspect his Tiny Code Generator has gotten a lot heftier over the years as so many people everywhere contributed to it. I really want to examine his original source code, since I'd imagine what he originally did probably looked a lot more like Blink than it looks like modern Qemu.
- deleted 4y ago[deleted]
- andai 4y agoFascinating. Most JS code is ephemeral, i.e. rarely is something as intensive as video encoding done in the browser (and even then WebAssembly would usually be preferred). It seems to me like browsers would benefit from running most code in QuickJS, and then spinning up V8 only for those rare cases of long-running JS?
- nightpool 4y ago
- Y_Y 4y agoWhy bother making this? (even if it is really cool)
- trashburger 4y agohttps://justforfunnoreally.dev/ https://justforfunnoreally.dev/
- jart 4y agoWe do what we must because we can.
- gabcoh 4y agoThe comparison with QEMU is with KVM disabled, right? Assuming this is true, how does it compare with KVM enabled?
- fwsgonzo 4y agoKVM allows you to run guests directly on the CPU and has native performance
- monocasa 4y agoWell, not quite 'native'. TLB refills are 4x to 5x as expensive, and anything that needs a context switch tends to be at a minimum twice as expensive, and it's common to balloon even farther from there.
- fwsgonzo 4y agoI guess that's mostly if you are running a full operating system inside it, generally in Qemu. It doesn't have to be - could just be a program. Tiny programs running in KVM can use big pages and never cause or require any pagetable changes. For simple workloads it can even be faster than native unless you dynamically load something that uses bigger pages for your native program, eg. https://easyperf.net/blog/2022/09/01/Utilizing-Huge-Pages-For-Code https://easyperf.net/blog/2022/09/01/Utilizing-Huge-Pages-Fo...
- monocasa 4y agoIt's harder to force huge pages on a guest than it is to just use them in regular user space where you can simply mmap them in. And none of that accounts for the increased context switch time.
- fwsgonzo 4y agoThe guest is not in control - sure theres a few pages at the beginning of each section that has to be 4k until you reach the first 2MB-multiple. What context switch time? It takes 5 micros to enter and leave the guest. The rest is just "workload". The point is: KVM is native speed if you never have to leave. I don't need to prove this for anyone to understand it has to be true.
- britneybitch 4y agoThat reverse debugging feature looks cool. At a high level, how does it work?
- jart 4y agoVery simply. Took three hours to code. Blink just takes a "screenshot" of the ANSI terminal display, gzips it, and appends it to a ring buffer with 64,000 entries. Each screenshot is a full frame. There's no delta encoding or anything smart like that. 64k gzipped frames takes a few hundred megs of memory once it fills up, depending on how big your terminal display is. My favorite part is that, when you press the 'c' button to continue execution, Blink will only transmit 60 FPS to your terminal. In-between frames, it's still capturing screenshots in the background, which get added to the ring buffer. It'll save thousands of frames per second, so you can skim through execution pretty quickly, like a tv show, and then maybe you'll see something happen, smash ctrl-c, and scroll backwards slowly with fine-grained per-instruction granularity, thus illuminating the event you saw fly by earlier. It's so nice. Especially if you're used to tools like GDB TUI, which permits scroll-wheeling down the assembly display, but it won't let you scroll-wheel back up to the thing you were just looking at!
- britneybitch 4y agoOops, maybe not that high-level. I meant, underneath the UI layer, how is the state/execution path of the emulated CPU efficiently recorded during execution and later rewound? Any approaches I can think of would destroy the performance. I have a toy emulator project that dumps the entirety of RAM every frame and I'm trying to come up with ideas to improve its efficiency.
- jart 4y agoBlink's reverse debugging is implemented purely at the user-interface level. It doesn't have anything to do with the execution engine. While Blink does have near-perfect knowledge of memory, I considered doing the thing you proposed, where deltas are stored and reconstructed. I decided that it wouldn't offer compelling benefits beyond just capturing and rewinding screenshots. For Blink's use case, screenshots are arguably superior, since it preserves perfectly the UI states previously observed by the user. I understand this might not be an option for your project, since you might not have a display that's visualizing program memory and execution. In that case, I'd suggest why not build that first?
- Maursault 4y ago> Blink is at least 2 times faster than QEMU > Blink is now outperforming Qemu by 13% when emulating GCC. Nice work. But isn't QEMU notoriously slow?
- bonzini 4y agoIt's faster than you think. :)
- KingLancelot 4y ago[dead]
- Sophistifunk 4y agoWhere is it? I do not have a twitter account.
- xcdzvyn 4y agoHi jart! You're an inspiration! That's all :)
- smith7018 4y agoIncredible work, jart! Have you tested if it can run on Asahi Linux (Linux for ARM Macs)?
- musicale 4y agoSelf-hosting is certainly a thing if the emulator can run on the emulated platform. Same for VMMs that can run on a virtualized platform. It's a nice test also and can be useful for debugging.