5 ms·

> C has no complex data structures like hashes, trees, or linked lists, and should the programmer require them, they are expected to implement their own. This p

> C has no complex data structures like hashes, trees, or linked lists, and should the programmer require them, they are expected to implement their own. This provides more granular control over the code, as the programmer can tweak the details of the implementation as needed for efficiency. It's absolutely possible to roll your own data structures, even if the language provides its own implementations. Some use their own hash map instead of std::unordered_map/set in C++, and some use hash maps specialised for primitive types in Java (as the generic HashMap boxes). (On the contrary: do people roll good implementations of data structures usually?) > As explained in this Reddit thread, mouse lag is likely because the interrupt handler allocates memory that triggers garbage collection. The Biscuit paper states "the longest single GC-related pause suffered by NGINX was 115 microseconds"; I'm not sure how well that generalises to other workloads, but (infrequent already) pauses would be hard to notice if that does generalise.

e63f67dd-065b 3y ago
> On the contrary: do people roll good implementations of data structures usually? In high-level languages, my general observation is that hand-rolled data structures can be divided into two kinds: the kind written by somebody who has no clue what they're doing, and the kind written by a data structures wizard that leaves you in awe about the details. The most notable example of I've seen of the latter kind was in some read-optimised database where they wrote a cache that linearly scales with the number of readers almost infinitely -- some black magic with maintaining two copies of a map, and having each reader go through completely wait-free paths and switching maps on writes so they never interfere, whilst sharing the underlying storage to not make writes completely inefficient. Stuff like this just makes admire the crazy things that are possible. Then you have the crappy linked list implementation #82432 that segfaults it you look at it funny. > The Biscuit paper states "the longest single GC-related pause suffered by NGINX was 115 microseconds"; I'm not sure how well that generalises to other workloads, but (infrequent already) pauses would be hard to notice if that does generalise > The collector suspends ordinary execution on all cores (a “stop-the-world” pause) twice during a collection: at the beginning to enable the write barrier on all cores and at the end to check that all objects have been marked. These stop-the-world pauses typically last dozens of microseconds Yeah that certainly seems to be the case, for interactive use, I find it hard to believe that anything less than a few ms will cause issues, and that's 3 orders of magnitude more than what biscuit found. Although I do wonder if there are GC concerns elsewhere -- these are just vague memories, but I believe that the Go GC is pretty conservative and will not reap anything that looks like a pointer, so there might be concerns around leaks especially with all the special pcie registers, dma buffers, etc that might be lying around in memory.
- hayley-patton 3y ago
  The Go GC is precise nowadays. But there's also a kind of semi-conservative GC which can identify pointers/not-pointers in the heap, but not the stack; apparently Go 1.0 was fully conservative, 1.1-1.2 were semi-conservative, and 1.3 and on are precise.

e63f67dd-065b 3y ago

> On the contrary: do people roll good implementations of data structures usually? In high-level languages, my general observation is that hand-rolled data structures can be divided into two kinds: the kind written by somebody who has no clue what they're doing, and the kind written by a data structures wizard that leaves you in awe about the details. The most notable example of I've seen of the latter kind was in some read-optimised database where they wrote a cache that linearly scales with the number of readers almost infinitely -- some black magic with maintaining two copies of a map, and having each reader go through completely wait-free paths and switching maps on writes so they never interfere, whilst sharing the underlying storage to not make writes completely inefficient. Stuff like this just makes admire the crazy things that are possible. Then you have the crappy linked list implementation #82432 that segfaults it you look at it funny. > The Biscuit paper states "the longest single GC-related pause suffered by NGINX was 115 microseconds"; I'm not sure how well that generalises to other workloads, but (infrequent already) pauses would be hard to notice if that does generalise > The collector suspends ordinary execution on all cores (a “stop-the-world” pause) twice during a collection: at the beginning to enable the write barrier on all cores and at the end to check that all objects have been marked. These stop-the-world pauses typically last dozens of microseconds Yeah that certainly seems to be the case, for interactive use, I find it hard to believe that anything less than a few ms will cause issues, and that's 3 orders of magnitude more than what biscuit found. Although I do wonder if there are GC concerns elsewhere -- these are just vague memories, but I believe that the Go GC is pretty conservative and will not reap anything that looks like a pointer, so there might be concerns around leaks especially with all the special pcie registers, dma buffers, etc that might be lying around in memory.

hayley-patton 3y ago
The Go GC is precise nowadays. But there's also a kind of semi-conservative GC which can identify pointers/not-pointers in the heap, but not the stack; apparently Go 1.0 was fully conservative, 1.1-1.2 were semi-conservative, and 1.3 and on are precise.