4 ms·

If your non-crummy tools are so bad that C ends up eating your lunch by a factor of 100, I'm not sure that they really are non-crummy.

barrkel 16y ago
Powerful tools improve productivity because you have to do less work to get the job accomplished. But they have a reverse side: you need to be aware of how they work to use them efficiently, otherwise you'll end up with silly performance problems - e.g. I've seen naive string tokenization code that did substrings, and then deleted the matched substring from the start of the string, all in a loop. By providing the tools, it's easier to misuse them. When you have fewer tools, on the other hand, you need to think at a lower level and work more directly on the problem. You have a lot more work to do, but the probability that you're misusing the tools is smaller, because you'll be building the tools yourself, manually.
- _delirium 16y ago
  I wonder how much that actually accounts for C's generally good performance in these kinds of ad-hoc benchmarks. There's really two "low-level" things about C: 1) it's low-level in the actual language sense of being reasonably close to the metal; and 2) it has a pretty bare-bones standard library, requiring most algorithms to be hand-coded, if you don't link in a 3rd-party library. Mostly people focus on #1, but as you point out, #2 might actually be a big part of it. I don't actually mean this as a slight against C, fwiw. In some ways, coding in C feels liberating, because I'm culturally allowed to do the nasty special-case hack, instead of doing it The Right Way with the library function that checks all the edge cases and error conditions and whatever.
  - barrkel 16y ago
    On this theme, there was a kind of "code-off" between Rico Mariani (.NET performance architect at the time) and Raymond Chen (The Old New Thing blog, Windows user mode developer). Rico has a kind of index to it here: http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx http://blogs.msdn.com/ricom/archive/2005/05/10/performance-q... It was interesting to see how little Rico had to do from the start to end up with quite a performant application. Eventually Raymond started pulling ahead, but IIRC it was when he started using memory mapped files for I/O. Here's a summary at version 5 of the unmanaged code: http://blogs.msdn.com/ricom/archive/2005/05/18/419805.aspx http://blogs.msdn.com/ricom/archive/2005/05/18/419805.aspx Version Execution Time (seconds) Unmanaged v1 1.328 Unmanaged v2 0.828 Unmanaged v3 0.343 Unmanaged v4 0.187 Unmanaged v5 With Bug 0.296 Unmanaged v5 Corrected 0.124 Unoptimized Managed port of v1 0.124 It was quite interesting.
- deleted 16y ago
  [deleted]
- JoachimSchipper 16y ago
  I fully agree; the point is that, in quite a few cases, these people weren't (obviously) misusing tools. Look at the Perl code - it's readable, uses a well-tested library, and is ridiculously slow.

barrkel 16y ago

Powerful tools improve productivity because you have to do less work to get the job accomplished. But they have a reverse side: you need to be aware of how they work to use them efficiently, otherwise you'll end up with silly performance problems - e.g. I've seen naive string tokenization code that did substrings, and then deleted the matched substring from the start of the string, all in a loop. By providing the tools, it's easier to misuse them. When you have fewer tools, on the other hand, you need to think at a lower level and work more directly on the problem. You have a lot more work to do, but the probability that you're misusing the tools is smaller, because you'll be building the tools yourself, manually.

_delirium 16y ago
I wonder how much that actually accounts for C's generally good performance in these kinds of ad-hoc benchmarks. There's really two "low-level" things about C: 1) it's low-level in the actual language sense of being reasonably close to the metal; and 2) it has a pretty bare-bones standard library, requiring most algorithms to be hand-coded, if you don't link in a 3rd-party library. Mostly people focus on #1, but as you point out, #2 might actually be a big part of it. I don't actually mean this as a slight against C, fwiw. In some ways, coding in C feels liberating, because I'm culturally allowed to do the nasty special-case hack, instead of doing it The Right Way with the library function that checks all the edge cases and error conditions and whatever.
- barrkel 16y ago
  On this theme, there was a kind of "code-off" between Rico Mariani (.NET performance architect at the time) and Raymond Chen (The Old New Thing blog, Windows user mode developer). Rico has a kind of index to it here: http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx http://blogs.msdn.com/ricom/archive/2005/05/10/performance-q... It was interesting to see how little Rico had to do from the start to end up with quite a performant application. Eventually Raymond started pulling ahead, but IIRC it was when he started using memory mapped files for I/O. Here's a summary at version 5 of the unmanaged code: http://blogs.msdn.com/ricom/archive/2005/05/18/419805.aspx http://blogs.msdn.com/ricom/archive/2005/05/18/419805.aspx Version Execution Time (seconds) Unmanaged v1 1.328 Unmanaged v2 0.828 Unmanaged v3 0.343 Unmanaged v4 0.187 Unmanaged v5 With Bug 0.296 Unmanaged v5 Corrected 0.124 Unoptimized Managed port of v1 0.124 It was quite interesting.
deleted 16y ago
[deleted]
JoachimSchipper 16y ago
I fully agree; the point is that, in quite a few cases, these people weren't (obviously) misusing tools. Look at the Perl code - it's readable, uses a well-tested library, and is ridiculously slow.