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.
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.
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).
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.
Think of WASM as a kinda universal library target. You can compile C, Rust, C#, Java to WASM, and then you can use it in a different language from the source. This way, Java can run C or Rust code without going through a FFI (foreign function interface). From the article, one example is porting tree-sitter (a C library) to Java by first compiling it to WASM, then use Endive to access its function.
Buy-Borrow-Die resets the basis for capital gains tax, but then there's estate tax when the money gets passed on (exemption is only $15 million, trivial to billionaires).
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.
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.
shouldn't be hard. what backend/hardware are you interested in running this with? i'll add an example for using C++ onnx model. btw check out roadmap, our inference engine will be out 1-2 weeks and it is expected to be faster than onnx.
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.
This is true. A multi-tier JIT-compiler requires writable execute memory and the ability to flush icache. Loading segments dynamically is nice and covers a lot of the ground, but it won't be a magic solution to dynamic languages like JavaScript. Modern WASM emulators already implement a full compiler, linker and JIT-compiler in one, almost starting to look like v8. I'm not sure if adding in-guest JIT support is going in the right direction.
