3 ms·
When have you ever had the C runtime be the cause of a performance problem?
by Veedrac 10y ago
When have you ever had the C runtime be the cause of a performance problem?
- adrianN 10y agoWriting a custom replacement for malloc is relatively common. Does that count?
- zzalpha 10y agoWriting a custom replacement for malloc is relatively common. You... can't be serious. That's common to you?
- adrianN 10y agoYes? From the Wikipedia: "Because malloc and its relatives can have a strong impact on the performance of a program, it is not uncommon to override the functions for a specific application by custom implementations that are optimized for application's allocation patterns."
- zzalpha 10y ago"not uncommon" is far far from "common". If you're writing your own malloc replacement you're pretty deep into the weeds of high performance computing. Heck even just deciding to replace the stock implementation with an off-the-shelf replacement puts you in fairly rarified company. I'd wager the vast majority of software written for Linux makes use of the standard glibc allocator. I expect high performance games are the most common exception, but they represent a fraction of the C/C++ in the wild. Space leaks in Haskell, on the other hand, are unfortunately relatively easy to introduce.
- Veedrac 10y agoI don't see why not, though I wouldn't consider that to be an example of a difficult to diagnose problem in the same vein as lazy evaluation.
- eximius 10y agoI have not because I don't write C professionally. We generally have things that require algorithmic improvements due to the scale - language doesn't matter. C's model requires you to understand the machine model. Haskell presumably requires you to understand the machine model (but less thoroughly) but understand the compiler's model also. It's a little more but comparable. So complaining only about the Haskell runtime just seems ironic to me.