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
> 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.
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.
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.
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