[erikgaas]

You can but it's not ideal. What if you want to write your own cuda kernel for your experiment? Python isn't really setup for this easily unless you want to throw odd c++ integrations into your code. Swift is designed to be a direct match to the underlying instructions. This would make deep learning much more expressive and flexible in Swift, with less errors.

This question is addressed extensively in the course. Check out the last two lectures, they do a great job of going over lots of different reasons.

[codesushi42]

That doesn't really make sense. The code you implement in Swift when in Jupyter needs to also be available at runtime to execute. Meaning you can do the exact same thing in Python, because your model architecture is going to be embedded in the exported model.

For custom kernel code, what you really want to use is a custom TF op. But I doubt that's what you're getting at anyway, because that's for more advanced use cases.

[jph00]

The goal is to allow Swift to be used for writing MLIR and XLA kernels. The new LazyTensor under development already allows for fused XLA operations to be created in Swift. There's an awful lot you can do in Swift which is very very hard to do properly in Python. I've got a bit more background on this here: https://www.fast.ai/2019/03/06/fastai-swift/

Edit: HN isn't letting me reply deeper, so I'll reply to "what are the benefits over C++?" here. The first is that MLIR has dialects that support stuff like polyhedral compilation, which result in much more concise and understandable code, which is often faster too. The second is that using the same language from top to bottom means you can profile/debug/etc your code in one place, which is much more efficient. And you don't have to learn two languages. And you don't have to use C++, which (for me at least) is a big win! ;)

[codesushi42]

MLIR is going to be orthogonal to C++ performance. You're talking about the efficiency of an intermediate representation. But that IR turns into TF opcodes, which then need to execute natively.

You can achieve the same efficiency in C++ via a custom TF op. You end up with native instructions either way. And you have access to the entire memmapped model in the op, allowing you to do as you please.

You're only debugging in one place, because the same C++ code runs during training in your notebook that runs during inference on your device.

You're getting ease of implementation and usage of Swift. But your code will be less portable; you won't be able to run the same model on Android or on the server. And there's not necessarily any performance benefit over doing the same in C++, definitely not if your kernel is simple.

[codesushi42]

Thanks. What is the advantage of using Swift over implementing a custom TF op in C++, and using its generated Python wrapper in Jupyter? Just not having to deal with C++?

[saynay]

Not needing to know both Python and C++.

If you need to debug something, you don't need to use some mixture of pdb and gdb.

Swift is a relatively young language, meaning it does not (yet) have weird hairy bits to work around design decisions made 20 years ago.

Similarly, Swift is still getting defined in many areas. There is (theoretically) the opportunity to influence language design decisions to patterns that mesh better with ML needs.

This is largely my paraphrasing of the reasons stated by Jeremy https://www.fast.ai/2019/03/06/fastai-swift/

[codesushi42]

Yes, but at the cost of portability. You won't be able to run the same model on Android for instance.

You're still debugging in two places; in Swift and Python. Debugging Swift is probably easier than C++ though.

I think using Swift is a valid solution for special cases, but not the best solution for most cases. The TF authors already provide a suitable, general solution in the form of custom TF ops.

And if you don't need a custom kernel, and the chances are you don't, then stick with pure Python for maximum ease of use and portability.