101–110 of 148 posts
Earlier quoted context omitted.
> The thing I most want to use this (or some other WASM Linux engine) for is running a coding agent against a virtual operating system directly in my browser. That exists: https://github.com/container2wasm/container2wasm Unfortunately I found the performance to be enough of an issue that I did not look much further into it.
Did anyone expect anything different though, when running a full-blown OS in JavaScript?
Earlier quoted context omitted.
I ran two experiments: ~20x slower for a naive recursive Fibonacci implementation in Python (1300 ms for fib(30) in this VM vs 65ms on bare metal. For comparison, CPython directly compiled to WASM without VM overhead does it in 140ms.) ~2500x slower for 1024x1024 matrix multiplication with NumPy (0.25 GFLOPS in VM vs 575 GFLOPS on bare metal).
This is not correct. You are using WebVM here, not BrowserPod. WebVM is based on x86 emulation and JIT compilation, which at this time lowers vector instructions as scalar. This explains the slowdowns you observe. WebVM is still much faster than v86 in most cases. BrowserPod is based on a pure WebAssembly kernel and WebAssembly payload. Performance is close to native speed.
Out of interest I tried running my Primes benchmark [1] on both the x86_64 and x86 Alpine and the riscv64 Buildroot, both in Chrome on M1 Mac Mini. Both are 2nd run so that all needed code is already cached locally. x86_64: localhost:~# time gcc -O primes.c -o primes real 0m 3.18s user 0m 1.30s sys 0m 1.47s localhost:~# time ./primes Starting run 3713160 primes found in 456995 ms 245 bytes of code in countPrimes() re…
MIPS (the arch of which RISCV is mostly a copy) is even easier to emulate, unlike RV it does not scatter immediate bits al over the instruction word, making it easier for an emulator to get immediates. If you need emulated perf, MIPS is the easiest of all
http://blog.schmorp.de/2015-06-08-emulating-linux-mips-in-pe...
Earlier quoted context omitted.
This is not correct. You are using WebVM here, not BrowserPod. WebVM is based on x86 emulation and JIT compilation, which at this time lowers vector instructions as scalar. This explains the slowdowns you observe. WebVM is still much faster than v86 in most cases. BrowserPod is based on a pure WebAssembly kernel and WebAssembly payload. Performance is close to native speed.
I see. I thought they were the same and https://vitedemo.browserpod.io/ failed to load, so I was not able to test there.
Earlier quoted context omitted.
Nothing, but "there are already working options" does not necessarily mean we shouldn't try new (and sometimes weird) things
GP says "You don't want to just run that code in ... even a very well protected VM." Why?
I can launch this thing and start making arbitrary connections out to port 25 on the internet from some random IP? Hmm.
(For APX I have patches at https://lore.kernel.org/qemu-devel/20260301144218.458140-1-p... but I have never tested them on system emulation).
Earlier quoted context omitted.
I see. I thought they were the same and https://vitedemo.browserpod.io/ failed to load, so I was not able to test there.
Demo works as expected for me, please share information if possible or join our Discord for further help: https://discord.leaningtech.com
The performance is pretty amazing. fib(35) runs in 60ms, compared to 65ms in NodeJS on Desktop.
But I can't find a shell. Is there only support for NodeJS at the moment?
Earlier quoted context omitted.
You haven't been around here in the Blockchain/NFT/Smart Contract dark ages, have you?
TBH I’ve been here a while, never felt what the point with the above is but do feel LLM:s are a new valuable affordance in computer use. I mean I don’t have to remember the horrible git command line anymore which already improves my exprience as a dev 50%. It’s not all hype bs this time.
Every time I see a comment like this, I have to wonder what the heck other devs were doing. Don’t you know there were shell aliases, and snippet managers, and a ton of other tools already? I never had to commit special commands to memory, and I could always reference them faster than it takes to query any LLM.