> You could make the argument that this well-understood process could be broken out into its own class/package/module and tested with its own public interface, but if there really is only one consumer then that's kind of a strange trade-off to make in many cases.
That's how I develop in general: a "component" does not exist because it has multiple-clients, but because it is a conceptual piece of logic that makes sense to document and test in isolation. It allows to define what is the public API of this component and what isn't. This is how software scales and stays maintainable over time IMO.
There is something to be said about individual productivity (whatever that means in a very innovative/creative environment) vs team/company output, just today I saw this in my feed: https://flocrivello.com/changing-my-mind-on-remote-about-bei...
And that's coming from someone who actually tried to build a business out of remote work (TeamFlow was the product).
I can be much more productive at home when it is about my individual contribution (me coding to deliver something unambiguous), but xxx individuals doing this does not necessarily align into a great product: that does not scale.
They claim they are writing the actual kernel code (as in the implementation of a matmul) with it, and it was presented as a "system programming language": this goes far beyond "high-level tasks" it seems.
It depends what you mean by "new subsystem" and "transitioning to": what seems like a given is that the notion of "one size fits all" of LLVM IR is behind us and the need to multi-level IR is embraced.
LLVM IR is evolving to accommodate this better, within reason (that is: it stay organized around a pretty well defined core instruction set and type system), and MLIR is just the fully extensible framework beyond this.
It is to be seen if anyone would have the appetite to port LLVM IR (and the LLVM framework) to be a dialect, I think there are challenges for this.
TensorFlow is also a runtime, yet we model its dataflow graph (the input to the runtime) as a dialect, same for ONNX. TensorRT isn't that different actually.
All of Google TPU is powered by the XLA compiler, so any MLPerf benchmark result from Google comes powered by XLA.
Anything JAX is also built on top of XLA, so you can take JAX performance as a point of comparison as well if you'd like.
The movement of paddling has a natural rotation of the shaft when you raised the fixed hand for a stroke on the other side, it's quite straightforward to figure out sitting and mimicing the movement.
During this movement if the blade aren't feathered at all you have to compensate with some bending of the wrist. The amount of rotation of the shaft induced depends on how much you raise the hand/elbow, and so is fairly dependent on your style of stroke. This is the main way I think should be approached feathering: how much vertical do you intend to paddle? From there the angle should follow to optimize for the least amount of wrist twisting.
In general paddling very vertical will come with more angle in between the blades. I practice slalom and use to have 70-80 degrees crossing, but I tend to paddle less vertically now (aging? Lack of training?) and I'm down to 60 degrees comfortably now.
In case you haven't tried it yet, Pythran is an interesting one to play with: https://pythran.readthedocs.io
Also, not compiling to C but to native code still would be Mojo: https://www.modular.com/max/mojo