r/Julia

I'm working on a communication network simulator using discrete event simulation. In a normal simulation a GC pause is not an issue at all, but in HIL (hardware-in-the-loop) simulations an occasional 10ms GC pause doesn't look good. A HIL simulation doesn't have very hard timing constraints, some lag below the maximum limit (e.g. 100us) is acceptable if on average the simulation can keep the pace with the hardware. A typical HIL simulation usually doesn't take too much time anyway, because one has to actually wait for it to finish in real time. It's very often used to compare the intricate details of the hardware with the simulation model. (e.g. timing)

My question is what kind of solutions can you think of for reducing the long tail of GC pause distribution?

In these communication network simulation models, most objects which are allocated during event processing don't survive the event. There are basically two exceptions: either something went into the simulation engine's future event set (e.g. a new event containing a packet) or went into the long term simulation model state (e.g. updating a routing table). The former is much more common than the latter. So a simulation has a very specific allocation pattern, which the GC has no information at all.

Of course, the simulation could be carefully organised such that the number of allocations is absolutely minimal, or it could use object pools for commonly used data structures, and some other ticks on the simulation model side.

What else can be done regarding this issue? Is there anything that can be fine tuned in the GC? I've heard there are changes related to this in the upcoming Julia version.

So I've been working on a projectional editor and a discrete event simulator for communication systems lately and I faced the usual FTTX problem. Even though I used PackageCompiler.jl the UI took several seconds to start and many user interface interaction took like a second or more for the first time. Similarly, running even a very short simulation on the command line using the console took an unnecessarily long time. Of course this is a known issue. Compilation took like 99% of the time in these cases.

So I did what, I guess, every user does. I added compile workload by utilizing the user interface in headless mode with every possible edited data structure and projection. Similarly I also run all simulations for some time to allow the compiler to do it's job and save the compiled code into the final executable image. It did work as expected, but one problem remained. How long should I execute the simulations and how many UI projections and operations should I utilize? Because the more I do, the longer it will take for each precompilation to finish.

I tried two techniques: utilizing the actual features like a user would and artificially forcing the compiler to compile functions for certain argument type combinations. The former took too much time during each precompilation because it's difficult to run the real algorithms such that they utilize all interesting code paths but avoid running unnecessarily long. The latter produced many useless compiled functions for unused type signatures growing the image and also often missed many important ones.

I was kinda stucked. I discussed this issue with AI, but didn't get much help. Then I realized I can use the two techniques together in a sufficiently efficient and accurate way. Maybe this is widely known, but I didn't find this idea, and I just thought it may help others.

So the idea is to have a compilation database, basically a text file, which tells the compiler which function signatures to precompile. The database is created by utilizing the features of the program as a user would, running the UI, emulating the clicks, doing the operations, doing the screen refreshes, running the simulations, etc. and saving all the compiled function type signatures. It doesn't matter if takes a lot of time, because it doesn't get updated for every change. The reason it works is because the compiler can fill in the missing 1% in the real running program and nobody will notice it. Also, when the functions are precomplied from the database some of them fail due to changes in the program. When the percentage of failures becomes large enough that is a good sign to regenerate it.

It does work pretty well. The UI starts up in like half a second, every click on the UI is like a few times 10ms, a simulation with zero duration starts sets up the whole engine and infrastructure and finishes like in less than half a second from the command line. That's an acceptable performance for me.

One of the things I wanted to achieve with LowLevelFEM.jl was to keep finite element code reasonably close to the mathematical formulation.

For example, the stiffness matrix for a 3D linear elasticity problem can be written as

K = ∫(SymGrad(Pu) ⋅ D ⋅ SymGrad(Pu))

and the surface load as

f = ∫(Pu ⋅ [1.0, 0.0, 0.0], Γ="right")

rather than calling a dedicated elasticity assembly routine.

Originally, I considered this mainly an abstraction/readability feature. I expected the more general operator-based formulation to come with some performance cost.

After working on the assembly implementation — particularly direct assembly into a precomputed CSC sparsity pattern and multithreading — that is no longer necessarily the case.

In a small 3D elasticity example on my machine:

• problem-specific high-level solve: 323 ms, 299 MiB
• operator/weak-form solve: 120 ms, 52 MiB

Even the stress recovery can be written directly as field algebra:

ε = (u ∘ ∇ + ∇ ∘ u) / 2

σ = E / (1 + ν) * (ε + ν / (1 - 2ν) * trace(ε) * I)

For this particular example, that version is also slightly faster and uses considerably less memory than the older dedicated stress routine.

I don't mean these numbers as a general benchmark — they are just one mesh and one machine. What I find interesting is that the more general formulation no longer seems to require choosing between readable mathematical notation and reasonable performance.

For me, that was an important milestone in the development of the package.

I'd be interested in what people working on FEM/PDE software think about this kind of operator-level interface, especially where you would draw the line between mathematical expressiveness and implementation transparency.

Juliacon 2026 is live, there's other channels too. Hopefully the live video stays up after the stream ends.

Principal Differential Geometric Algebra by Michael Reed is the first reference of its kind, built on rigorous category theory foundations and a full unified TensorField computational language design for differential geometry. This category theory foundation presented is a custom designed formalism for categories to specifically emphasize the existence of choice morphisms, relevant to mathematicians interested in how axiom of choice appears in class/set theory. Next, the book introduces essentials of geometric algebra as the primary basis for differential geometric algebra computational language design using Grassmann.jl library for Julia language. Developed completely from scratch, Grassmann.jl introduced many new pioneering computational language designs to enable reproducible scientific research with numerical differential geometric algebra. Building on Grassmann.jl, the Cartan.jl package is the first computational language design to pioneer a FrameBundle for the PrincipalFiber G-bundle formalism used in advanced differential geometry. Not only does Cartan.jl present a completely new programming paradigm for working with an abstract FiberBundle topology using numerical analysis, it also unifies the topological implementations of structured/unstructured finite element methods and also spectral element methods. This book emphasizes the analysis of eigen-characteristics with multilinear algebra, differential geometry, and partial differential equations. Many figures and diagrams are included, all scientifically reproducible with concise programming language. Partial differential equation examples are evaluated with boundary conditions found in the literature to help scientists and engineers validate the usefulness of the computational language design. Also included are many special/elliptic functions and appendices for basics of Julia language, the Reduce.jl package, the Fatou.jl package, and the new Unified System of Quantities (USQ) for physics units from UnitSystems.jl.

Principal Differential Geometric Algebra (Hardcover, 2025) https://www.lulu.com/shop/michael-reed/principal-differential-geometric-algebra/hardcover/product-kv6n8j8.html

Principal Differential Geometric Algebra (Paperback, 2025) https://www.lulu.com/shop/michael-reed/principal-differential-geometric-algebra/paperback/product-yvk7zqr.html

As usual, I expect a lot of harassment in the comments here on Julia reddit, since Stephen Wolfram is funding people to stalk and harass me 24/7, and the Julia community is also participating in this stalking and harassment.

Normal people don't waste their time harassing scientists on the internet.

This is an update from my previous post on a simple molecular visualizer in Julia. Now it has colors, and I can also visualize simultaneously the energies, highlighting the energy for the particular structure I'm watching. I will continue to add functionality.

I'm making a calendar thing, and i have a struct containing fields of years, months, days, etc. and I'd like to have one single addTime! method that works on any time unit. I'd like to be able to call
addTime!(callendarVar, months=10)
addTime!(callendarVar, years=5)
addTime!(callendarVar, months=10, days=20)

I've already got the logic down but i'm having trouble writing a working declaration which would allow me to use these disordered optional arguements based on their names. Any advice?

EDIT: the trick was to add a semicolon between the static arguement and the optional arguements. How i was meant to figure that out without taking a spyglass to every character in the docs - i have no idea.