6 ms·

This blog post reminds me of the "Machine Learning Systems are Stuck in a Rut" paper [1], where they mentioned: > It is hard to experiment with front end featu

This blog post reminds me of the "Machine Learning Systems are Stuck in a Rut" paper [1], where they mentioned: > It is hard to experiment with front end features like named dimensions, because it is painful to match them to back ends that expect calls to monolithic kernels with fixed layout. On the other hand, there is little incentive to build high quality back ends that support other features, because all the front ends currently work in terms of monolithic operators. An end-to-end tool chain for machine learning requires solutions from many specialist disciplines. This is a fantastic example of getting around this problem using Flux.jl's interaction with the full Julia language. Here the author does some exceedingly cool stuff (doing machine learning on encrypted data!), and in order to get there he needed to write what many would think of as lower-level kernels that should be "provided by the library" (encrypted matrix multiplication, encrypted convolutions). To make the interface useful, he needed to use a mature interface that people are already using and make it something that can automatically switch over to encrypted implementations. And, because of the nature of fully homeomorphic encryption, the implementation has to be fast, otherwise it's dead in the water since FHE is expensive! To me, this example showcases one way how Flux.jl's is helping machine learning get out of that "rut". The author adds dispatches to standard kernels which allow for his encrypted data types, which then allows standard Julia Flux.jl machine learning models to act on encrpyted data, and it uses type-inference + JIT compilation to make it fast enough to work. Not only that, but it's also not tied to some "sub-language" defined by a machine learning framework. That means the FHE framework not only works nicely with machine learning, it can be used by any other package in the Julia language (differential equation solvers, nonlinear optimization, macroeconomics models?). This allows composibility of tools and community: all tools from all fields can now use this same FHE implementation, so authors collaborate and mature this to a very good one. These knock-on effects give people doing research in Julia a lot of competitive advantages over other researchers, and it will be interesting to see how this effects not just the ML research community, but also everyone else! https://dl.acm.org/citation.cfm?id=3321441 https://dl.acm.org/citation.cfm?id=3321441 (Repost from the previous thread on this!)

yowlingcat 7y ago
Thanks for this provocative comment -- if you don't mind me asking, what do you think the tradeoffs are between using Julia and Python for ML in production? I get the idea of right tool for the right job and all, and I know that Python has a fantastic ecosystem. But, how close is Julia? How developed is the ecosystem right now, and how fast is it developing?
- eigenspace 7y ago
  Julia has a smaller ecosystem than Python for sure, however julia has a couple of key ecosystem advantages that make it punch well above its weight class. It really just boils down to the fact that julia's core value proposition is primarily enticing to domain experts trying to implement new algorithms without wanting to worry about switching languages for performance hotspots or having to reimplement existing functionality from other packages. Julia packages tend to be small, focused and astonishingly composable. Hence, the proportion of the community that are actively developing and maintaining state of the art pacakges in julia is way higher than that in other languages like Python. Furthermore, even if you're not some super researcher developer, Julia substantially lowers the bar for mere mortals such as myself to do package development. The composability I mentioned above means that I can stand on the shoulders of giants as I implement my own stuff, plus the fact that the majority of libraries are written in pure julia means that I can easily "peek under the hood" to figure out how they work and learn from them. It's hard to make broad statements about how much ecosystem support one can expect from julia without first specifying the field. Some fields have fantastic julia support and others haven't received enough attention. It really just depends on if someone from your field has started making good packages yet.
orbifold 7y ago
Julia always seemed great on paper and definitely is a strong candidate for replacing Matlab. But whenever I tried using it, the user experience seemed much more broken than python or c++. It just seems way easier to structure and work on a python + c++ project than it is to structure and work on a Julia project. A moderately sized sane c++ code base compiles and runs faster than whatever gymnastics Julia performs to create a single 2d plot (literally freezes my laptop for seconds). It also installs gigabytes worth of libraries into global directories by default. The compiler itself is also of questionable quality compared to clang, Swift or Ocaml.
- nslocum 7y ago
  Julia is compiled using LLVM.
- eigenspace 7y ago
  Compiler latency is being actively worked on and a PR was just pushed to Plots.jl which halved the time to first plot for many users. Note that even before this though, it's just the compilation phase for the first plot that's expensive. Plotting itself is quite fast in julia, and if you start up julia with the command line argument `--compile=min` you'll see very very fast first plots. Obviously, this will come with a runtime performance cost though.
- svnpenn 7y ago
  > literally freezes my laptop for seconds Yep. This has been commented on again and again, but many refuse to show willingness to fix or even acknowledge the problem: https://github.com/JuliaLang/julia/issues/28092 https://github.com/JuliaLang/julia/issues/28092 https://github.com/JuliaLang/julia/issues/17285 https://github.com/JuliaLang/julia/issues/17285 https://github.com/JuliaLang/julia/issues/4452 https://github.com/JuliaLang/julia/issues/4452 https://github.com/JuliaLang/julia/issues/1064 https://github.com/JuliaLang/julia/issues/1064 https://github.com/JuliaLang/julia/issues/260 https://github.com/JuliaLang/julia/issues/260
  - pkofod 7y ago
    What do you mean by "refuse to show willingness to fix or even acknowledge the problem"? Do you realize that two of those issues were started by core contributors?
mikorym 7y ago
> fully homeomorphic encryption I think you mean fully homomorphic encryption, that is, f(x.y)=f(x).f(y). A homeomorphism is a isomorphism of topological spaces. If you do mean the latter then it would be something new (and I am curious to hear about it).
- ChrisRackauckas 7y ago
  Oops :)

yowlingcat 7y ago

Thanks for this provocative comment -- if you don't mind me asking, what do you think the tradeoffs are between using Julia and Python for ML in production? I get the idea of right tool for the right job and all, and I know that Python has a fantastic ecosystem. But, how close is Julia? How developed is the ecosystem right now, and how fast is it developing?

eigenspace 7y ago
Julia has a smaller ecosystem than Python for sure, however julia has a couple of key ecosystem advantages that make it punch well above its weight class. It really just boils down to the fact that julia's core value proposition is primarily enticing to domain experts trying to implement new algorithms without wanting to worry about switching languages for performance hotspots or having to reimplement existing functionality from other packages. Julia packages tend to be small, focused and astonishingly composable. Hence, the proportion of the community that are actively developing and maintaining state of the art pacakges in julia is way higher than that in other languages like Python. Furthermore, even if you're not some super researcher developer, Julia substantially lowers the bar for mere mortals such as myself to do package development. The composability I mentioned above means that I can stand on the shoulders of giants as I implement my own stuff, plus the fact that the majority of libraries are written in pure julia means that I can easily "peek under the hood" to figure out how they work and learn from them. It's hard to make broad statements about how much ecosystem support one can expect from julia without first specifying the field. Some fields have fantastic julia support and others haven't received enough attention. It really just depends on if someone from your field has started making good packages yet.

orbifold 7y ago

Julia always seemed great on paper and definitely is a strong candidate for replacing Matlab. But whenever I tried using it, the user experience seemed much more broken than python or c++. It just seems way easier to structure and work on a python + c++ project than it is to structure and work on a Julia project. A moderately sized sane c++ code base compiles and runs faster than whatever gymnastics Julia performs to create a single 2d plot (literally freezes my laptop for seconds). It also installs gigabytes worth of libraries into global directories by default. The compiler itself is also of questionable quality compared to clang, Swift or Ocaml.

nslocum 7y ago
Julia is compiled using LLVM.
eigenspace 7y ago
Compiler latency is being actively worked on and a PR was just pushed to Plots.jl which halved the time to first plot for many users. Note that even before this though, it's just the compilation phase for the first plot that's expensive. Plotting itself is quite fast in julia, and if you start up julia with the command line argument `--compile=min` you'll see very very fast first plots. Obviously, this will come with a runtime performance cost though.
svnpenn 7y ago
> literally freezes my laptop for seconds Yep. This has been commented on again and again, but many refuse to show willingness to fix or even acknowledge the problem: https://github.com/JuliaLang/julia/issues/28092 https://github.com/JuliaLang/julia/issues/28092 https://github.com/JuliaLang/julia/issues/17285 https://github.com/JuliaLang/julia/issues/17285 https://github.com/JuliaLang/julia/issues/4452 https://github.com/JuliaLang/julia/issues/4452 https://github.com/JuliaLang/julia/issues/1064 https://github.com/JuliaLang/julia/issues/1064 https://github.com/JuliaLang/julia/issues/260 https://github.com/JuliaLang/julia/issues/260
- pkofod 7y ago
  What do you mean by "refuse to show willingness to fix or even acknowledge the problem"? Do you realize that two of those issues were started by core contributors?

mikorym 7y ago

> fully homeomorphic encryption I think you mean fully homomorphic encryption, that is, f(x.y)=f(x).f(y). A homeomorphism is a isomorphism of topological spaces. If you do mean the latter then it would be something new (and I am curious to hear about it).

ChrisRackauckas 7y ago
Oops :)