Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Swift for TensorFlow?

github.com

Post reply on HN
Print view View original

141–150 of 151 posts

Re: Why Swift for TensorFlow?

#141

Post by phillipcarter »

tanilama wrote: post #89
phillipcarter wrote: post #50

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…

> Who would trade static typing with fast prototyping any time.

These need not be at odds. Many ML languges like F# or OCAML, by use of type inference, get you type safety without having to type a bunch of stuff and sacrifice faster prototyping. And certainly in F# there is a history of having productive tooling that lets you prototype easily. Simply writing some F# code in an F# script in an IDE, hitting alt+Enter, and letting it execute in an interactive shell is hugely productive for exploratory tasks. And features like Type Providers build out types for an arbitrary data set that let you guarantee your code is actually correct for the data.

What I've mentioned isn't without its flaws, and eventually someone is going to reach head-scratching problems just as they would in any other environment. I don't think there's an objective way to measure productivity across a wide range of professionals, but I do believe that some subset of them would prefer static types for their work. This is backed by conversations with some of them about problems they encounter.

Re: Why Swift for TensorFlow?

#142

Post by Redoubts »

marcrasi wrote: post #36
skwb wrote: post #32

Earlier quoted context omitted.

What is the plotting experience like though? As I previously mentioned, plotting is one of the main reasons our group uses python. Another reason now that I think about it, is the number of scientific libraries that I can just "pip install" without much thought (such as scipy/opencv).

You can call out to matplotlib (or any other python libraries installed on your system), using the python interop feature ( https://github.com/tensorflow/swift/blob/master/docs/PythonI... )! https://github.com/google/swift-jupyter#rich-output has an example with screenshots.

Oof

Re: Why Swift for TensorFlow?

#143

Post by Redoubts »

m0zg wrote: post #56
rudedogg wrote: post #52

Earlier quoted context omitted.

Sorry, I just didn't want to give people the impression that it's more difficult than other languages. To upgrade you'd just have to remove the original install directory and untar the new release. I'm not familiar with Snap, but I did find https://snapcraft.io/swift Also, upgrading will be less common than Rust since almost everyone uses the latest release/toolchain. There's not really a reason to use the daily buil…

For comparison, for Go, it's "sudo snap refresh go". For Rust it's "rustup update stable". I mean, how hard would it be to properly package this stuff, and why should tens of thousands of users deal with all this manual downloading and unpacking? Assuming, of course, that Swift folks don't deliberately want to make the language unpolular, like Haskell.

I’m kinda annoyed there’s no PPA for this, but I suspect they won’t bother shipping this in the standard repo until there’s a stable ABI

Re: Why Swift for TensorFlow?

#144

Post by byt143 »

dnautics wrote: post #104
ninjin wrote: post #98

Earlier quoted context omitted.

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 siz…

1) It is not the duty of AD to favor an array type, but flux is an ML library. When you do something like Chain() or Dense() or LSTM() in flux, which is very obviously an ML tensor operation, it SHOULD pick reasonable, fixed (or variable!) tensor dimension. This is maybe not so easy, but it should be doable. Likewise, I wish Flux had "batch" and "minibatch" types that had specifiable dimensions so that if you try to…

Regarding 3, can you make an issue or discourse post for discussion?

Re: Why Swift for TensorFlow?

#145

Post by ychen306 »

dnautics wrote: post #103
ychen306 wrote: post #47

Earlier quoted context omitted.

I will say this in the risk of talking out of my ass as I have no experience in either language :). Having a statically typed language greatly simplifies the tooling because static analysis is much easier; graph program extraction involves one such analysis. When you have to deploy the trained model in production one would hope not to use Python or Julia. I'd like to add that, with my limited experience in prototypin…

what's the problem with deploying julia in production in inference? Some occasional piece of data that looks wrong in an unanticipated way causes a runtime type fault? People deploy high uptime websites with django - how do they do it? Well you use kubernetes (or, gasp, systemd) and have restart and load balancing logic. Even if you were typecheck-compiled, you can't guarantee some other developer logic or system err…

The problem comes down to how you use your model, which is all that matters. If there is a mismatch between the language in which your model is embedded in and the language in which your main application/interface is written in, then ideally you want a way to extract the model statically from the dev environment. It's not about type-checking per se, which is nice, but how you get the model out without having to, say, start a python interpreter in your server process just to do the inference (which is why in some aspect Tensorflow is more convenient).

Re: Why Swift for TensorFlow?

#146

Post by ychen306 »

shele wrote: post #105
dnautics wrote: post #103

Earlier quoted context omitted.

what's the problem with deploying julia in production in inference? Some occasional piece of data that looks wrong in an unanticipated way causes a runtime type fault? People deploy high uptime websites with django - how do they do it? Well you use kubernetes (or, gasp, systemd) and have restart and load balancing logic. Even if you were typecheck-compiled, you can't guarantee some other developer logic or system err…

On the other hand, Julia can do the right thing dynamically . Your matrix happens to be symmetric? Julia will chose an appropriate factorisation and will propagate that knowledge through dynamic dispatch.

Which you don't need most of the time in production because you can statically determine which operation needs to happen without the overhead of dynamically choosing the operation.

Re: Why Swift for TensorFlow?

#147

Post by ychen306 »

skohan wrote: post #131
dnautics wrote: post #129

Earlier quoted context omitted.

You don't know what you're talking about.

Tell me where I'm wrong

You are not wrong. For some "highly dynamic" applications, say, optimizing compiler IR where there are many different subclasses of IR nodes, dynamic dispatch is nice. But when you are running an ML model, scientific application where you already know which sparse matrix format you need, etc, you can do all of that statically with less overhead and performance predictability. This is in no way an argument against Julia; the point is that you don't need dynamic dispatch if you can statically determine what needs to happen.

Re: Why Swift for TensorFlow?

#148

Post by siproprio »

byt143 wrote: post #54

Julia would have been a much better and more cost effective choice in my opinion. It's a superior platform to on which develop this sort of thing, and further along at that. Also easier to use.

Julia doesn't have a debugger... They specifically claimed this is a very important thing.

In my experience, Julia has also inscrutable scoping rules, a slow REPL, and it's only fast if you don't count the "startup time" of having to precompile everything.

Re: Why Swift for TensorFlow?

#149

Post by m0zg »

Redoubts wrote: post #143
m0zg wrote: post #56

Earlier quoted context omitted.

For comparison, for Go, it's "sudo snap refresh go". For Rust it's "rustup update stable". I mean, how hard would it be to properly package this stuff, and why should tens of thousands of users deal with all this manual downloading and unpacking? Assuming, of course, that Swift folks don't deliberately want to make the language unpolular, like Haskell.

I’m kinda annoyed there’s no PPA for this, but I suspect they won’t bother shipping this in the standard repo until there’s a stable ABI

And that's fine: ship an official snap or use the Rust solution. Not doing this very directly impacts adoption. Most people won't even try to set it up.

Re: Why Swift for TensorFlow?

#150

Post by KenoFischer »

ychen306 wrote: post #147
skohan wrote: post #131

Earlier quoted context omitted.

Tell me where I'm wrong

You are not wrong. For some "highly dynamic" applications, say, optimizing compiler IR where there are many different subclasses of IR nodes, dynamic dispatch is nice. But when you are running an ML model, scientific application where you already know which sparse matrix format you need, etc, you can do all of that statically with less overhead and performance predictability. This is in no way an argument against Jul…

That is basically the core insight behind julia. The really performance sensitive parts of your application are already static just by the nature of that code, so we can extract that static information to make it really fast. We can also make use of the same static information for static error messages or static compilation and get the best of both world (dynamic during development, static when you're done), but the tooling for that is a bit less developed at the moment.
Post reply on HN