Neural accelerators are easy to use from Metal. They kick in automatically if you do a matmul using Metal Performance Primitives and you use bf16 or smaller (they don't seem to work in fp32).
Yeah I kind of think authors didn't conduct a thorough-enough literature review here. There are well-known relations between number of hash functions you use and the FPR, cache-blocking and register-blocking are classic techniques (Cache-, Hash-, and Space-Efficient Bloom Filters by Putze et. al), and there are even ways of generating patterns from only a single hash function that works well (shamelessly shilling my own blogpost on the topic: https://save-buffer.github.io/bloom_filter.html)
I also find the use of atomics to build the filter confusing here. If you're doing a join, you're presumably doing a batch of hashes, so it'd be much more efficient to partition your Bloom filter, lock the partitions, and do a bulk insertion.
Have you tried SolveSpace? It's easily my favorite open source CAD program. The main things it's missing are shells, fillets, and chamfers. But I've been able to 3D print quite a few parts using it!
Giving it a quick look, seems like they've addressed a lot of the shortcomings of Parquet which is very exciting. In no particular order:
- Parquet metadata is Thrift, but with comments saying "if this field exists, this other field must exist", and no code actually verifying the fact, so I'm pretty sure you could feed it bogus Thrift metadata and crash the reader.
- Parquet metadata must be parsed out, meaning you have to: allocate a buffer, read the metadata bytes, and then dynamically keep allocating a whole bunch of stuff as you parse the metadata bytes, since you don't know the size of the materialized metadata! Too many heap allocations! This file format's Flatbuffers approach seems to solve this as you can interpret Flatbuffer bytes directly.
- The encodings are much more powerful. I think a lot of people in the database community have been saying that we need composable/recursive lightweight encodings for a long time. BtrBlocks was the first such format that was open in my memory, and then FastLanes followed up. Both of these were much better than Parquet by itself, so I'm glad ideas from those two formats are being taken up.
- Parquet did the Dremel record-shredding thing which just made my brain explode and I'm glad they got rid of it. It seemed to needlessly complicate the format with no real benefit.
- Parquet datapages might contain different numbers of rows, so you have to scan the whole ColumnChunk to find the row you want. Here it seems like you can just jump to the DataPage (IOUnit) you want.
- They got rid of the heavyweight compression and just stuck with the Delta/Dictionary/RLE stuff. Heavyweight compression never did anything anyway, and was super annoying to implement, and basically required you to pull in 20 dependencies.
Overall great improvement, I'm looking forward to this taking over the data analytics space.
Typically requests are binned by context length so that they can be batched together. So you might have a 10k bin and a 50k bin and a 500k bin, and then you drop context past 500k. So the costs are fixed per-bin.
I intuitively think about linear regression as attaching a spring between every point and your regression line (and constraining the spring to be vertical). When the line settles, that's your regression! Also gives a physical intuition about what happens to the line when you add a point. Adding a point at the very end will "tilt" the line, while adding a point towards the middle of your distribution will shift it up or down.
A while ago I think I even proved to myself that this hypothetical mechanical system is mathematically equivalent to doing a linear regression, since the system naturally tries to minimize the potential energy.
Maybe I'm missing something, but why do people expect PoW to be effective against companies who's whole existence revolves around acquiring more compute?
I've been beating the drum about this to everyone who will listen lately, but I'll beat it here too! Why don't we use seL4 for everything? People are talking about moving to a smart grid, having IoT devices everywhere, putting chips inside of peoples' brains (!!!), cars connect to the internet, etc.
Anyway, it's insane that we have a mathematically-proven secure kernel, we should use it! Surely there's a startup in this somewhere..
> Sure, we don’t produce anything, but we have companies with high revenues and we can raise money based on those revenues. We’ll both be rich!
I think this is the central hole in the argument that the US is stagnant. The money that investors give you has to come from somewhere! Particularly in venture capital, you only get returns if you produce value.
Nevertheless, I do agree with a lot of the points here.
epoll is orthogonal to threads. It _can_ be used in a multithreaded program, but it doesn't have to be. It may very well be implemented in terms of kernel threads, but that's not what I'm talking about. I'm talking about user-space threads.
Conceptually yes, but I suspect there's going to be a lot hairier in practice. For instance, I think there's some stuff that needs language support such as thread-local storage. I'd guess it would be simpler to just re-implement threading from scratch using syscalls. But I also don't think the language provides any support for atomics, so you'd have to roll your own there.
Maybe I'm misunderstanding something, but it seems like ev is still multiprocessing? Reading the code, it looks like you can read/write to files, and if you want to kick off some other work it spawns a process. I don't see any instance of threads there.
I was pretty excited about Hare until Devault said that Hare wouldn't be doing multithreading as he preferred multiprocessing. That was a pretty big dealbreaker for me. The rest of the language looks quite clean though!
Ah interesting! I've definitely seen some French code somewhere with the variable names being all French as well, so it really was strange to see them be mixed.
From what I’ve seen, code usually comes in one of two languages: English or French. Somehow everyone but the French speaks enough English to write code!