Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSLinux Now Supports x86_64

bellard.org

Post reply on HN
Print view View original

111–120 of 148 posts

Re: JSLinux Now Supports x86_64

#111

Post by apignotti »

johndough wrote: post #109
apignotti wrote: post #104

Earlier quoted context omitted.

Demo works as expected for me, please share information if possible or join our Discord for further help: https://discord.leaningtech.com

I dug a bit deeper. The cause was that navigator.storage.getDirectory() is not available in Firefox private browsing mode. 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?

Only node is supported as of version 1.1, but the next version is fully focused on command line tooling (git, bash, ssh, grep, ...).

See the launch blog post for our full timeline: https://labs.leaningtech.com/blog/browserpod-10

Also, could I ask you to quickly edit your previous comment to clarify you were benchmarking against the older project?

Re: JSLinux Now Supports x86_64

#112

Post by saagarjha »

brucehoult wrote: post #69

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…

> If you're building code specifically to run in emulation, use RISC-V: builds faster, smaller code, runs faster.

I don't really think this bears out in practice. RISC-V is easy to emulate but this does not make it fast to emulate. Emulation performance is largely dominated by other factors where RISC-V does not uniquely dominate.

Re: JSLinux Now Supports x86_64

#113

Post by johndough »

apignotti wrote: post #111
johndough wrote: post #109

Earlier quoted context omitted.

I dug a bit deeper. The cause was that navigator.storage.getDirectory() is not available in Firefox private browsing mode. 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?

Only node is supported as of version 1.1, but the next version is fully focused on command line tooling (git, bash, ssh, grep, ...). See the launch blog post for our full timeline: https://labs.leaningtech.com/blog/browserpod-10 Also, could I ask you to quickly edit your previous comment to clarify you were benchmarking against the older project?

Unfortunately, that comment can not be edited anymore. Maybe @dang can change it or remove the comment chain. I am fine with both.

Re: JSLinux Now Supports x86_64

#114

Post by sylware »

I am almost sure it was done so carefully that you can extract it from the abominations which are the whatng cartel web engines with a direct to OS abstraction layer that with only some little amount of work.

Re: JSLinux Now Supports x86_64

#115

Post by dmitrygr »

brucehoult wrote: post #72
dmitrygr wrote: post #71

Earlier quoted context omitted.

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

That's a very small effect in the overall decoding of an instruction even in a pure interpretive emulator, and undetectable in a JIT. Also MIPS code is much larger.

Entirely disagreed. In a simple step by step emulator it can be as much as 30% of the time spent. In a jit indeed it is less of an effect.

Re: JSLinux Now Supports x86_64

#116

Post by lxgr »

saagarjha wrote: post #112
brucehoult wrote: post #69

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…

> If you're building code specifically to run in emulation, use RISC-V: builds faster, smaller code, runs faster. I don't really think this bears out in practice. RISC-V is easy to emulate but this does not make it fast to emulate. Emulation performance is largely dominated by other factors where RISC-V does not uniquely dominate.

Do you have an explanation for GP's benchmark results then?

Re: JSLinux Now Supports x86_64

#117

Post by thesz »

brucehoult wrote: post #72
dmitrygr wrote: post #71

Earlier quoted context omitted.

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

That's a very small effect in the overall decoding of an instruction even in a pure interpretive emulator, and undetectable in a JIT. Also MIPS code is much larger.

MIPS code is not much larger.

There are two interesting differences of ISA between MIPS and RISC-V: that MIPS does not have branch on condition, only on zero/non-zero and that MIPS has 16 bit immediates with appropriate sign extension (all zeroes for ORI, all ones for ANDI). The first difference makes MIPS programs about 10% larger and second difference makes MIPS programs smaller (RISC-V immediates are 11.5 bits due to mandatory sign extension, 13 bits are required to cover 95% of immediates in MIPS-like scheme), a percent or so, I think.

Re: JSLinux Now Supports x86_64

#118

Post by lxgr »

Is JSLinux still an interpreter, or does it JIT compile these days?

Or are modern JS JITs so good that this is no longer a relevant distinction, i.e. is the performance of a JITted x86 interpreter effectively equivalent to a JITting x86-to-Javascript translator where the result is then itself JIT interpreted?

Re: JSLinux Now Supports x86_64

#119

Post by simonw »

repstosb wrote: post #95
simonw wrote: post #19

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. Claude Code / Codex CLI / etc are all great because they know how to drive Bash and other Linux tools. The browser is probably the best sandbox we have. Being able to run an agent loop against a WebAssembly Linux would be a very cool trick. I had a play with v86…

> 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. Well, there it is, the dumbest thing I'll read on the internet all week. Most of the engineering in Linux revolves around efficiently managing hardware interfaces to build up higher-level primitives, upon which your browser builds even higher-level primitives,…

> Well, there it is, the dumbest thing I'll read on the internet all week.

Rude.

In case you're open to learning, here's why I think this is useful.

The big lesson we've learned from Claude Code, Codex CLI et al over the past twelve months is that the most useful tool you can provide to an LLM is Bash.

Last year there was enormous buzz around MCP - Model Context Protocol. The idea was to provide a standard for wiring tools into LLMs, then thousands of such tools could bloom.

Claude Code demonstrated that a single tool - Bash - is actually much more interesting than dozens of specialized tools.

Want to edit files without rewriting the whole thing every time? Tell the agent to use sed or perl -e or python -c.

Look at the whole Skills idea. The way Skills work is you tell the LLM "if you need to create an Excel spreadsheet, go read this markdown file first and it will tell you how to run some extra scripts for Excel generation in the same folder". Example here: https://github.com/anthropics/skills/tree/main/skills/xlsx

That only works if you have a filesystem and Bash style tools for navigating it and reading and executing the files.

This is why I want Linux in WebAssembly. I'd like to be able to build LLM systems that can edit files, execute skills and generally do useful things without needing an entire locked down VM in cloud hosting somewhere just to run that application.

Here's an alternative swipe at this problem: Vercel have been reimplementing Bash and dozens of other common Unix tools in TypeScript purely to have an environment agents know how to use: https://github.com/vercel-labs/just-bash

I'd rather run a 10MB WASM bundle with a full existing Linux build in then reimplement it all in TypeScript, personally.

Post reply on HN