robertknight

This post is full of Claude's irritating verbal ticks ("It's not X, it's Y"). It is fine to use Claude (or another LLM) to help with this kind of reverse engineering, but I would prefer the write-up be done by hand.

This would have been more effective if written by hand. The issue content is typical LLM-generated markdown that has a lot of noise (formatting, headings, lists etc.) which makes it fatiguing to read. It comes across like a PowerPoint deck of dense slides. What is really needed is a clear, focused and well-written letter that effectively gets across a message and has the potential to be persuasive to the people within Microsoft who might be in a position to help. An additional problem with the LLM-written style is that it comes across as low-effort, which also lessens its impact.

The major constraint is that the compiler needs to guarantee that transformations produce semantically identical results to the unoptimized code, with the exception of undefined behavior or specific opt-outs (eg. `-ffast-math` rules).

An ML model can fit into existing compiler pipelines anywhere that heuristics are used though, as an alternative to PGO.

The custom scroll behavior on this page is infuriating and distracts from the content. It is like scrolling in treacle. If someone who works at Microsoft sees this and is able to file an issue, could you please do so.

I've seen talks on this topic at Rust conferences which seemed strongly influenced by Swift's approach, so that will probably be the direction this ends up going in.

Good post! The inefficient code for comparing pairs of 16-bit integers was an interesting find.

One interesting thing I discovered comparing various matrix multiplication implementations used in ML libraries is that several of them (ONNX Runtime, XNNPack, any others?) skip the step, from BLIS's textbook algorithm, of packing the LHS matrix. Instead they pack only the RHS. Since those are the weights, this can be done once ahead of time and then an inference pass does not need to do any packing at all.

From skimming various papers it seems like the motivation for packing the LHS originally, even though a single element is broadcast from it at a time (nb. this is opposite to the order in this post, where the row count in the microkernel is a multiple of the register size, rather than the column count), was to reduce TLB misses. Apparently this is not a problem in practice on modern CPUs and for problem sizes common in ML inference.

For context, ultralytics is the Python package for YOLO v8 and YOLO v11, two of the most widely used object detection models. The GitHub repo has 33K stars.

A couple of suggestions:

1. Try not to stress too much. The point of review is to improve the quality of the code that lands, and the health of the codebase as a whole, not to grade the author.

2. When you think your work is ready for an initial review, take a short break and then review it line by line yourself, looking for any obvious mistakes or possible simplifications. I recommend doing this in a different editor or view than the one you authored the code in originally.

When reviewing someone else's code, it is annoying if there are silly mistakes that the author could obviously have caught themselves. Issues where the author was not aware of a subtle detail or a coding practice in some other part of the code are less of an issue. Identifying these are exactly what reviews are for.

> This effectively means that if I were to bundle ffmpeg and ffprobe executables within my app, I would have to make the app open-source as well and provide it under the same license.

This is a misunderstanding of the LGPL license requirements, as they are usually interpreted. LGPL requires that if your application dynamically links to a modified version of the library, then you must make the source code _for the modified version of the library_ open source.

The original use case for the LGPL license was the C runtime, which practically every binary on a system will link to, proprietary or otherwise. The idea is that the binary can be closed source, but any modifications made to the C runtime itself must be distributed. The idea is that an end user could take your modified version of the C library and further customize it to their needs.

In the context of bundled ffmpeg and ffprobe executables, the user could replace them with their own versions. You should make clear which version of the source was used to build them and if you have made any modifications, those must be open source.

> All Maven/PIP/NodeJS/etc. dependencies are pulled through via proxy and scanned before first use.

What does the scanning process check for / which tools are used?