Do you want to work on PyTorch? The PyTorch team at Facebook is hiring! Remote in many locations is OK and most things we do are open source. Reach out to me in DMs if you're interested.
๐จ๐จ๐จ HEY EVERYONE I HAVE A PODCAST ABOUT PYTORCH INTERNALS DEVELOPMENT Two episodes public so far, three more recorded and unreleased. Also on Spotify, Apple and Google ๐จ๐จ๐จ
PyTorch Dev Podcast is coming back, first episode on Monday, with weekly release! I'll also be experimenting with screencasts (I've got one very boring one recorded, more planned); stay tuned on where to get them!
Great blog post by
@cwillycs
about contributing to PyTorch for the very first time. Best quote: โI donโt have a PhD in MLโฆ I canโt do this.โ Ssshh, of course you can.
As a staff engineer, you are expected to solve impactful problems that no one else can solve. For problems that can be solved via CODING, are you more likely to be breaking down a technical barrier or an organizational barrier? (Choices described more downthread.)
Automatic code formatting is how we have chosen to incrementally solve the problem of why can't we store source code in a more structured representation
Assuming I don't mess it up, I'll be streaming my undergrad NYU class on programming languages at The first class is mostly logics and then a trip through JavaScript history, as a way to frame many of the things that will be discussed in the class
The reason to use types is not that it will stop bugs from people who know what they are doing (though it very well may), but it will stop bugs from people who have no idea what they are doing (and are just trying to get the fucking thing to work)
Upon reflection, it is shocking that no one in my work sphere figured out how to do collaborative whiteboarding over the entire pandemic (this based on observation that no one is whiteboarding in any meeting I attended)
My read on Mojo is it's what you would do if Swift for Tensorflow failed and you were like "why did it fail" and concluded it's because no one likes Swift, so instead you do Python, and also MLIR is cool so backend to MLIR directly instead of TF
High abstraction often results in a loss of tactile feel for low level characteristics; e.g., GC ~> poor understanding of how much memory you're allocating; templates ~> poor understanding of how much code you're compiling. Can we restore feedback w/o losing abstraction?
One way to tell you're working with a really well written codebase: when things go wrong, you find there are well oiled diagnostic tools in just the right places to help you figure things out. Could be as simple as useful logging, or as complex as automated repro generation
Tomorrow at 3PM EST I will be livestreaming a deep dive of torchdynamo on my Twitch channel (roughly two hours before my regular PL class). We will try to understand enough to fix
I wonder if naively written Rust code can be slower than naively written code in compiled GC'ed language, simply because a garbage collector beats out clone()'ing everywhere just to shut up the borrow checker
I've always thought Skip was pretty cool and I have wondered how their incremental computation engine was implemented internally to get such good performance. Thread.
It is pretty frustrating that I am basically working on an optimizing compiler for a dependently typed language (PT2 + dynamic shapes + data dependent shapes) but it is so different from the literature that I don't know if any of it is relevant to our situation
You know how some PL courses organize themselves by making little languages and successively extending then? Should do the same thing but with emphasis on some ancillary feature X e.g., debugging, permitting BC breaking changes in the ecosystem, modularity, separate compilation..
python changed their tracebacks from reporting line number of the end of the statement to the beginning of statement and this broke my code and surely I live in the dumbest timeline
Which is more difficult: writing an ahead-of-time (symbolic) or runtime (eager) reverse mode automatic differentiation implementation? For the PyTorch team, you can observe that we struggled with AoT more. But it is difficult to suss out exactly why this is the case. ๐งต
Compiler Twitter: If We decided to make a formal semantics of PyTorch operators (add, conv, etc), what tool should we use to write it? Are we forced to build our own?
Every positive float8 E4M3 number. First row is subnormals, last row normally would be NaNs in IEEE but they robbed it for more dynamic range. No infinities.
So I took a stab at outlining like, the first two lectures of "how to design PLs with debuggers" at but really what I found out is I know nothing about debuggers and I'm hoping maybe someone else can run with this (cc
@cfbolz
)
Organizational barriers are code that, if you put a gun to someone's head, they could write it. But for some reason, they don't. Maybe it doesn't look good on perf, or it's really boring to do, or there's too much. See also the "bulldozer method":
There are a lot of problems that seem like way too much brute force work to be feasible, until you start the work and realize that the velocity increase you get from the practice of doing the work means that the problem is straightforward and feasible.
How does one become a floating point expert? E.g., how does one get to the point where you can decide whether or not to replace cos(x) with sqrt(1-sin(x)^2) and you know it will be profitable AND numerically stable?
Every year I forget why algebraic effects are algebraic and then I have to go reread Bauer's paper in the subject but this year it doesn't feel like it is sticking lol
I suppose the moral of the story is that it doesn't matter if your thing is better, if it's not staffed and people don't understand how to adapt it to solve new problems it will get replaced
@yminsky
Picked C++ because we could get static types, but it turns out writing an FP style compiler in C++ is awful (we ended up doing an LLVM style IR), the types aren't even that good so we ended up having to introduce dynamic types anyway for IR nodes
Fridge thought: programming languages that were designed to harness and contain an "army of junior engineers" will be the best languages for LLMs to code in