celrod

EXWM is ;). I used it for about a year, but ultimately found the performance, and in particular a low language server locking up the window manager, unacceptable.

I'm still waiting for clangd support, e.g. [0] before trying modules. But maybe I should just try it, as at least one person reports that it already works [1].

[0] https://github.com/clangd/clangd/issues/1293 [1] https://github.com/snu-sf-class/swpp202401/issues/21

What's the trick with explicit template instantiations? Including them in the precompiled header?

If using cmake, you can try a unity build. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.htm...

You can also specify a `-DUNITY_BUILD_BATCH_SIZE` to control how many get grouped, so you can still get some parallelism. However, I think it'd be more natural to be able to specify number of batches (e.g. `nproc`) than their size.

Code bases may need some updating to work.

FWIW, that synthetic benchmark was reflective of some real world code we were deploying. Using malloc/free for one function led to something like a 2x performance improvement of the whole program.

I think it's important to differentiate between malloc implementations/algorithms, just like it's important to differentiate between GCs. E.g., mimalloc "shards" size classes into pages, with separate free lists per page. This way, subsequent allocations are all from the same page. Freeing does not free eagerly; only if the entire page is freed, or if we hit a new allocation and the page is empty, then it can hit a periodic slow path to do deferred work. https://www.microsoft.com/en-us/research/uploads/prod/2019/0...

Good malloc implementations can also employ techniques to avoid fragmentation. It's unfortunate that the defaults are bad.

But I confess, compacting GCs and profiling the effects of heap fragmentation (especially over time in long running programs) are both things I lack experience in. Microbenchmarks are unlikely to capture that accurately.

The RCU use case is convincing, but my experience with GCs in other situations has been poor. To me, this reads more like an argument for bespoke memory management solutions being able to yield the best performance (I agree!), which is a totally different case from the more general static lifetimes generally outperforming dynamic lifetimes (especially when a tracing step is needed to determine liveness).

> Lies people believe... Calling free() gives the memory back to the OS.

I believe calling `free()` gives the memory back to the allocator, which is much better than giving it to the OS; syscalls are slow. Perhaps not immediately; mimalloc only makes frees available to future `malloc`s periodically.

Trying a simple benchmark where I allocate and then immediately `free` 800 bytes, 1 million times, and counting the number of unique pointers I get: glibc's malloc: 1 jemalloc: 1 mimalloc: 4 Julia's garbage collector: 62767

62767, at about 48 MiB, isn't that bad, but it still blows out my computer's L3 cache. Using a GC basically guarantees every new allocation is from RAM, rather than cache. This kills performance of any heavily allocating code; we don't care only about how fast memory management can work, but how quickly we can worth with what it gives us. I gave a benchmark in Julia showcasing this: https://discourse.julialang.org/t/blog-post-rust-vs-julia-in...

Malloc/free gives you a chance at staying hot, if your actual working memory is small enough.

Allocators like mimalloc are also designed (like the compacting GC) to have successive allocations be close together. The 4 unique pointers I got from mimalloc were 896 bytes apart.

My opinions might be less sour if I had more experience with compacting GCs, but I think GCs are just a vastly more complicated solution to the problem of safe memory management than something like Rust's borrow checker. Given that the complexity is foisted on the compiler and runtime developers, that's normally not so bad for users, and an acceptable tradeoff when writing code that isn't performance sensitive. Similarly, RAII with static lifetimes is also a reasonable tradeoff for code not important enough for more bespoke approaches. The articles example is evidently one of those deserving a more bespoke solution.

> As pressure from thread collisions increases, additional arenas are created via mmap to relieve the pressure. The number of arenas is capped at eight times the number of CPUs in the system (unless the user specifies otherwise, see mallopt), which means a heavily threaded application will still see some contention, but the trade-off is that there will be less fragmentation.

https://sourceware.org/glibc/wiki/MallocInternals

So glibc's malloc will use up to 8x #CPUs arenas. If you have 10_000 threads, there is likely to be contention.

Knights featured AVX512F and were best at heavily SIMD workloads. Sierra Forrest is bad at these jobs of workloads, lacking AVX512 and having only 16 byte execution units, so their AVX(2) throughput is also poor.

They're thus going after a very different market.

Too bad Julia doesn't have this theoretical "well written GC". I do not like GCs, so I agree with OP's sentiment. Why solve such a hard problem when you don't have to?

I don't find ownership models that difficult. It's things one should be thinking of anyway. I think this provides a good example of where stricter checking/an ownership model like Rust has makes it easier than languages that do not have it (in this case, C++): https://blog.dureuill.net/articles/too-dangerous-cpp/

I don't think these are realistic. It does far worse than MKL in practice on Intel CPUs in my tests, especially if arrays are not huge.

I would love to see a Snapdragon Elite X in a Framework.

To be clear, this doesn't mean this scheduler itself runs faster. It means that the scheduler algorithm is better suited for gaming workloads, allocating your hardware more effectively.

Of course, if the scheduler ran much slower so your CPU spends more time on the scheduler than time saved through better resource allocation, then it wouldn't help performance. But that's hopefully not a major factor here.

Chimera uses the scudo allocator, which is Ajay also the default on Android and Fuscia.

Yet I can't find many benchmarks.

Frustratingly, it's listed here, but not actually included in the results: https://github.com/daanx/mimalloc-bench Might be fun trying to run the benchmarks myself.

And only need it to compile to webassembly.

If my signed integers overflow, that is wrong. I want to be able to detect if it ever happens, not have that be defined as perfectly valid wrapping behavior. If it's undefined, it's perfectly legal for the compiler to make overflow trap, so I can catch it, or confirm it never happens when running tests our debugging. `-ftrapv` or ``-fsanitize=undefined` do this.

`std::popcount` was added to the stl in C++20 https://en.cppreference.com/w/cpp/numeric/popcount

Yes, just because you see SIMD instructions doesn't mean the code is fast. You need the correct instructions.

Not relevant to this example, which is `popcount`ing only a single number, but AVX512 did also introduce SIMD popcount instructions for getting many inputs at a time. Also true for other useful bit-funs like leading or trailing zeros. So if you're using zmm registers, you can do way better than that godbolt example.

Another comment cited this Dan Luu article: https://danluu.com/keyboard-v-mouse/

Apparently a lot more claiming evidence exists than sharing of actual evidence. One of the few things shared was a pseudoscientific explanation that stated precisely the opposite of your (and my) subjective experience: That using the mouse is less distracting and can be better committed to muscle memory than "command keys".

I think that is patently false, and don't thing Tog should be taken as anything but a marketing hack.

Disclaimer: my knowledge of Tog is limited to what is presented in that Dan Luu article.

I have never seen him speak, but odd that an example of him faking it is supposed to make him seem genuine?

Depending on which STL you use, there may also be assertions you can enable, e.g. via defining _GLIBCXX_ASSERTIONS https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...

https://www.anandtech.com/show/21112/qualcomm-snapdragon-x-e... Qualcomm's upcoming Nuvia chips apparently do quite well on geekbench also (but unlike the 7945hx3d, aren't yet available).

If any of my family members are secretly killers, I would not feel bad about them getting caught...

But I would feel bad if, e.g., insurance premiums were to go up because I had inherited risk factors for some costly diseases.

I like integer overflow being UB. Makes it easier to check for by enabling a sanitizer. With it being defined as wrapping, it would be illegal for overflow to cause a runtime trap. Of course, rust mandates the trap on debug builds, which is a fine approach too.

I tried gcc, clang, msvc, and icc. They all generated the load and either an add or an inc. https://godbolt.org/z/han78n9zM If we define `f` to const_cast away the const and add 10: https://godbolt.org/z/1dso8ojWG all the compilers agree that we should get 53. However, make `y` const, so we have

  const int y = 42;
  const int x = y;

and now modifying x suddenly becomes undefined behavior, and x + 1 returns 43 https://godbolt.org/z/cqbGasrMM Similar to how the original assembly showed making `y` const removed the reload and increment/+1 of x.

So, it seems that all these compilers agree that modifying `x` is undefined behavior if `y` is const, but is defined if `y` is mutable.

I am not sure why this is.

I may have misunderstood, but I didn't get the impression this should be the case from reading: https://en.cppreference.com/w/cpp/language/cv

My best guess is that for some reason, `x` is a constant object only if initialized itself via a constant object. But I couldn't find anything saying that is the case. I asked on the #learn channel of cppslack.

Unfortunately, `x` does escape, merely because we initialized it via assigning to it from a non-const.

I edited to add a godbolt link, but repeating here: https://godbolt.org/z/7vre49xb1

In my example, even though `x` is a `const` local, the assembly still shows that it reloads `x` and adds `1` if we assign to it from a non-const local `y`.

It's unfortunately easy to defeat this, e.g.

  int y = 42;
  const int x = y;

is enough, even though `x` is still a `const` local variable.

https://godbolt.org/z/7vre49xb1

[Deleted - responded to the wrong comment. I meant to respond to IAmLiteralyAB.]

We supposedly consume about 100 watts at rest. Given that my flops are low (less than one!), I don't think I'm an efficient processor. At least for floating point operations. Producing paper and ink cartridges isn't free, either.

I might be competitive with an LLM + GPUs, but I imagine it'll demolish me on throughput.

Emacs-eat is supposed to work on windows, and may give you a faster e-shell.

Note that you can use things like `pcomplete` and `eshell-syntax-highlighting` to make eshell fairly smart. The fact that my shell can use corfu and the same completion, filtering, and ordering as the rest of my emacs is great.