4 ms·

In my opinion, the issue that will make more of a difference in the long run is Mojo's first-class support for AoT compiled binaries (as well as JIT compilation

by ubj 3y ago

In my opinion, the issue that will make more of a difference in the long run is Mojo's first-class support for AoT compiled binaries (as well as JIT compilation). Julia's poor AoT support (with small binaries) is a major Achilles heel. I really wish that the Julia developers had taken that more seriously earlier on.

arbitrandomuser 3y ago
If anyone is interested in compiling small binaries with Julia do check out staticcompiler.jl and supporting statictools.jl that manages to produce small binaries without the Julia runtime , Ofcourse it's a wip , and not fully mature , I'm just putting it out there for people to know. There's some really cool demonstrations come out of this ... Wasm fluid simulation in Julia: https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ Differential equations demo in the browser: https://tshort.github.io/Lorenz-WebAssembly-Model.jl/ https://tshort.github.io/Lorenz-WebAssembly-Model.jl/ Someone even setup Julia to run on AVR mcus for Arduino (Directly using gpucompiler which statictools uses to compile to binaries): https://seelengrab.github.io/articles/Running%20Julia%20baremetal%20on%20an%20Arduino/ https://seelengrab.github.io/articles/Running%20Julia%20bare...
- ubj 3y ago
  Yep, I was aware of StaticCompiler.jl. I wish it was more mature. Static compilation is indeed possible with Julia. But it's very limited in its capabilities and certainly not as effortless as a simple `mojo build myfile.mojo`.
  - suavesito 3y ago
    Well, it is as simple as that... using PackageCompiler.jl [1] (PkgC.jl). It does create huge executable (you can easily trim them), but those are relocatable and portable between machines as they include most (if not all) of the dependencies needed to run them. They are already used in production in several places. I don't have the link at hand right now, but maybe someone else might jump to give the link to talks given by Chris Rackaukas on this. From my personal experience. I've done graphical apps in GTK3 in Julia with PkgC.jl cross-compiling from Linux to Windows. And they worked. :) [1] https://julialang.github.io/PackageCompiler.jl/stable/ https://julialang.github.io/PackageCompiler.jl/stable/
    - ubj 3y ago
      PackageCompiler.jl is more fully featured, and I'm definitely looking forward to further developments :) But it still has some pain points: * Massive executables (which you mentioned). This makes it very difficult to use with embedded systems. * Functions are not precompiled by default. You need to write a precompile script [1], which leads to a "two script problem": one script to do what you actually want, and another script that (hopefully) hits all the types you'll possibly need at runtime. And yes you can use `--trace-compile=file.jl` or SnoopCompile.jl instead, but this is still another step I need to worry about when compiling something. [1]: https://julialang.github.io/PackageCompiler.jl/dev/sysimages.html#tracing https://julialang.github.io/PackageCompiler.jl/dev/sysimages...
      - suavesito 3y ago
        While the second part is true, it is a fundamental restriction because Julia compiles a method until it is actually hit and types are defined for the call stack. In equivalent manner, for StaticCompiler.jl you need a declarations of the methods/symbols you need to export. So, while it is true you need to do an extra step compared with other languages, it is not a fundamental problem with respect to PackageCompiler.jl, but rather a design restriction given how Julia works.
        Max-Limelihood 3y ago
        That's not a fundamental restriction or design problem with Julia, you're just describing JIT compilation. Plenty of languages can be compiled either ahead-of-time or just-in-time. Actually, this should be unusually easy for Julia, because their JIT compiler isn't a heuristic-based compiler like JITs for Python or JS. The problem is funding. There are 0 full-time employees working on this issue because JuliaComputing has gotten about 10% of the funding Mojo has.
Certhas 3y ago
In the long run I think the determining factors will be: Connection to the Python ecosystem. Python remains the number 1 teaching language by a large margin. AI funding. If they can get the buy in from the AI community that Julia never got, they have the resources to engineer around any challenges faced. Solid foundation in modern language design, and with that, a focus on correct code produced by larger teams.
zarkenfrood 3y ago
I think in the long run the real difference will be if mojo gets accepted into industry usage given it initially looks like it is closer to python. Julia has struggled getting wider industry adoption and mojo is currently selling itself as minimal uplift from existing python which will help the sell in industry.
sundarurfriend 3y ago
FWIW, the core Julia developers seem to be taking this more and more seriously, and AoT compilation to small binaries seems more of a "when" question than an "if" at this point. Open source development - without multi-million dollar support from outside - is unpredictable, but I wouldn't be surprised if a year from now, writing a restricted subset of Julia allowed you AoT compilation to reasonable binaries (and not something as restricted as StaticCompiler.jl requires, just avoiding some of the extreme dynamic features).
- baggepinnen 3y ago
  You mean investment like this? https://info.juliahub.com/juliahub-receives-13-million-strategic-investment-from-ae-industrial-partners-horizonx https://info.juliahub.com/juliahub-receives-13-million-strat... You can imagine what a company like Boeing might be interested in when it comes to a programming language.
  - sundarurfriend 3y ago
    Boeing is probably interested in Julia for manufacturing optimization, so their interest is likely in improving the optimization ecosystem around JuMP [1], Optim [2], etc., and compiler improvements related to that. But we can only guess from the outside, and it's ultimately upto JuliaHub to decide how to spend the money, so I'll cross my fingers and hope that this gets us AoT static compilation sooner! [1] https://jump.dev/ https://jump.dev/ [2] https://julianlsolvers.github.io/Optim.jl/stable/ https://julianlsolvers.github.io/Optim.jl/stable/
  - Max-Limelihood 3y ago
    13 million is substantial but not even close to the 100 million Modular got. Which really makes me wonder what Modular has been doing with that money, if they're still getting beat in benchmarks like this...
    - DNF2 3y ago
      First of all, Mojo is quite new. Secondly, there might not be much CPU performance left on the table for that benchmark, no matter how much money you throw at it.
hpcjoe 3y ago
This is my current pain with Julia. It makes deploying code require the entire environment, or a PackageCompiler built sys-image. I've played with static compiler, and other techniques. They are sadly quite brittle for my previous use cases. Lack of ability to use threads in a static compiler built binary was a deal killer for me.

by ubj 3y ago

arbitrandomuser 3y ago

If anyone is interested in compiling small binaries with Julia do check out staticcompiler.jl and supporting statictools.jl that manages to produce small binaries without the Julia runtime , Ofcourse it's a wip , and not fully mature , I'm just putting it out there for people to know. There's some really cool demonstrations come out of this ... Wasm fluid simulation in Julia: https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ Differential equations demo in the browser: https://tshort.github.io/Lorenz-WebAssembly-Model.jl/ https://tshort.github.io/Lorenz-WebAssembly-Model.jl/ Someone even setup Julia to run on AVR mcus for Arduino (Directly using gpucompiler which statictools uses to compile to binaries): https://seelengrab.github.io/articles/Running%20Julia%20baremetal%20on%20an%20Arduino/ https://seelengrab.github.io/articles/Running%20Julia%20bare...

ubj 3y ago
Yep, I was aware of StaticCompiler.jl. I wish it was more mature. Static compilation is indeed possible with Julia. But it's very limited in its capabilities and certainly not as effortless as a simple `mojo build myfile.mojo`.
- suavesito 3y ago
  Well, it is as simple as that... using PackageCompiler.jl [1] (PkgC.jl). It does create huge executable (you can easily trim them), but those are relocatable and portable between machines as they include most (if not all) of the dependencies needed to run them. They are already used in production in several places. I don't have the link at hand right now, but maybe someone else might jump to give the link to talks given by Chris Rackaukas on this. From my personal experience. I've done graphical apps in GTK3 in Julia with PkgC.jl cross-compiling from Linux to Windows. And they worked. :) [1] https://julialang.github.io/PackageCompiler.jl/stable/ https://julialang.github.io/PackageCompiler.jl/stable/
  - ubj 3y ago
    PackageCompiler.jl is more fully featured, and I'm definitely looking forward to further developments :) But it still has some pain points: * Massive executables (which you mentioned). This makes it very difficult to use with embedded systems. * Functions are not precompiled by default. You need to write a precompile script [1], which leads to a "two script problem": one script to do what you actually want, and another script that (hopefully) hits all the types you'll possibly need at runtime. And yes you can use `--trace-compile=file.jl` or SnoopCompile.jl instead, but this is still another step I need to worry about when compiling something. [1]: https://julialang.github.io/PackageCompiler.jl/dev/sysimages.html#tracing https://julialang.github.io/PackageCompiler.jl/dev/sysimages...
    - suavesito 3y ago
      While the second part is true, it is a fundamental restriction because Julia compiles a method until it is actually hit and types are defined for the call stack. In equivalent manner, for StaticCompiler.jl you need a declarations of the methods/symbols you need to export. So, while it is true you need to do an extra step compared with other languages, it is not a fundamental problem with respect to PackageCompiler.jl, but rather a design restriction given how Julia works.
      - Max-Limelihood 3y ago
        That's not a fundamental restriction or design problem with Julia, you're just describing JIT compilation. Plenty of languages can be compiled either ahead-of-time or just-in-time. Actually, this should be unusually easy for Julia, because their JIT compiler isn't a heuristic-based compiler like JITs for Python or JS. The problem is funding. There are 0 full-time employees working on this issue because JuliaComputing has gotten about 10% of the funding Mojo has.

Certhas 3y ago

In the long run I think the determining factors will be: Connection to the Python ecosystem. Python remains the number 1 teaching language by a large margin. AI funding. If they can get the buy in from the AI community that Julia never got, they have the resources to engineer around any challenges faced. Solid foundation in modern language design, and with that, a focus on correct code produced by larger teams.

zarkenfrood 3y ago

I think in the long run the real difference will be if mojo gets accepted into industry usage given it initially looks like it is closer to python. Julia has struggled getting wider industry adoption and mojo is currently selling itself as minimal uplift from existing python which will help the sell in industry.

sundarurfriend 3y ago

FWIW, the core Julia developers seem to be taking this more and more seriously, and AoT compilation to small binaries seems more of a "when" question than an "if" at this point. Open source development - without multi-million dollar support from outside - is unpredictable, but I wouldn't be surprised if a year from now, writing a restricted subset of Julia allowed you AoT compilation to reasonable binaries (and not something as restricted as StaticCompiler.jl requires, just avoiding some of the extreme dynamic features).

baggepinnen 3y ago
You mean investment like this? https://info.juliahub.com/juliahub-receives-13-million-strategic-investment-from-ae-industrial-partners-horizonx https://info.juliahub.com/juliahub-receives-13-million-strat... You can imagine what a company like Boeing might be interested in when it comes to a programming language.
- sundarurfriend 3y ago
  Boeing is probably interested in Julia for manufacturing optimization, so their interest is likely in improving the optimization ecosystem around JuMP [1], Optim [2], etc., and compiler improvements related to that. But we can only guess from the outside, and it's ultimately upto JuliaHub to decide how to spend the money, so I'll cross my fingers and hope that this gets us AoT static compilation sooner! [1] https://jump.dev/ https://jump.dev/ [2] https://julianlsolvers.github.io/Optim.jl/stable/ https://julianlsolvers.github.io/Optim.jl/stable/
- Max-Limelihood 3y ago
  13 million is substantial but not even close to the 100 million Modular got. Which really makes me wonder what Modular has been doing with that money, if they're still getting beat in benchmarks like this...
  - DNF2 3y ago
    First of all, Mojo is quite new. Secondly, there might not be much CPU performance left on the table for that benchmark, no matter how much money you throw at it.

hpcjoe 3y ago

This is my current pain with Julia. It makes deploying code require the entire environment, or a PackageCompiler built sys-image. I've played with static compiler, and other techniques. They are sadly quite brittle for my previous use cases. Lack of ability to use threads in a static compiler built binary was a deal killer for me.