Hacker News Reader

Comment by m0zg | Hacker News Reader

So what's gonna happen to MLIR and TensorFlow Swift now? Dead?

I wouldn't be worried for MLIR.

MLIR is getting used internally more and more inside TensorFlow, but also by separate team in different projects, like IREE for example (https://github.com/google/iree ). The TensorFlow lite converter has been replaced by the new MLIR-based one, similarly for the Edge TPU.

But more than that, what makes me confident is the traction we are getting outside Google. First, we landed MLIR in LLVM last month: https://github.com/llvm/llvm-project/commit/0f0d0ed1c78f1a80...

The LLVM Fortran frontend (f18/flang) which will merge soon in the LLVM monorepo is using MLIR for their own IR. It'll be exiting to develop a non-ML MLIR-based frontend within LLVM! In particular Flang is opening an HPC perspective that could be leveraged by other DSLs later. They are adding an OpenMP dialect to MLIR right now: https://llvm.discourse.group/t/rfc-openmp-dialect-in-mlir/39...

Intel has been actively porting their nGraph/PlaidML framework to be based on MLIR (search for "The Stripe dialect" and "nGraph Dialect" here: https://mlir.llvm.org/talks/ ).

I'm less familiar with S4TF, but I know they recently got some nice new hires, including https://twitter.com/DaveAbrahams/status/1207690883782467584

Edge TPU will eventually be canceled as well, I'm pretty sure, which is why, as exciting as it is otherwise, I'm not using it for anything practical. There's just no way to make $1B/yr with it, so it's officially below Google's executive interest threshold.

Chris Lattner actually gave a talk at the last MLIR open design meeting. This may or may not ease worrying about MLIR's future.

"2020-01-24: Thoughts on Tensor Code Generation in MLIR" here: https://mlir.llvm.org/talks/ for reference.

By far the #1 committer and founding engineer of Swift for Tensorflow also recently left the project: http://rxwei.me/about/ . From the committer list, it looks like Dan Zheng is the only individual who is actively working on it, and he's was an intern until he formally started January 2019. I don't know the ins and outs of Google culture, but it looks at least like every senior engineer has moved onto something else.

Doesn't mean Swift for Tensorflow is dead. Could mean Swift for Tensorflow will properly support Metal soon :-D

There are medium sized teams at Google for each of MLIR and s4tf. There's a weekly open design meeting for each of them. Many different folks have presented their work at both meetings.

Yea but they cancelled this week's meeting, and I guess this is why

Not clear with MLIR, since it seems to have some traction beyond S4TF.

But yes, I think S4TF has had zero interest among people actually doing ML and is probably dead. It might take Google a while to actually kill it off, though.

From conversations I’ve had with people doing ML, if they know about S4TF at all they actively dislike certain aspects (for example that it’s based on a statically typed language), or are dismissive of others (like support for differentiation, which is a neat parlor trick but saves a tiny bit of effort).

Not "zero" IMO. I, for one, was excited about its potential, I was just waiting for it to mature (wisely in retrospect). Python is really bursting at the seams for ML/DL at this point and the ecosystem is in need of a proper compiled language for implementing deep learning systems. This language must be easier on the newcomers than C++.

Imagine a future where you could tell if your shit's broken by recompiling it, and your "deployment" would be just putting some RPC in front of your existing code.

Most people I know that understand s4tf well (including me) are excited about it. Chris Lattner and I co-taught two video lessons on it - have a look at those and see what you think: https://course.fast.ai/videos/?lesson=13 .

I think you might have misread. I'm excited about it, it just wasn't mature enough for anything client-facing for me.

I didn't misread - I was agreeing with you! :) And disagreeing with the person you were responding to.

Would you be open to doing a Fast.ai initiative in Julia? If so, what would that take?

I would be delighted. I've even spoken to the Julia core team about it. Hopefully one day they'll make that happen! (Just like we developed SwiftAI thanks to support from Chris Lattner and the s4tf team).

How can I try those lessons on Windows?

Probably easiest is to use Colab, which supports Swift directly. Otherwise, use one of the approaches shown on the course site: https://course.fast.ai/

(Most data scientists on Windows, including me, use SSH to connect to a GPU server running Linux for training models.)

So not an option against the competition that has no issues supporting Windows as first class citizen.

Windows needs to die though. The sooner it dies, the sooner we can all just assume that everything has bash and a bunch of excellent compilers installed.

There plenty of OS that aren't POSIX clones, Windows is not alone.

Anyone that cares about bash on Windows can install mingw or WSL, preferably WSL2.

Tablets don't have CLIs by default.

Even if UNIX clones ruled the world, chsh is a thing.

Hey Jeremy, I'm a really big fan. I got really interested in Swift based on your initial blogpost on it, and managed to get the company I work at to invest a bit in researching how suitable it could be for real time ML on video.

If it's not too forward, do you know at the moment if FastAI will continue to invest in Swift? I know development was a bit stalled due to the work needed for FastAI 2.0, but I was wandering if it'll resume, or if Richard Wei and Chris Lattner leaving changes anything?

Cheers and thanks for FastAI!

PD: Was working a bit on SwiftCV, added the videoio and highgui modules. Was wondering if I should PR it to fastai's or vvmnnnkv's version of the repo?

I was also pretty excited when I heard that they were baking autodiff into the language but unfortunately Swift has very little traction outside of mobile development, which makes it a hard sell.

I think a compiled subset of python is the best way to make that happen. All of the JITs (Numba, PyTorch, Jax, etc) already handle a decent portion of the language, so it should be doable.

No compile time type / function signature checking - no deal.

That language is Julia, plus there are ongoing integrations with Java, .NET, Go, Rust, Haskell, OCaml.

All of them much more mature than Swift, outside Apple's eco-system, including being able to target CUDA.

Also C++17/C++20 isn't that bad.

I learned C++ARM at the age of 16, and many Portuguese universities teach it at first year students, surely newcomers can grok it.

C++ isn't that bad if you already know it. I agree. I enjoy programming in C++ myself. For anyone just starting out, it's pretty horrifying, which is why there aren't a lot of experienced C++ programmers around. Its worst trait is that it encourages excessive cleverness, and left unchecked that can very quickly make any code impossible to understand.

Also Portuguese universities seem to be out of sync with the rest of the world if they teach C++. In the US most people with a CS degree haven't been exposed to C++. It's either Java or something functional. C++ typically doesn't even come up. Which is pretty puzzling to me, because most of the programs I use daily (including this very browser) are C++ programs.

Portuguese universities aren't the only ones, I am pretty sure many of the other European ones do the same.

Also, I actually learned C++ during high school, back when C++ARM was the only "standard", and most C compilers still did a mix of K&R and C89.

Nowadays many high schools do stuff with Raspeberry PI and Arduinos (Processing is just C++).

And you have books like these available https://www.amazon.de/f%C3%BCr-Kids-Grundlagen-Spieleprogram...

My guess is that Swift+Tensorflow on hold.

Last I checked, Swift is still years away from 1st class Windows support and adequate tooling. Without those in place, Swift+Tensorflow is still a very niche product for Google and I cannot think of a good enough reason why they should heavily invest into it.

Why would windows matter so much for tensorflow? Isn’t most ML work these days done under Linux?

Because that is what we get on our desks, managed by IT.

Python Tensorflow, Julia, ML.NET, Tensorflow for C++, Pytorch, DL4J do all pretty well on Windows.

A lot of work from researchers are using *conda on Windows. ML research is happening across all fields, not just computer science.

Wild speculation, but my guess is that both will continue to be developed.

As far as I understand, the MLIR project predates its machine learning application and was originally intended as a new IR for clang. In that capacity it makes a lot of sense. MLIR is also currently experimental in Tensorflow, although I have no idea how mature the implementation is.

Similarly, there has been significant investment into Swift for Tensorflow, so it's probably here to stay. On the other hand, from a language design perspective Swift is not a particularly good choice for automatic differentiation and translation into Tensorflow graphs (imperative, exposing many details of the underlying machine, etc.). Without a lot of investment into this project it might just be overtaken by a better engineered competitor, or more likely, fail to gain sufficient mind-share over the "good enough" python solution that already exists.

https://twitter.com/JeffDean/status/1222033368700706816

Depends on the community, more and more communities are proving to be more reliable when it comes to core tech pieces.

I just saw the last commit is from Eugene Burmako, who has previously done awesome work with Scala compiler. I think the project is in good hands.

Reply on news.ycombinator.com