Introducing Swift for Tensorflow

DevAndArtist · April 23, 2018, 6:31am

I just was wondering, everything is cool. ;)

Chris_Lattner3 · April 26, 2018, 7:28pm

This is up now, docs and more info is here: GitHub - tensorflow/swift: Swift for TensorFlow

JetForMe · June 20, 2019, 9:41pm

I just watched the presentation from Mar 6, 2019, and am hoping this means our iOS project can use Swift for Tensorflow instead of the C++ Tensorflow we're currently using. I went to see what it takes to install it (e.g. is it available as a Framework for Xcode), and see that it requires special build tools.

Will (are) those new swiftc features be integrated into Xcode 11 or 12?

I ask because it seems the selected toolchain applies to the whole IDE, rather than, say a target within a project. We don't want to have to manually switch between toolchains to build our project.

firecrackerz · June 21, 2019, 1:35pm

i don't think this will heppen any time soon, even current state of swift is too too apple centric, there is no proper support for other platforms (other then darwin), swift is really good langauge but i think rust is properly executed (ie)
what we need here is swift foundation away from apple, clean implementation with all platforms supports and proper standard library

nuclearace · June 21, 2019, 1:58pm

If the differentiable programming features are upstreamed then yes, eventually those will be available in Xcode. TensorFlow the library probably will never be directly available in Xcode, and I can't speak as to whether it'll be made to work directly on iOS or not. My understanding is the current implementation still relies heavily on Python interop.

JetForMe · June 21, 2019, 4:32pm

No, no, I wouldn't expect the library to be in Xcode. I just don't want to have to switch between toolchains; that seems fraught with danger.

rxwei · June 21, 2019, 5:05pm

The implementation of the TensorFlow library does not rely on Python interop, except for a very very tiny part which provides convenience APIs for converting numpy arrays. It is guarded by #if camImport(Python).

github.com

tensorflow/swift-apis/blob/main/Sources/TensorFlow/Core/PythonConversion.swift

// Copyright 2019 The TensorFlow Authors. All Rights Reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

#if canImport(PythonKit)

  import PythonKit

  /// The `numpy` Python module.
  /// Note: Global variables are lazy, so the following declaration won't produce

This file has been truncated. show original

rxwei · June 21, 2019, 5:15pm

The TensorFlow library is a SwiftPM package. It depends almost exclusively on the differentiable programming feature, which we plan to push through Swift Evolution this year.

Assuming the differentiable programming feature had landed in master, the only other thing you need to compile TensorFlow package is to set up a CTensorFlow module map, which you can do with SwiftPM.

So in short, a fork of the compiler toolchain is not where we are headed in the long term. Instead, we try to push technologies to become included in the official Swift.

JetForMe · June 24, 2019, 8:19pm

This is what I'm hoping for. If Xcode let me choose the toolchain per-target, it might not matter so much, but it gets really cumbersome to need a different toolchain if I want to use TensorFlow inside my iOS app.

rxwei · June 24, 2019, 8:30pm

That's great to hear :) Though we haven't prioritized making all that possible today, it is absolutely important to us that iOS and Android apps can be developed using Swift for TensorFlow like a normal Swift library. The support for it is non-trivial because we'll need technologies such as MLIR to make sure mobile inference/training is efficient. Stay tuned :)