Live data from Hacker News

Why Swift for TensorFlow?

github.com

91–100 of 151 posts

Re: Why Swift for TensorFlow?

#91

I still don't understand why they would choose Swift over C#? They complain about C#/Java having "highly dynamic constructs" but correct me if I'm wrong but isn't swift also a GC/OOP like Java and C#? I don't think Swift has any inherent objective advantages over c#. I think it would have been a better decision to go with C# over Swift as Microsoft has a clear roadmap with the language and it is already supported on…

While I do think the choice of Swift is kind of weird, you are wrong about Swift being garbage collected (it uses Automatic Reference Counting). It also compiles to actual machine code (rather than an intermediate representation for use in a VM).

Reference counting is a garbage collection algorithm as per CS literature, you are mixing it up with tracing garbage collection algorithms.

Swift makes use of SIL and LLVM bitcode before the final binary is produced.

Likewise C# can be AOT compiled to actual machine code via NGEN, .NET Native, CoreRT and Mono/Xamarin.

Re: Why Swift for TensorFlow?

#93

I still don't understand why they would choose Swift over C#? They complain about C#/Java having "highly dynamic constructs" but correct me if I'm wrong but isn't swift also a GC/OOP like Java and C#? I don't think Swift has any inherent objective advantages over c#. I think it would have been a better decision to go with C# over Swift as Microsoft has a clear roadmap with the language and it is already supported on…

I would rather claw my eyes out than write any ML stuff in C#.

It's a fine enterprise language, but good lord writing data science and machine learning stuff in it would be an right pain. It's also not super high performance, and when you're doing a lot of maths heavy operations, high performance is absolutely crucial. I had great difficulty establishing whether SIMD/vectorisation was even supported, and then even more difficulty getting it to work.

Julia would have been a far, far superior choice than Swift.

Re: Why Swift for TensorFlow?

#96

Earlier quoted context omitted.

More to the point static typing is just not that important for data scientists. Arguably it's not that important for backends devs either (e.g. lisp, erlang).

Should be prefaced with, "I think". Having done user research on this by speaking to data scientists, I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning. Much like how TypeScript is seen as a revelation to hordes of JavaScript programmers who have never used static types before, the ability to get some level of correctness verific…

In that regard Julia is hardly any different to TypeScript.

Re: Why Swift for TensorFlow?

#97

Earlier quoted context omitted.

Should be prefaced with, "I think". Having done user research on this by speaking to data scientists, I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning. Much like how TypeScript is seen as a revelation to hordes of JavaScript programmers who have never used static types before, the ability to get some level of correctness verific…

> I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning Who would trade static typing with fast prototyping any time. Data science is a really nebulous term covering many drastically different domains of CS. Many DS I talked with, don't really produce code, they do coding to produce analysis, which is the actual delivery. For them, c…

Although I am a big fan of a couple of dynamic languages, when it scales we really need static types to make any sense of it, even to our older selfs a couple of months down the line.

So gradual typing like in Julia is already a good thing for having the best of both worlds.

Re: Why Swift for TensorFlow?

#98

Earlier quoted context omitted.

> achieved with optional typing (presuming a well designed type system) Enter stage left: Julia Julia is already pretty great, I'd really love to see what cool stuff we could have with a swell in community size and investment!

Yeah that's kind of what I'm referring to but the default array typing in flux.ml doesn't encode tensor dimensionality in the type system. If it did (which it very easily could in julia) you wouldn't wind up with a situation where your learning task halts in the middle of a training run, which can happen in flux.ml

Due to the way that code composition works in Julia, there is no real “default” array for Flux. Rather, you can lift in any array type that you like. The GPU arrays are an excellent example of this, Flux “knows” nearly nothing about GPUs (apart from a few convenience functions), yet works perfectly when using a GPU array type. So there is nothing stopping you from lifting in say StaticArrays [1] which carries the sizes in the type or NamedArrays [2] where dimensions have explicit names – the latter being superior in practice to the former in my opinion, or perhaps someone is up for marrying the two?

[1]: https://github.com/JuliaArrays/StaticArrays.jl

[2]: https://github.com/davidavdav/NamedArrays.jl

In brief, it is not the duty of the automatic differentiation package to favour a specific array type – it just works for all of them, which is something that I find fairly magical with Julia.

Re: Why Swift for TensorFlow?

#100
post #27

Earlier quoted context omitted.

I am a bit ignorant on the topic, but is swift available for Windows/Ubuntu? Most of the deep learning scientists I know and work with use either of the two setups. I know there technically exists CUDA GPU support for Apple, but I have frankly never even attempted to mess with it.

Ubuntu is supported (see https://swift.org/download/ ), but Windows is pretty early I think. See https://github.com/apple/swift/blob/master/docs/Windows.md and https://forums.swift.org/t/windows-nightlies/19174 for more info.

Ubuntu is "supported". The compiler might be available, but there are hardly many libraries available that would compile outside Apple platforms.
Post reply on HN