u/melevy

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.

Hello,

I made an open source project called LOTI.

The idea is to have a cheap distributed way for people to create verifiable timestamps and event ordering without depending on a central service.

The way it works is participants build a hash-linked history of events, so later they can query when something happened and what happened before or after it.

I originally started working on this because I was interested in the problem of proving the history of digital events. It could be useful for things like document provenance, legal disputes, audit logs, or any situation where you want a proof of the time boundaries or the frontier l definite order of digital events according to your own clock.

It's still an early project and I'm mostly looking for feedback. The project already contains an implementation in a wisely used communication network simulator and also a real world implementation. The kernel was written by me 8 years ago, the rest is created using agentic engineering very recently.

The most interesting part, where feedback would be most valuable, is how the event chain discovery can be implemented in a fast, efficient and cheap way. The difficulty lies in the evolving nature of the network topology (neighbors come and go) and the time dependent routing during discovery for events in the past.

The project is here:

https://levy.github.io/loti

Thank you!

This project of mine was dormant for like 8 years, but now that we have vibe coding I gave it a shot. Of course, I know vibe coding is bad 😉 but I also have a family, so...

I'm aware that there like several dozens of other ways in crypto land to do this somewhat differently, nevertheless I still made this. It took two weekends and a few dozen prompts to make it work both in a network simulator and using a command line program and a daemon. The most important parts were written by me back in 2018.

I'm not sure what I want to do with this. It's just a toy work in-progress project that I thought may be interesting.

The GitHub link is on the page.

Happy hacking!

Ez a projekt kb. 8 éve fekszik a a fiókomban. Gondoltam kicsit megtolom az AI-al a hétvégén. Tudom vibe-coding is bad meg minden... Na de na, család is van a világon és most volt rá lehetőség. 😉

http://levy.github.io/loti

So this is work in progress... Comments are welcomed!