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

https://cloud.google.com/blog/products/bigquery/inside-capac...

Search for the section with

"Capacitor builds an approximation model that takes into account all relevant factors and comes up with a reasonable solution."

or a more detailed dive in the paper (by the favourite author of performance engineers, Daniel Lemire)

https://arxiv.org/abs/1207.2189

Duckdb might not be the reason, the real reason might be AWS.

It's been two years since I worked on this, but AWS Nitro might be triggering a high CPU Steal % when all the cores are busy at the same time.

You can do taskset -c 1-191 and get a tiny bit of breathing room there.

I almost always do this above 32 cores, since this lets me always have a nice responsive ssh connection when the rest of the CPUs are churning high.

The more cores you have, the less of a problem sparing 1 core becomes.

This is somewhat unavoidable if you have a number of files and a tight filter which rejects most of them. The footer choice was a bad one in hindsight (not for HDFS), but for anything which uses XOR or other kind of erasure coding. The other other file format I worked with used headers only instead of footers, to save a few ms in latency for the initial GET

I don't think Ducklake can maintain a zone-map or ART index over parquet files, but there is no equivalent of iceberg metadata/something which has min/max/HLL compacted across multiple files yet.

The secondary indexes with file identifiers stored in a sequential file is most likely the next useful thing duckdb can make.

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.

[1] - https://dl.acm.org/doi/10.14778/2733004.2733064

Async io generally causes a CPU bump as a side-effect, when the bottleneck moves from the disk to the CPU (more usually memory bandwidth).

My experience is from a different SQL engine, but the improvement in scan rates directly translates all other operators getting more work to do per unit time.

More CPUs pegged at 100% is always a good sign of smooth flows, but optimizing further requires data layout changes from that point. Even if it is a sub-linear speedup out of concurrency scaling - more with more is still a win, assuming you can pay for more (the Dy-skew paper has an example I can quote).

Buried in the pdf in different sections

> Managers attend meetings far more frequently and spend substantially more time in them than non-managerial employees.

> Separately, interactions with senior colleagues are associated with stronger wage growth

A meeting is called to coordinate or communicate. Wadge's law of meetings tell you which one is which.

But not all coordination is top down, sometimes you need your manager to go negotiate a point with another division.

And neither is all communication, most often you can impress on others the potential of a new approach or the problems with the existing one.

The only trouble for the neurodivergent among us is that "appearing to pay attention" is also communication, same goes for eye-contact or not stuttering.

Corolllary is that skip meetings at your own risk, decisions will be made and you won't be in the room where it happens. And don't be the person who is not welcome in meetings, that too eventually makes your pay suffer.

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

[1] - https://dl.acm.org/doi/10.1145/504311.504291

This would turn an internal IPv4 into an externally routed IPv6, which is a neat trick which would replace all the NAT madness that we do run today.

I'd like nothing more than the ability to run ipv4 internally indefinitely, especially with things like mesh networks where the ACLs are carried over from ages ago (2018 doesn't feel that long ago, but it is).

Most of the time I don't even need a route to a direct connection, I just need legible flow logs out of a kubernetes platform.

The Lotus Elise was famously glued together instead of welds. The original Roadster also had the same innards.

This is clearly not a car for someone who wants to go from A to B, but a lot of Tesla components gets binned together for the next iteration of the cheaper car because they always order too many of them.

Oddly enough this makes their cheaper cars more reliable than the expensive ones (think about the Audis right when Ferdinand Piech took over Lamborgini).

> Imagine how they must feel about their work being deliberately copied wholesale and intentionally presented as someone else’s.

Nobody copies from a mid-tier product.

As someone who worked in open source till recently, I've seen a copycat as validation that my idea was better than what they could come up with on their own.

All those people now have evidence that their approach is the best for an AI native future.

The interesting point is that there is overlap in personnel, so this is less of copied homework, more that Anthropic hired some good people who knew a good solution that worked.

But from a pure AI lens, this is what we're doing - putting great ideas into one system and now everyone can drink from that well.

The bad part is that the well has a coin meter next to it, rather than it being a commons. So the fruits of that is not distributed to the people who planted those seeds. This is also happening too fast that the people whose work is getting redistributed to others are still not done being compensated for their work.

The real reason rewrites to fix tech debt used to fail was that it took too long to get to feature partity & the goal posts moved constantly while you were on the rewrite team.

The sunk cost of existing code is no longer considered in a rewrite.

Maybe it was hard to write in the first place, but it is not hard to rewrite anymore, as long you've got decent tests.

Comments URL: https://news.ycombinator.com/item?id=50106703

Points: 6

# Comments: 0

My team hasn't finished writing their blog posts yet, but the customer demos [2] went out the moment TypeSafe took our call and sorted all the paperwork out.

There's a tiny section at the bottom of the demo which explains how it actually works (or the github repo is the code).

We have a single decision API[1] over all similar models, so we run evals across all the "System One" api products & definitely don't trust any benchmark that you haven't run. All standardized benchmarks have been benchmaxxed already.

PS: just in case it wasn't clear, the demo is a game where we play to calibrate the human vs machine decision making (or just do it in auto-pilot mode).

[1] - https://github.com/prasanthj/duckdb-dual-cognition

[2] - https://demos.isotopes.ai/demo/apps/chain-command

The management decisions to scale up production take years to materialize on your food.

Even if you hate what you got out of a bottle you bought this week, that taste is not what made the sauce popular years ago. Popularity seems to cause a quality fade in everything that scales out of a single factory.

For example, the Sriracha from 7 years ago tasted totally different than today & it is the peppers that changed, not the recipe. Palo Alto fire fighters has gotten more cumin than chillis as the spicy stuff goes to the XX version. The Athabascan sauces I've loved from Alaska have slowly morphed sweeter and maple.

Tabasco for all its faults hasn't changed that much in the 20 years I've been having it.

{ "model": "strands-decider-2B-hobson-v19", "answers": { "is_urgent": { "type": "noul", "noul": 0.8287 } }, "usage": { "input_tokens": 86, "output_tokens": 1 }, "latency_ms": 1732.17 }

This is how I got it running - https://gist.github.com/2891eb0db9ea92c1a4e860d44f556292

There's a lot more to be done if we optimize for MLX & let it run on a Mac mini instead of the docker wrapper.

Competing models is table stakes for decision making.

While doing the ablations for the "Team of Rivals" paper, I found that the models were very happy to ignore errors[1] when the data it is classifying looks like its own output.

Jev slots into the middle critique in the paper. The only reason we haven't flipped to Jev last week is because we're a HIPAA shop and Typesafe hasn't responded to our emails.

[1] - https://github.com/t3rmin4t0r/critique-evals

> don't key on the ANN address. That is precisely the change turbopuffer v3 makes. As you can imagine, it is not a trivial change.

This is a direct parallel to how Postgres and Mysql built indexes.

Your design choice went from a Postgres design pattern to a Mysql one. The difference is the reindexing cost vs the lookup cost - Postgres optimized for lookup and Mysql does for indexing on writes. Or more accurately, Postgres was better with good schema design using joins & mysql was optimized for a bad design with less normalization where many indexes exist for the same table.

Postgres always points an index to a row-id within postgres which is an arbitrary value which changes on each update.

Mysql, always assuming the storage engine is pluggable, points to the primary index entry and adds an extra indirection to the lookup.

This means that you point the mysql index to a stable id, so unless you go update the primary key for a row, you won't have to update the indexes for all the attribute lookups you might have made to data.

I don't do databases any more that much, but the design for NIMBLE file format has a lot of quirks which are relevant to this specific idea (wide tables).

But the old Uber post about switching from Postgres to Mysql to prevent index amplification[1] is a direct mirror to this post.

[1] - https://www.uber.com/us/en/blog/postgres-to-mysql-migration/

This is good, but they're the slow mover due to this exact thing.

Google is getting punished for not letting the models enter an echo chamber and go faster than humanly possible.

[1] - https://news.ycombinator.com/item?id=6372466

Until I had tailscale serve generating valid certs, I had a good reason to use Cloudflare tunnels.

But in general I don't want to put everything on the internet side of things.

Mostly, I don't want something open, but more like a "share with" for people who are in the same office (virtually over tailnet, not physically on the same LAN).

This still works great for a demo instead of a product pitch, to send an link out to see something.

I'd still use a real host over a laptop for those.