gopalv

This is not a new problem, I've had this problem every summer when a new batch of interns show up.

As they say, if an intern can bring down production, it is not the intern's fault.

The interns are generally so much better than me at writing code, but they're not the best at "software development" (I call it "software gardening").

My training regime is to push them up the next 4 leadership levels from "writing code" - delegation, negotiation, vision and inspiration.

Agents are barely at delegation, with multi-agent harnesses.

They don't negotiate with you, they say yes.

Their vision is limited to the context you gave and most of their output is uninspiring (you can smell "Claude did this" on a UX design pattern easily).

But the humans, they've been thrust into delegation on day 1 & unless you've been a tech-lead manager, you probably haven't exercised that skill yet. Even if you have done that, the way agents work is not exactly how humans work [1] in terms of incentives or even try something they think won't work.

If you've been a good IC for years, the company could always afford to hire a human who specializes in those skills and suddenly you've been promoted to a new role without a pay bump or even a choice.

Most of the "Let's add agents and go faster" is basically adding more manpower to a project behind schedule and the payback is missing because that causes communication gaps & dropped messages.

The weird thing is to see this based off the KV-Cache in the diagrams.

Completely different from the Databricks RAFT [1].

My team built "Dreamtime" earlier this year [2], which used a different mechanism to distill out learnings across multiple sessions.

This didn't pull from the token layer, but from user nudges on unsatisfactory responses.

This works like a sawtooth wave where we accumulate context, check for dissonances (a user gets to say "It depends" and fix it), compress it back, retire the old one.

The audit requirements are the real problem for customers, where you need to be able to ask "When did this change? and who changed it?" which was hard to answer from the lowest layer of the model unless you can retain lineage to the original sessions.

A model we train can't serve as an accomplice to a user who wants to hide some financial crimes by nudging the agent repeatedly.

"A Little Bit of Slope Makes Up For a Lot of Y-Intercept"

I assume this intended at a class which has already finished writing an AOT compiler and wants to build faster functions than you can derive at a compile time.

> On the first call to a function, the compiler calls compile_me, which reconstructs argument types from their tag bits and builds a temporary type environment. The function body is then optimized using those concrete argument types.

It's been two decades since I have worked on Rhys's brilliant libjit and the work that came before it[1], but the first-call recompilation can mix well with a byte code interpreter as well.

You still need to be able to JIT a whole function with the first-call recompiler here, but you can do even more incremental if you are pairing it with an interpreter which gets to pick up the slack of the JIT.

For example, with an interpreter, I could JIT about ~15% of a function and incrementally implement one opcode at a time without handling the complex ones on day one.

The switch loop with direct threading can jump into a JIT block or the next instruction's compiled location, in identical fashion. So you get to operate register to register for adjacent instructions being JIT'ed together, but write back to heap for the interpreter to take over for an unsupported one.

This is referred to as unrolling in the impl there, because what it really does is partially unroll the for(op in ops) loop and skip the jump to the top when you see a sequence of ops which you can line up together and JIT once.

No, this is still parquet being loaded in.

The "trick" is running through sort order combinations which result in maximum packing in a Dremel style data format (like Parquet).

Here's the trick explained in enough detail to understand, but not enough to copy as-is

Transparent queries on server/browser in identical sql.

If you play all the tricks Google's Capacitor does to the data layout, you can shove ~2-3 million rows to a browser based query engine in 16-20Mb with duckdb-wasm. We can scale it up to ~1Gb with HTTP range queries, with cache-control.

Then we use Jev to write SQL queries over it in 1-2s, whenever someone has a followup question. Getting Jev to write SQL takes a bit of prep, but my co-founder wrote a paper about clairvoyant query execution a few years ago [1].

I could have 3000 users logged into the same application, but all of them would be bringing their own CPU to run duckdb. My compute scaling problems for my data cube is a solved problem with this approach.

Switch case is the workhorse of a lexer, parser and execution engine. Lots of them over enums.

This was all mis-optimized for years thanks to Spectre/Meltdown changing how the actual runtime of pre-fetch and speculation used to work.

All my work on CGOTO was made irrelevant by the CPU advances, only to become relevant again when fetch speculation got nerfed.

The indirect call scenario is a bit more interesting, because the JVM has an amazing paper about interface dispatch caches [1] on how to do it runtime instead of compile time.

The PGO is still useful, but not unless you can predict the workload you're going to have - Benchmarketing with a TPC benchmark is a good situation for it.

If you have consistent hardware, tuning an OLTP system for the hardware is much more interesting. Going back in the memory hole, Yahoo used to have a Jeremy Cole build of Mysql which was specially optimized for the raid disk layout that was in production (ZFS came by to fix those issues directly).