csjh

I found it to spiral into complete nonsense a few times when I tested it out, but it's possible that was a bug in the provider

It should be pretty mature outside of Wasi. To be fair, there's really nothing that's super mature in terms of Wasi support, except maybe Wasmtime

don’t look at the user that reposted the article

maybe it implies some amount of "live to work" etymologically, but the word "living" in that context specifically refers to living in the financial sense (the act of living wouldn't really make sense in that sentence)

you live to play video games and watch movies, but you make a living by working

Wasm is explicitly not designed for interpretation (https://arxiv.org/abs/2205.01183)

Optimizations like these are so cool. I love seeing higher level languages take advantage of their high level-ness

What do you mean outside of programmer control? What's stopping you from setting the stack size in the linker flags?

What’s the downside of SynthID?

Obligatory DuckDB solution:

> duckdb -s "COPY (SELECT url[20:] as url, date, count(*) as c FROM read_csv('data.csv', columns = { 'url': 'VARCHAR', 'date': 'DATE' }) GROUP BY url, date) TO 'output.json' (ARRAY)"

Takes about 8 seconds on my M1 Macbook. JSON not in the right format, but that wouldn't dominate the execution time.

You’re missing the fact that the compiler isn’t forced to fill every register in the first place. If it was less efficient to use more registers, the compiler simply wouldn’t use more registers.

The actual counter proof here would be that in either case, the temporaries have to end up on the stack at some point anyways, so you’d need to look at the total number of loads/stores in the proximity of the call site in general.

Started on a dependency-free (including manual object file creation, excluding manual linker) single-pass C compiler with a goal of it being self-hosting. Spawned after my previous project (single-pass Wasm JIT) started to plateau a bit and wanted to start something more "full-stack compiler"-y.

https://github.com/csjh/c-liva

Maybe, but from the author's description, it seems like the interpretation of intent that they want is to generally give the most information possible to the compiler, so it can do its thing. I don't see why the right high level language couldn't give the compiler plenty of leeway to optimize.

> High level languages lack something that low level languages have in great adundance - intent.

Is this line really true? I feel like expressing intent isn't really a factor in the high level / low level spectrum. If anything, more ways of expressing intent in more detail should contribute towards them being higher level.

Appreciated, but not sure I'm ready for that yet - still need to finish uni :p

Been working on a single-pass WebAssembly JIT compiler (atm only guaranteed to work on M1 air), been super interesting learning and thinking through strategies to balance fast compilation & fast generated code. It's the fastest single-pass JIT output-wise that I'm aware of, but the compilation speed could use some work.

Also: the README is pretty outdated, the real interesting stuff happens in https://github.com/csjh/mitey-jit/blob/main/backend/arm64/ba...

https://github.com/csjh/mitey-jit

for the average developer I think the killer feature is allowing you to query over whatever data you want (csv, json, parquet, even gsheets) as equals, directly from their file form - can even join across them

distributing the dispatch instructions lets the predictor pick up on specific patterns within the bytecode - for example, comparison instructions are probably followed by a conditional branch instruction

How's it nondeterministic?

That's not true, plenty of great stuff is shipping every year. Take your pick: https://web.dev/series/baseline-newly-available https://web.dev/blog/baseline2023

Been interested in programming language implementations recently, so I'm working on an in-place WebAssembly interpreter

Currently passes all the WebAssembly 1.0 test suite minus the tests that require imports (around 9) - should have those ones fixed this week

https://github.com/csjh/wasm-interpreter

I think the most surprising part here is the gzipped-base64'd-compressed data almost entirely removes the base64 overhead.

I'm working on a serialization format, somewhat based on apache arrow but row-based. Includes end to end typescript type safety, and significantly faster than JSON in serialization and deserialization. Seems to do fairly well in the native version I threw together, but more of a javascript/typescript operation for now.

https://github.com/csjh/pest

It's in test262, so it basically has to be supported for the project to accomplish its goals.

My heuristic (especially for bigger, better indexed websites) is whenever archive.org first saw it

No need to remember crazy charts to determine equality in Javascript, just blanketly use `===`

stringzilla[1] has 10x perf on some string operations - maybe they don't suck, but there's definitely room for improvement

[1] - https://github.com/ashvardanian/StringZilla?tab=readme-ov-fi...

Futamura projections are super cool, reminds me of another post recently https://news.ycombinator.com/item?id=40406194

That’s a pretty standard feature nowadays

Mainly security related guarantees, plus it can run effectively anywhere with the same guarantees in all those environments

I wouldn't say that's the whole point of Wasm. Speed & efficiency are also key goals, which are what AssemblyScript play into, giving access to that speed potential in a format that's easy for web devs