Programmer interested in performance, new pieces of metal, compilers for them.
Twitter: bztree
Email: krassovskysasha@gmail.com
Blog: https://save-buffer.github.io/
Unfortunately this is standard for TUM's database group. Their previous database, HyPer was similarly cutting-edge, but was closed source under a proprietary license. Last I heard it got sold to Tableau.
Last I heard, the Sokoban game has a ridiculous number of puzzles on it. Can't find a source but I seem to recall hearing that it would take 400+ hours to finish it all. So.. I don't think it's entirely unreasonable it's been taking this long.
Neon engineer here. We implemented our own local cache between the pageserver and Postgres (called LFC). It compensates for the lack of a normal file system cache, and scales up with the rest of the autoscaling infrastructure.
Sure! Each instance of Postgres runs inside a qemu VM, inside a kubernetes pod. The VM provides isolation, autoscaling, metrics, and (eventually) live migrations. These VMs share AWS Metal nodes.
This is achieved through our Pageserver. The pageserver ingests streams of WAL, and so contains both snapshots and deltas. This lets us efficiently seek to any LSN by replaying page deltas on top of the nearest snapshot (we call it the GetPage@LSN API).
I've been exactly thinking about it this way for a long time. Actually once we're able to push computation down into our disk drives, I wouldn't be surprised if these "Disk Shaders" will be written in eBPF.
A famous Super Smash Bros player, when asked for advice, would always respond with "Don't get hit". Seems this principle of not blundering has wide-reaching applications!
My general take is that while the idea of composability is good, the implementations of these things are just frankly not of high quality. Velox/Acero in particular are all plagued by what I've come to call "Java syndrome", where everything is written as idiomatic Java but with C++ syntax. Virtual methods, std::shared_ptr galore (in lieu of garbage collection), random heap allocations, etc. As a result these systems tend to be bloated and significantly slower than they need to be.
DuckDB is good though, and I predict its quality of implementation will keep "monolithic databases" relevant for a while longer.
Yes this has been an up-and-coming theme in the data science world. Arrow for the data format, Ibis for the API, Acero/Velox/DataFusion/DuckDB/Polars for execution, Substrait for the query plan representation, etc.
The difference is that if a European social media company wanted to operate in the US, it's welcome to. With China it's a different story - they can operate in our market but we can't operate in theirs.
I'm almost certain this will be slower than OpenMP because it uses a centralized task queue that gets locked. OpenMP uses a decentralized work-stealing task queue called the Chase-Lev Deque. There's a C implementation in this paper:
+1 for Denis! The book does a great job explaining both “what does it mean for a program to be optimal?” And “what do I type into my terminal to check the performance?”
Of course, it doesn’t cover every possible performance trick. For that, I’d also recommend the Intel Optimization Manual and Johnny’s Software Lab.
It sounds like your distinction of tabulation vs memoization is similar to the concept of bottom-up vs top-down DP. Bottom-up: build the table up eagerly, top-down: recurse down and fill in the table lazily.
It's used a lot in databases for query processing. Specifically, if you're performing a hash join, probing the hash table is more expensive than probing the Bloom filter. If you are pretty sure you're not going to find very many matches in the hash table (i.e. the join is very selective), you can skip going into the hash table by first checking the Bloom filter.
There's a lot of optimizations you can do on top of the classic Bloom filter. In short, you can use a single hash to compute an offset into a table of bit patterns. SIMD lets you perform multiple lookups in parallel. I wrote a blog post about more advanced Bloom filters if you're curious:
Yep, I've heard that actually something like 80% of the energy of the CPU is used by the front-end! Beyond decoding, you also have all the energy spent on scoreboarding data dependencies and reordering the instructions and scheduling to execution ports. If you can do that 8x less as in the case for SIMD, that's a huge win!
I was hoping for a more thorough survey of the compilers and their history. Notably missing is any mention of Intel’s compiler, the Cray compiler, or the competition between Borland and Watcom C compilers. There was a big span of time when GCC wasn’t the only game in town! And also no mention of the more fringe compilers like TCC or the newer cproc. I understand it was meant to be brief, but this felt a bit too brief for my taste.
As far as I'm aware pg_vector just uses the compiler's autovectorization on float32. I think specifically for Euclidean distance you won't really beat GCC (the README even admits it: "GCC handles single-precision float but might not be the best choice for int8 and _Float16 arrays, which has been part of the C language since 2011.")
How come not all benchmarks appear on all languages? For example, Zig's bar appears to be lower than C's by virtue of sudoku and bedconv being missing.
I think parent comment meant that progress has accelerated to such a degree that the same amount of innovation will have happened between now and 2029 as happened between 2003 and now.
> A slower card with double today's RAM would absolutely sell
Absolutely, SQL analytics people (like me) have been itching for a viable GPU for analytics for years now. The price/performance just isn't there yet because there's such a bias towards high compute and low memory.
I resonate hard with this, and I'm glad it's being flagged as a trend. I didn't quite realize how soul-crushing ads were until I got rid of them. Now I'm on YouTube Premium and Twitch Turbo and look forward to getting rid of more ads.
I was just thinking that while browsing the language docs. Something like "This is my programming language. There are many like it, but this one is mine".
I've actually been thinking along similar lines lately but for a different problem: I see a lot of people using the "pimpl" pattern - having an interface heap-allocate an object for you to hide implementation details. With this destination-passing style you could get rid of the heap allocation and potentially have the "impl" object live on the caller's stack.