4 ms·
I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which
by eximius 10y ago
I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime.
I am not experienced enough with Haskell to know whether peeking under its hood involves a more complicated model or not. It might be more frustrating. But its certainly not a unique experience - it's costs are just less distributed over other runtimes.
- restalis 10y ago"we're just more comfortable with the relatively common and direct mapping of the C runtime" That's a funny way to put it. It's more like the difference between getting results or abandoning the thing altogether due to exploding cost of required effort.
- user5994461 10y agoThe C is very straightforward. Maybe you meant C++? You see no complaint because noone use that anymore. Anything that can be done with an easier language is done with an easier language. The hardcore C++ performance critical code is left to a few veterans, who don't complain.
- eximius 10y agoI don't consider the combination of the C runtime + the machine model straightforward - just less arcane than C++. Consider pipelines and branch prediction and cache lines and it quickly becomes difficult. Granted, those typically become relevant later in the optimization stage than other things.
- Veedrac 10y agoPipelines, branch prediction and caching are not part of the C runtime. And unlike Haskell, C makes it easy to look at the assembly for a piece of code, evaluate it for the machine it's running on, and fix these problems when they come up. C is not generally adding additional burdens, especially not ones that a higher-level language like Haskell won't also be adding to a far greater degree.
- Veedrac 10y agoWhen 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.