Implications of setting SIGCHLD in relation to NIFs

[Jesper Louis Andersen]

On Mon, Nov 16, 2020 at 7:12 PM José Valim <jose.valim@REDACTED> wrote:

>
> I am working on Tensorflow bindings and, at some point, Tensorflow forks a
> child process to invoke a separate program.
>

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201122/69891de7/attachment.htm>