4 ms·
Some case might be “exceptional” in the sense that it doesn’t happen most of the time (and thus doesn’t show up on regular profile checks), but when it does hap
by lovecg 7y ago
Some case might be “exceptional” in the sense that it doesn’t happen most of the time (and thus doesn’t show up on regular profile checks), but when it does happen the failures are highly correlated and suddenly you’re throwing thousands of exceptions per second all over the place.
This is also the time one finds out that the exception handling code on typical C++ runtimes take out a global lock and the multithreaded application grinds to a halt—the raw CPU cost of an exception is not the most pressing problem at this point.
- AnimalMuppet 7y agoWait, what? An exception takes out a global lock? Do you know which runtimes do this? Or, which runtimes don't?
- gpderetta 7y agolibstc++ does. And IIRC the reason is the usual culprit: dlclose [1]. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
- BubRoss 7y agomalloc takes out a global lock and performance doesn't 'grind to a halt' from a single allocation. Hundreds of thousands of allocations per second per core and concurrency will suffer, but most programs either don't actually have nearly enough concurrency or minimize their allocations to the point where it isn't a primary bottleneck.
- throwaway17_17 7y agoI think the context you’re working in matters heavily with such an assertion. In fact, it is quite common in game development to bulk allocate and then use custom allocators within these regions specifically avoid the drag on performance and determinism inflicted by malloc.
- BubRoss 7y agoI don't think this confronts anything I said. Bulk allocations with custom allocators would either be exactly what I said (low malloc calls) or would just not use malloc at all and use the system memory mapping functions. The larger point was that an exception being thrown and taking a global lock is not going to tank performance. That would imply that all other threads are trying to take the same lock at the same time and that the thread that gets it holds it for a long time. Even in the case of malloc, where there could be actual heavy lock contention, this is not always a bottleneck.
- zabzonk 7y ago> malloc takes out a global lock Says who? The C Standard says nothing of the kind.
- BubRoss 7y agoAll modern common implementations (I think). MSVC's malloc definitely locks. I think gcc, clang and icc do too. This is a big reason why tcmalloc and jemalloc were created.
- gpderetta 7y agoI don't know about MSVC, but glibc malloc has per thread caches. At some point you need to hit the global allocator or sbrk or mmap of course and that might take a global lock.
- lovecg 7y agoOf course, it would depend on the workload. An exception here and there wouldn’t matter, but for a somewhat contrived example, using exceptions for something like a bad connection to a database on a server with dozens of threads could easily turn into a concurrency and a resource exhaustion problem (where every thread starts seeing the same error at the same time).
- jcelerier 7y ago> malloc takes out a global lock not anymore for a couple years with glibc : https://www.phoronix.com/scan.php?page=news_item&px=glibc-malloc-thread-cache https://www.phoronix.com/scan.php?page=news_item&px=glibc-ma...