News for hackers. Stuff that matters.

A comment on Potential of the Julia programming language for high energy physics computing. Parent comment

Re:Potential of the Julia programming language for high ener... by jampekka on Monday December 04, 2023 @11:18AM (#38519135)
> The one you need is this which is already merged but was after the 1.10 feature freeze so it has to wait till 1.11, though you can test it with nightly builds which is available on julialang site: https://github.com/JuliaLang/julia/pull/51435

The discussion seems to be too deep in Julia internals for me to follow. Is this about startup time or defining an entry point (or both?). I haven't had problems with Julia entrypoints (yet at least).

With the nightly `./julia-f7618602d4/bin/julia -e "using DynamicalSystems"` still takes over 5 seconds. Can I somehow define a main to make this faster or precompile more efficiently?

> Since packagecompiler.jl already has C ABI and one goal discussed about binaries being easily callable from other languages and vice versa, I would bet that it will have shared libraries.

Sounds promising. Shared libraries are not a musthave for me, but could allow Julia save us from C++ in more cases.

[ Parent | on HN ]
Re:Potential of the Julia programming language for high ener... by amj7e on Monday December 04, 2023 @12:26PM (#38520134)
Thats for an entry point, you can search `Base.@main` to see a little summary of it. Later it will be able to be callable with `juliax` and `juliac` i.e. `~juliax test.jl` in shell.

DynamicalSystems looks like a heavy project. I don't think you can do much more on your own. There have been recent features in 1.10 that lets you just use the portion you need (just a weak dependency), and there is precompiletools.jl but these are on your side.

You can also look into https://github.com/dmolina/DaemonMode.jl for running a Julia process in the background and do your stuff in the shell without startup time until the standalone binaries are there.

[ Parent | on HN ]