Hi All, I saw this question first popped up at JuliaCon 2021: [The State of Julia | JuliaCon 2021 | Stefan Karpinksi, Viral Shah, Jeff Bezanson, & Keno Fischer] Since then I have seen a lot of talk and discussion about it as well as some attempt (StaticCompiler.jl) to address the missing feature of producing small binaries. I am asking about it because a lot of IT people around me are simply not interested in Julia because of that. I work in a large company and saw Rust and Go take off but no one wants to use Julia (even the small group of people who uses Python and R). They see simply no reason to learn a new language. I would like to see Julia really take off. From my point of view it did not so far, and looking at some programming language ranking it is still laging behind Rust and Go. Like one of the comment in the youtube video I posted above, I think the ability to produce binaries “would make this thing blow up” and would solve a lot of the latency issues the language has. Jeff Benzanson, in the video, said that he does not have a specific deadline for separate compilation and that his personal goal was to present a prototype the next year… I just have a couple of questions: does the Julia core team think that having small binaries is a pressing issue or not? -is there a roadmap to address small binaries/dll generation? Thank you.

So while there isn’t a clear roadmap at the moment, it is a goal of the Julia team to have small binaries (It’s the main thing I’ll be working on in the near future). The vision is to have something like juliac that takes in a module or a script (this isn’t super clear just yet, but also isn’t super important, it just needs to be something with well defined entry points (main/shared library API) and generates a binary from that. I believe that from that we will have 3 different options to generate the code, one would be equivalent to what PackageCompiler.jl does right now, the other will be StaticCompiler.jl and the one that’s missing, which will allow using the runtime but will require a well defined call graph (known targets for a possible dynamic dispatch) so that we know what code to compile, and more importantly what to throw away, so that the final binary isn’t too big.

[image] mkitti: Could you run @time main() twice to see the effect of in memory compilation caching? Sure, and I find the cost is stable. julia> @time main() 149927 0.485954 seconds (49.94 k allocations: 780.336 KiB) julia> @time main() 149861 0.485176 seconds (49.87 k allocations: 779.305 KiB) julia> @time main() 149820 0.484067 seconds (49.83 k allocations: 778.664 KiB) [image] mkitti: I would also be interested in seeing the difference in the LLVM IR ot native code generation. I’m not sure. In fact, I did nothing special here. Upsilon/Phi-C nodes are directly translated into some C-family language, and the try-catch construct in the target language is leveraged to implement stuffs. However, the encoding for Upsilon nodes/PhiC nodes might be quite different from the one that Julia uses: block_t _B; handle_error: try { switch (_block_target(_B)) { case 0: goto _L1; case catch_clause_jump_target1: goto _Li; ... case catch_clause_jump_target2: goto _Lk; } // normal code gen // Expr(:enter, jump_target_i) => _block_push(_B, jump_target_i); } catch (exception e) { _exception_wrap_and_push(e); goto handle_error; } I don’t have an idea, or I won’t think this interesting. One thought could be our simplification to the stacktrace. So far our AOT Julia creates stacktrace that is more restricted, and more complete stacktrace is available only when the .dwo/.pdb files created by the AOT compiler are also kept beside the generated shared libraries/executable.

[image] thautwarm: Recently, our AOT compiler (made by my team)…our generated native code greatly outperforms vanilla Julia in terms of try-catch-finally statements, while in general cases our AOT Julia is slightly slower than the vanilla. This may likely end up in an announcement post anyway if it isn’t closed-source, but can I ask why this compiler diverges from the mainstream compiler rather than repurpose it with additional optimizations assuming no further code is evaluated? Or does it not diverge and it’s slightly slower in general for different reasons?

That’s great news. Thanks for sharing. As @ChrisRackauckas said in the Julia subreddit, there is also a plan that includes a static subset of Julia. Are there ideas about a little more explicit memory management? For example, we can already use Bumper.jl with StaticCompiler.jl which is a great combination, but there isn’t an interface to use Bumper with most of the language(i.e. Sockets). Or this line of thinking is not in the current plans?

For now the plan is to keep using and improving the GC.

[image] gbaraldi: the one that’s missing, which will allow using the runtime but will require a well defined call graph (known targets for a possible dynamic dispatch) so that we know what code to compile, and more importantly what to throw away, so that the final binary isn’t too big. Occasionally, what I want along these lines is just a launcher. A launcher is just an executable that will switch to a specific environment and then run a main function with a full Julia install. On some platforms this is easy enough to do with a shell script or perhaps a small C program. A cross platform way to do this entirely in Julia without depending on a shell or a C compiler would be nice.

You can do that with juliaup (portable version) and a .bat file. I already do it. For linux/apple you’ll need a bash script. The bat file download the portable version of juliaup from github, setup some variable in PATH, then juliaup install julia, then launch julia and run some script, then remove everything at the end. That being said not sure what you mean by environment in this context. If it is a julia environment then it is also easy. (Anyway I think this is off topic)

I’m really excited for the AOT compiler

Yes, that’s a completely different issue though. That’s more a question of defining and better supporting what a Julia app is. We definitely want that as well though. There’s a GitHub issue somewhere.

In the video the example is x + y, and while that’s only an example I do feel that math heavy code is more often talked about when we talk about compiling things. To me it seems instead that the bigger “market” with binaries is for string and io heavy code. Because that includes all the general purpose tools like formatters, linters, web servers that you want to deploy somewhere remotely and spin up quickly. Strings, GC and allocations are not at all a focus of GPUCompiler I’d say, and StaticCompiler also doesn’t really allow them for that reason. But I think the community infrastructure would gain much more from work on that than from packaging up purely numeric code. At least I assume that because purely numeric code doesn’t seem like the kind of thing to me where you don’t have the option to run a normal Julia session. Unless targetting embedded devices maybe. So what is the optimum we can reach while still including all String, GC and related functionality, just no dynamic compilation?

Isn’t the case for purely numeric code replacing C/C++/Fortran in producing binary numeric libraries, e.g. that can be used by R and Python packages, embedded, etc. There’s a huge potential “market” there working directly from julias current strengths.

Roadmap for small binaries

Internals & Design

LaurentPlagne December 22, 2023, 12:11pm 122

In addition, It is often the case where you can’t directly switch the language for a large simulation software, and easily callable Julia libraries could greatly help the progressive adoption of Julia.

Topic		Replies	Views
Building stand-alone helloworld produces many dlls, being 200MB big New to Julia	37	6713	November 18, 2021
Why is static compilation difficult General Usage	7	2128	September 14, 2023
Could Someone Explain To Me the Desire for Small Julia Binaries? General Usage question	41	5479	June 12, 2023
Statically compiled and statically linked General Usage	35	10288	September 8, 2020
Julia static compilation General Usage question	38	15032	February 15, 2019

Roadmap for small binaries

Related topics