The thing you actually need to look at here is the license. For swift (which is the main thing we use, via the tensorflow branch) the license is Apache, like fastai: https://github.com/apple/swift/blob/master/LICENSE.txt
This is a good license. It makes sure that you can use not only the code freely, but also any patents implemented in the code.
For Google/Apple to be apple to do this, they need a license to use any patents that you have implemented in your code. Hence the patent grant.
The CLA they ask you to sign assigns your copyright. This means that they may re-license the code later. However that does not remove the license that you already have. CLAs are common, and we used to use one ourselves, however after further research we decided they’re not actually necessary in our case. I’m guessing Google is just erring on the conservative side here.
However, @clattner@saeta one odd thing is the the s4tf repo has a CC license, not Apache: https://github.com/tensorflow/swift/blob/master/LICENSE.txt . This license is not generally used for code - it’s designed for prose/pics/etc. Can I suggest you chance this to an Apache license? Also, having it consistent will be easier for everybody, and having the patent issue addressed that way would be good too.
I agree with Jeremy’s summary of the license situation.
The idea of the tensorflow/swift repo was that it was supposed to hold docs, not code. However, workbooks are a fuzzy gray line (they are both dox and code), we should re-discuss this.
TVM is an end-to-end compiler stack for deep learning - it is specifically optimized for tensor operations used in deep learning. TVM uses a high-level intermediate representation (IR) to represent tensor operations.
MLIR is a meta compiler IR that can represent multiple other IRs, including TVM’s IR, as well as LLVM IR and TensorFlow graphs. A goal of MLIR is to unify different compilers to solve multiple requirements in a single framework. Many languages could use MLIR by generating MLIR IR (in a similar way to how languages use LLVM).
It seems to be an important question to ask here about the licensing and usage of MLIR? Since all the swift code may be pretty much dependant on it in the future.
LLVM had to go through a few years of licence uncertainty, so would be good to understand this upfront for MLIR
If I am not mistaken, Python is built on top of standard TF C++ runtime as well. Does it mean that Python will also receive a boost in performance after the release of new TF runtime?
I am new to this, sorry if my question is not related!
ok, then I am getting confused maybe So might python tensorflow eventually have the same performance like swift? And then using swift for tensorflow is more about having a state of art the art programming language, not performance (because that comes for python TF too). Having a great programming language is definitely reason enough to switch imho, just trying to clarify this for myself
This is somewhat true, but python isn’t at all suited to the kinds of optimizations we’re discussing, so I can’t imagine python getting close to the capabilities of swift when using mlir.
I have a few questions about how Fastai for Swift will look like for a Pytorch/fastai user like me:
Do I understand right that the plan is to have things run on Tensorflow in the backend; but in the front end we will have pretty much rewritten Pytorch and fastai in Swift?
So would that mean we will end up with a Pytorch-like workflow, which I prefer to Tensorflow’s workflow (e.g. dynamic graphs, more Pythonic code, more flexibility…)? Or will we have to deal with the Tensorflow way of things quite a bit more?
Swift for TensorFlow provides an eager programming model, similar to PyTorch! Just create tensors and write math:
var x = Tensor<Float>([[1, 2], [3, 4]])
for _ in 1...5 {
x += matmul(x, x)
print(x)
}
Usability is our first principle. You don’t have to think about TensorFlow graphs at all (in fact, graphs are not yet user-exposed).
Besides language differences between Swift and Python, one difference between Swift for TF and PyTorch is how differentiation APIs work. PyTorch has imperative differentiation APIs (e.g. y.backward(), optimizer.zero_grad()), while Swift is more functional.
Here’s a short demo showcasing a basic model:
// Custom differentiable type.
struct Model: Differentiable {
var w: Float
var b: Float
func applied(to input: Float) -> Float {
return w * input + b
}
}
// Differentiate using `Differentiable.gradient(at:in:)`.
let model = Model(w: 4.0, b: 3.0)
let (𝛁model, 𝛁input) = model.gradient(at: 2.0) { model, input in
model.applied(to: input)
}
print(𝛁model) // Model.AllDifferentiableVariables(w: 2.0, b: 1.0)
print(𝛁input) // 4.0
Differentiation in Swift is designed to be expressive and customizable: you can define custom types that work with differentiation (not just tensors), register custom derivatives, and define powerful APIs like gradient surgery and recomputation in just a few lines of code. If that sounds interesting to you, check out our custom differentiation tutorial and read our differentiation-related docs!
I have a rather different (and entirely unofficial - I’m not an official s4tf person) take on this…
s4tf does indeed provide an eager programming model at present, and it’s built on top to tf eager. But tf eager is 10x slower than pytorch currently to do an op, so in practice actually using it like pytorch doesn’t really work. And we don’t have the ability to construct more complex graphs ahead of time like traditional tf allows. So I don’t think we can yet claim that we have a practically useful eager programming model.
On the other hand, just matching pytorch’s capabilities wouldn’t be interesting. Partly, because we already have pytorch, so why would be bother just creating something similar in a new language. And partly because we know that pytorch isn’t sufficient for future needs (which is why, for instance, pytorch is moving towards torchscript/jit).
The plan is to have things run thru MLIR/LLVM/XLA in the backend, which will allow a much more “eager” model than even pytorch allows.
I would describe that as aspirational at this stage. In practice our attempts to do these things in the last few weeks have found many sharp edges.
I think the most profound statement in this lesson was the last. Where the compiler will learn the optimal structure for performing the desired computation on a given data set. It reminds me of Learned Index Structure work published by Google last year. Here is a reference for those interested in exploring what the future may entail
So might python tensorflow eventually have the same performance like swift? And then using swift for tensorflow is more about having a state of art the art programming language, not performance (because that comes for python TF too). Having a great programming language is definitely reason enough to switch imho, just trying to clarify this for myself 
