> While nuclear fusion power is often hailed as a future source of abundant, clean energy, current dominant fusion designs, magnetic and laser inertial, are unlikely to become competitive due to their expected low experience rates. Accordingly, policymakers should not rely on, or fund, fusion power as a core pillar of future clean energy systems unless designs with different characteristics are developed.

https://tailscale.com/docs/features/client/linux-systray

1. tcmalloc is actually the only allocator I tested which was not using thread local caches. even glibc malloc has tcache.

2. async executors typically shouldn’t have tasks jumping willy nilly between threads. i see the issue u describe more often with the use of thread pools (like rayon or tokio’s spawn_blocking). i’d argue that the use of thread pools isn’t necessarily an inherent feature of async executors. certainly tokio relies on its threadpool for fs operations, but io-uring (for example) makes that mostly unnecessary.

tokio scheduler side, the executor is thread per core and work stealing of in progress tasks shouldn't be happening too much.

for all thread pool threads or threads unaffiliated with the executor, see earlier speculation on OS scheduler behavior.

[0]: https://github.com/google/tcmalloc/blob/master/docs/design.m...

Our results from July 2025:

rows are : ,

  app1:
  glibc: 215,580 KB, 133 ms
  mimalloc 2.1.7: 144,092 KB, 91 ms
  mimalloc 2.2.4: 173,240 KB, 280 ms
  tcmalloc: 138,496 KB, 96 ms
  jemalloc: 147,408 KB, 92 ms

  app2, bench1
  glibc: 1,165,000 KB, 1.4 s
  mimalloc 2.1.7: 1,072,000 KB, 5.1 s
  mimalloc 2.2.4:
  tcmalloc: 1,023,000 KB, 530 ms

  app2, bench2
  glibc: 1,190,224 KB, 1.5 s
  mimalloc 2.1.7: 1,128,328 KB, 5.3 s
  mimalloc 2.2.4: 1,657,600 KB, 3.7 s
  tcmalloc: 1,045,968 KB, 640 ms
  jemalloc: 1,210,000 KB, 1.1 s

  app3
  glibc: 284,616 KB, 440 ms
  mimalloc 2.1.7: 246,216 KB, 250 ms
  mimalloc 2.2.4: 325,184 KB, 290 ms
  tcmalloc: 178,688 KB, 200 ms
  jemalloc: 264,688 KB, 230 ms

i don't recall which jemalloc was tested.

If you're willing to dive right into it, I'd first read a bit about the comptime system [0] then have a go at reading the source for `MultiArrayList` [1], a container which internally stores elements in SoA format.

At least, that was what got me interested.

[0]: https://ziglang.org/documentation/master/#comptime

[1]: https://codeberg.org/ziglang/zig/src/branch/master/lib/std/m...

I noticed the following comment was added to lib/std/multi_array_list.zig [0] with this change:

        /// This pointer is always aligned to the boundary `sizes.big_align`; this is not specified
        /// in the type to avoid `MultiArrayList(T)` depending on the alignment of `T` because this
        /// can lead to dependency loops. See `allocatedBytes` which `@alignCast`s this pointer to
        /// the correct type.

[0]: https://codeberg.org/ziglang/zig/pulls/31403/files#diff-a6fc...

I took a look at the docs later and couldn’t find a direct comparison. But there does seem to be a remote build system. And there were a few mentions of sandboxing.

Can anyone provide a head to head comparison?

Does xmake strictly enforce declared dependencies? Do actions run in their own sandboxes?

Can you define a target whose dependency tree is multi language, multi toolchain, multi target platform and which is built across multiple remote execution servers?

See DGX Spark.

As a side benefit, the generated docker image can be very tiny.