sakras

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.

I see you guys are using Egg/Egglog! I've been mildly interested in egraphs for quite a while, glad to see they're gaining traction!

Likely performance - LLVM is somewhat notorious for being slower than ideal.

Likely refers to Machine IR, a lower level representation that normal LLVM IR lowers to?

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?

New smart grids with new software do not require a rewrite!

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 threaded, not multiprocess

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!

> Tensor Evolution (TeV)

Oh no, I'm never not going to read this as "tera-electron Volts". I wish they picked a different acronym!

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!

> A statement like this pretty much disqualifies your opinions

This is needlessly aggressive. I specialize in writing SIMD code. That is my job. I am very eager to get my hands on a RVV chip so that I can play with a new SIMD ISA. So obviously a non-SIMD chip is useless to me.

> Why would you expect it to have vector extensions?

Because it has "Performance" in the name. I double-checked the ISA and saw that it did not have V, and was disappointed.

> If you don't need RISC-V this year then

Why would anybody _need_ RISC-V? RISC-V is exciting because it has the possibility of giving the end user higher performance per dollar. Until it does that, it will relegated to enthusiasts who just like playing with new ISAs.

Oh that's exciting, I will be on the lookout for that!

I was going to buy one of these until I realized it didn't have vector extensions. I expected something with "Performance" and "Premier" in the name to have them. I think some sort of SIMD capability is table stakes for a lot of workloads these days, so I'm disappointed that there doesn't seem to be a CPU on the market that supports them. I've heard that the vector extensions being stateful makes them particularly hard to implement, which makes me wonder if there needs to be some sort of simpler-to-implement version which mirrors more traditional SIMDs like AVX2 and Neon.

Maybe I missed it, but are there any performance numbers? It being 100% implemented in Python makes me very suspicious that this won’t scale to any kind of large robot.

Just as a data point, I'd recommend going through it in Racket, which I believe has an explicit SICP mode. I went through it in GNU Guile and it was a pain because there were some minor syntactic differences between Guile and MIT Scheme.

This has definitely been an issue for me before, I think at least for a while Ubuntu/Debian didn't ship gdb with tui enabled, you had to build it yourself.

Yep it just uses Jax to do the inference, no tensorflow needed.

Indeed it's a woodworking technique called Sashimono which doesn't use any glue or screws, just precise cuts to join wood together.

I spent a long time trying to do some sort of machine learning over the OpenBCI helmet's data with the eventual goal of moving a cursor, but I didn't seem to get anywhere. The data was indeed _extremely_ noisy, and I don't believe my model ever converged to anything useful.

That said, I was just a high schooler and so my method of collecting training data was to run the script and "think really hard about moving left". Probably could have been a good deal more sophisticated too.

> Though APL may strike some as a strange language of choice for deep learning

I've actually spent the better part of last year wondering why we _haven't_ been using APL for deep learning. And actually I've been wondering why we don't just use APL for everything that operates over arrays, like data lakes and such.

Honestly, APL is probably a good fit for compilers. I seem to remember a guy who had some tree-wrangling APL scheme, and could execute his compiler on a GPU. But I can't find it now.