3 ms·

Why is it a problem that python calls out to other languages as needed? It's not like it's obvious while you're using the library and the result can be, in fact

Why is it a problem that python calls out to other languages as needed? It's not like it's obvious while you're using the library and the result can be, in fact, very fast. The main benefit I can think of is that Julia could theoretically do whole-program optimization, but it doesn't and it doesn't model side effects so even if it wanted to it would be quite limited.

amkkma 5y ago
There are innumerable benefits that the compiler gets from being able to see into functions. Codegen, AD, fusion, inlining, user defined arrays and element types being first class etc
socialdemocrat 5y ago
It matters to package developers. If you can develop packages in Julia rather than in C++ you can move much faster. Also in Julia users of a package can much more easily contribute. A Python programmer cannot easily jump in an fix or add things to a package mostly written in C++. Also writing packages in C++ creates a fair amount of friction. Combining packages becomes easier. The ML world in Julia allows a lot more code sharing while in Python PyTorch and TensorFlow are large monoliths. E.g. different ML packages in Julia can use the same library of activation functions. Each ML library is not a completely different island of functionality.
snicker7 5y ago
There a lot of cases in scientific computing where using "glue code" of any sort can kill performance. You miss compile-time optimizations that can perform whole-program analysis. As a result, despite Julia being very FFI-friendly, the Julia community is trying to move towards a "pure Julia" ecosystem. Sometimes this attitude makes sense (Julia-native BLAS), other times not (Julia has no HTTP/2 packages).
sundarurfriend 5y ago
One benefit from the user's side that I've experienced is that, when debugging, I can go as far into the call stack as I want or need, using the same tools I use to inspect my own Julia code and read things in the same language throughout - no jarring context switch. This helps significantly with building a complete mental model of what you're debugging, and with ruling out a whole class of potential issues at or beyond the language border.
WanderPanda 5y ago
If it is all one language you can have very nice code-sharing. Imagine a function that takes some matrices and does some operation on them. If you now want to execute this function on a GPU you can just swapt the matrix type to GPU matrices and as long as you implement kernels for all the operators the function uses the function can be executed on the GPU without any modification. This modularity removes the requirement for each package that wants to use GPUs to recreate and ship their own numpy-like implementation (like Tensorflow, PyTorch etc.).
ska 5y ago
> Why is it a problem that python calls out to other languages as needed? There is not problem if a) someone has written that code in the other language already and b) it works correctly. But it's harder to build, modify and debug these things, generally. Glue code is useful, but it definitely has a cost.

amkkma 5y ago

There are innumerable benefits that the compiler gets from being able to see into functions. Codegen, AD, fusion, inlining, user defined arrays and element types being first class etc

socialdemocrat 5y ago

It matters to package developers. If you can develop packages in Julia rather than in C++ you can move much faster. Also in Julia users of a package can much more easily contribute. A Python programmer cannot easily jump in an fix or add things to a package mostly written in C++. Also writing packages in C++ creates a fair amount of friction. Combining packages becomes easier. The ML world in Julia allows a lot more code sharing while in Python PyTorch and TensorFlow are large monoliths. E.g. different ML packages in Julia can use the same library of activation functions. Each ML library is not a completely different island of functionality.

snicker7 5y ago

There a lot of cases in scientific computing where using "glue code" of any sort can kill performance. You miss compile-time optimizations that can perform whole-program analysis. As a result, despite Julia being very FFI-friendly, the Julia community is trying to move towards a "pure Julia" ecosystem. Sometimes this attitude makes sense (Julia-native BLAS), other times not (Julia has no HTTP/2 packages).

sundarurfriend 5y ago

One benefit from the user's side that I've experienced is that, when debugging, I can go as far into the call stack as I want or need, using the same tools I use to inspect my own Julia code and read things in the same language throughout - no jarring context switch. This helps significantly with building a complete mental model of what you're debugging, and with ruling out a whole class of potential issues at or beyond the language border.

WanderPanda 5y ago

If it is all one language you can have very nice code-sharing. Imagine a function that takes some matrices and does some operation on them. If you now want to execute this function on a GPU you can just swapt the matrix type to GPU matrices and as long as you implement kernels for all the operators the function uses the function can be executed on the GPU without any modification. This modularity removes the requirement for each package that wants to use GPUs to recreate and ship their own numpy-like implementation (like Tensorflow, PyTorch etc.).

ska 5y ago

> Why is it a problem that python calls out to other languages as needed? There is not problem if a) someone has written that code in the other language already and b) it works correctly. But it's harder to build, modify and debug these things, generally. Glue code is useful, but it definitely has a cost.