fwsgonzo

I'm interested in hearing more

Just don't forget the versioning script needed on at least Linux. It's either that or build with the same older distro Godot uses, so you have a matching libstdc++ version. You can link with a newer stdlibc++ but you will need a linker versioning script that hides your impl from the dynamic linker so you don't get random ghosts in your machine.

> This makes me a very bad critic and reviewer of the code generated by the AI.

What is this argument? Because it's slower it's bad? It could have been done better? Ok. Then learn the language. Or pick a language you do know. Or the performance doesn't matter.

At the end of the day, people were shipping absolute garbage that made them east 50k a year on the side 15 years ago. I know this because ...

Bad arguments all around.

Reasonable, now we have to wait for the ban for under 18. And one hopeful day the complete ban and mass jailing of anyone who had anything to do with the big social media networks of today.

If our TVs are proxying requests on behalf of big tech, that's very disappointing. At the level of time to break them up and jail their execs.

This goes well with JD Vance wanting to end US Dollars reserve currency status. Truly the robber barons can't just leave a shell, it has to be graveyard dead too.

Hm that's strange. I have 300mbit here and the entire WASM blob is 30mb, it really should go through fast. It's hosted by Deno as a WebSocket proxy and file server.

I'm wondering if it's mostly the WASM setup itself (after transfer).

I'm looking for brutal feedback for my game that I'm working on.

I'm working on a cozy voxel game with RPG and platforming elements. Still early days, so I'm still figuring things out. Players play on their own private instances. The world is very malleable as player instances are based on a "master tape" world that I maintain. After creation that fork is the players own, and they do whatever they want.

You can play a browser build here: https://automatia.libriscv.no:3000/

If playing is not your jam, here's my latest post: https://libriscv.no/blog/next-of-kin (although it will not explain much about the game)

Yep, plain as day issues aren't being solved: Climate catastrophe, extreme concentration of wealth (with asset buying blowing up house prices), monopolies and oligopolies is now the standard/expectation for anything you are allowed to buy in your local foreign-owned chain store, social media and phone addiction impact on our kids, ourselves and other adults, and our parents, and now AI (faulty basic expertise turned commodity) as well as making many forms of artistry and jobs complete dead-ends.

The number one thing to learn from all of this is that governments aren't really hands-on-wheel and maybe never have been. It's interesting to watch an old video of a politician from eg. the 60s, 70s or 80s and compare to today, though. So, I could be wrong.

And "others" will be blamed, if history repeats.

Is this going to be a way to execute emscripted-built projects locally? Or is the target something else entirely, like WASM interacting with Java?

The loopholes are well known at this point. They keep renewing loans until they die, then it's tax-free after death. It's called Buy-Borrow-Die.

You either have to pause the caller or prevent the caller from trampling the memory while the callee is using it. If you look at previous work like VMRPC (https://ieeexplore.ieee.org/document/5542746/) they make the shared area read-only while the callee is using it.

In IPRE, I am pausing the caller while the remote call is on-going, which means "just having a shared block" is inferior to just sharing everything. It's just so much easier and nicer to be able to pass literally anything you want.

The caveat is that the callee has to wait, but I think the fact that the remote is now running in the SAME THREAD without any scheduling involved makes up for it. It's a true synchronous remote function call with some overhead.

Sorry about that, the conference was on Feb 2, and it's supposed to be out any day/week now. I don't have a date.

There is a blog-style writeup here: https://fwsgonzo.medium.com/an-update-on-tinykvm-7a38518e57e...

Not as rigorous as the paper, but the gist is there.

Best I can do is reply to an e-mail if someone asks for the paper, since it's not out yet. The e-mail ends with hotmail.

I actually just published a paper about something like this, which I implemented in both libriscv and TinyKVM called "Inter-Process Remote Execution (IPRE): Low-latency IPC/RPC using merged address spaces".

Here is the abstract: This paper introduces Inter-Process Remote Execution (IPRE), whose primary function is enabling gated persistence for per-request isolation architectures with microsecond-latency access to persistent services. IPRE eliminates scheduler dependency for descheduled processes by allowing a virtual machine to directly and safely call, execute functions in a remote virtual machines address space. Unlike prior approaches requiring hardware modifications (dIPC) or kernel changes (XPC), IPRE works with standard virtualization primitives, making it immediately deployable on commodity systems. We present two implementations: libriscv (12-14ns overhead, emulated execution) and TinyKVM (2-4us overhead, native execution). Both eliminate data serialization through address-space merging. Under realistic scheduler contention from schbench workloads (50-100% CPU utilization), IPRE maintains stable tail latency (p99<5us), while a state-of-the-art lock-free IPC framework shows 1,463× p99 degradation (4.1us to 6ms) when all CPU cores are saturated. IPRE thus enables architectural patterns (per-request isolation, fine-grained microservices) that incur millisecond-scale tail latency in busy multi-tenant systems using traditional IPC.

Bottom line: If you're doing synchronous calls to a remote party, IPRE wouldn't require any scheduler mediation. The same applies to your repo. Passing allocator-less structures to the remote is probably a landmine waiting to happen. If you structure both parties to use custom allocators, at least for the remote calls, you can track and even steal allocations (using a shared memory area). With IPRE there is extra risk of stale pointers because the remote part is removed from the callers memory after it completes. The paper will explain all the details, but for example since we control the VMM we can close the remote session if anything bad happens. (This paper is not out yet, but it should be very soon)

The best part about this kind of architecture, which you immediately mention, is the ability to completely avoid serialization. Passing a complex struct by reference and being able to use the data as-is is a big benefit. It breaks down when you try to do this with something like Deno, unfortunately. But you could do Deno <-> C++, for example.

For libriscv the implementation is simpler: Just loan remote-looking pages temporarily so that read/write/execute works, and then let exception-handling handle abnormal disconnection. With libriscv it's also possible for the host to take over the guests global heap allocator, which makes it possible to free something that was remotely allocated. You can divide the address space into the number of possible callers, and one or more remotes, then if you give the remote a std::string larger than SSO, the address will reveal the source and the source tracks its own allocations, so we know if something didn't go right. Note that this is only an interest for me, as even though (for example) libriscv is used in large codebases, the remote RPC feature is not used at all, and hasn't been attemped. It's a Cool Idea that kinda works out, but not ready for something high stakes.

desktop CPUs running inference on a single background thread would be the ideal case for what I'm considering.

How much work would it be to use the C++ ONNX run-time with this instead of Python? Is it a Claudeable amount of work?

The iOS version is Swift-based.

Gjerne det! Sitter her om dagen: https://discord.gg/4e3yd5ej

Same here, also on an island. We lost power for ~8 hours during a storm, however that is the longest I've ever experienced. I have this stone fireplace: https://www.norskkleber.no/ovner/marcello/ (Marcello 140), which kept my 75sqm living room heated through the whole thing.

Since that storm, we have decided to buy a second fireplace for upstairs with a cooking top.