<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Mon, Nov 16, 2020 at 7:12 PM José Valim <<a href="mailto:jose.valim@gmail.com">jose.valim@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I am working on Tensorflow bindings and, at some point, Tensorflow forks a child process to invoke a separate program.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'm not sure I would like to have TensorFlow running inside the Erlang VM in the first place. My usage is currently to run TensorFlow Serving next to the Erlang VM and then use the REST API it has to move data back and forth for prediction etc. This also gives you a nice automatic upgrade path through TensorFlow Serving. If I need more speed, I'd work on protobuf3 and gRPC bindings, since that is another adoption path.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I've looked at bindings in the past, but it seems to be a lot of work for somewhat limited gain. For the bindings to make sense you need all the accompanying tooling as well. And data scientists write their code in Python or something such. They don't write code in anything else. Finally, getting TensorFlow to build correctly for your architecture and GPU is a non-trivial task, whereas there's already a provided docker container for TF Serving that just cuts corners here in a neat way.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">My usage pattern is usually to work out the model in Python and do some training there. The advantage being that I have friends who work in Python, so I can ask them all the silly questions about how to do certain things, and ignore their pleas for me using PyTorch instead :) Once it is trained, I save the model and push it into TF Serving, where it can then be called from my Erlang system. I am curious as to why you are thinking this is a wrong model, and what the benefit of having the Graph inside the Erlang VM would be in the first place. The only thing I could think of would be efficiency. But even then I would measure, since there are microbatching featuers in TF Serving and your GPU generally likes larger tensors sent to it anyway, so the communication overhead is somewhat dwarfed in the larger scale of things I'd think.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As an aside, we should really write a programming language with a type system supporting tensor shapes directly. I would remove so many small mistakes in TF execution it hurts.</div><br></div></div></div>