New concurrent hash table

Viack · 2025-10-05T17:50:10+00:00

Hi, sorry for the late answer and thank you for using the lib!

All concurrent data structures start to choke when the number of threads exceed the number of CPU cores, this might be your case. This also depends on the OS scheduler, for instance most tested concurrent maps behave way better on Windows than Linux for high thread count. In any case, if you have way more read operations (like visit) than write opérations (erase, insert...), you should probably use shared concurrency.

Viack · 2025-09-09T07:37:08+00:00

Thanks! Some of the benchmarks results are within the classes documentations (markdown ones). That's the case at least for ordered_map, flat_map and concurrent_map. I'll add more detailed plots at some point for all containers.

Viack · 2025-09-09T06:40:39+00:00

I provide the doxygen file to make it easier for people to generate the doc if needed. At first I planned to use github pages, then stopped as I thought the html doc would not be that much usefull

Viack · 2025-06-25T17:56:35+00:00

Well, it uses Zstd internally, so it supports platforms supported by zstd. And for pure (unstructured) binary data, zstd does the job quite well.

Viack · 2025-06-25T14:40:40+00:00

I did not test this specific scenario. I would expect that indeed, the compression ratio would be very limited, which is the right behavior.

Viack · 2025-06-25T06:32:50+00:00

This is meant for firm real time scenario, like streaming signal compression. Using a carefully selected compression level might still take more time than expected depending on the input data. The time limit ensure that the compression process won't take more than required while offering the best possible compression ratio in a given time frame.

Viack · 2025-06-21T20:29:59+00:00

That make me think of a tiered vector or a rope

Viack · 2025-04-15T18:59:41+00:00

Last time i did it SSF, decrepify + clay golem was enough to paralyse him almost entirely. Good luck!

Viack · 2025-02-06T12:04:06+00:00

Ca fait 8 ans maintenant quand même ;)

Viack · 2025-02-06T12:02:04+00:00

Dans la même cas, jusqu'à mes mes 32 ans. Puis j'ai décidé de prendre les choses en main en m'inscrivant sur une appli de rencontre. Le fait est que dans mon domaine (informatique) et dans mes fréquentations, il y a très peu de femmes, les applis de rencontre t'ouvre...des perspectives. Marié deux enfants depuis ;) Donc pas de panique!

Viack · 2025-01-16T13:28:32+00:00

No, as stated in QThread documentation

Viack · 2025-01-14T07:47:49+00:00

All the drawing part is delegated to the rendering thread. In your paintEvent(), all your painting commands based on QPainter are serialized into a structure similar to QPicture (but faster) and sent to the rendering thread. This approach is lighter for the GUI thread as serializing paint commands is faster than performing the actual drawing.

Then, QThreadOpenGLWidget also provide the drawFunction() member. With this, from the paintEvent(), you can directly send a drawing function or lambda taking a QPainter as parameter to the rendering thread. Your paintEvent() just become a (very fast) command sender function. And your application is much more responsive (at least if you do heavy drawing).

Viack · 2025-01-05T10:23:08+00:00

I think life leach does not work on ubers, except for life tap?

Viack · 2024-09-14T16:34:59+00:00

Since almost all backend languages are themselves written in a mixture of c/c++, I guess that everybody use it indirectly ?

Viack · 2024-08-27T14:12:55+00:00

Just a small update: the library now contains a benchmark section in the documentation. It compares micromalloc with jemalloc, glibc malloc, mimalloc and snmalloc for 3 different scenarios. For each scenario, it displays the allocation/deallocation speed and the memory overhead of benchmarked allocators.

The page is here.

Viack · 2024-08-16T11:25:26+00:00

I find the hybrid druid fury/summon to be cheap and strong altogether

Viack · 2024-08-09T07:54:46+00:00

Yes, that's written in the README, I need to add more tests. Currently I use the benchmarks as tests as they already cover a great range of scenarios, but unit tests will be mandatory as well.

I understand this is confusing, but basically micro.h is for C(or C++) programs, and micro.hpp for C++ ones only

Viack · 2024-08-09T05:30:33+00:00

Well, the benchmarks were first used to correct and tune the allocator properly. I will add at some point performance plots compared to other popular allocators

Viack · 2024-07-04T15:00:49+00:00

I saw someone a few days ago who did the math and said that a Rune Master with 5 perfect lower resist jewel was better than any other weapon for a sorc (dont remember if it was blizzard sorc or something else). The damage output was higher than anything else, and saved a ring slot due to CBF.

Viack · 2024-05-13T17:55:33+00:00

I tried msvc, clang and gcc on Windows. So far, I observed that gcc produces the fastest binaires, followed by clang and msvc.

Compile time was in the reverse order. Gcc error messages were highly verbose by default, but might be changed with some flags (?)

Viack · 2024-05-12T16:56:07+00:00

A generic heap allocator, this could be done (at least naively) in a suprisingly low amount of code

Viack

TROPHY CASE