4 ms·

Most of this impression is usually caused by the combination of the following things: * fast startup * programs in C usually do much less with more code than

Most of this impression is usually caused by the combination of the following things: * fast startup * programs in C usually do much less with more code than high level languages Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages (e.g. dynamic dispatch tends to be slower in C than in C++ or Java).

deeviant 13y ago
Dynamic dispatch in C? There is none. There bigger a project is, the more stuff it does. If a language does this stuff slow(aka ruby), then it will not run faster no matter what buzz words you invoke.
- mtdewcmu 13y ago
  Yeah... C's dynamic dispatch can be slow or fast. It's up to you, because you get to write it yourself.
  - pkolaczk 13y ago
    It can't be as fast as in VM-based languages, because the code (typically) can't self-optimize / modify itself according to the usage patterns to inline dynamic calls. This is the stuff that VM can do, because it has much more information. This is one of the reasons a general sorting method like qsort is so slow in C compared to general sorting method in Java (Collections.sort). Sure, you can specialize manually or do some macros, but such manual approach gets hairy pretty quickly for something more complex than a simple sorting method.
    - mcguire 13y ago
      I keep hearing this, but I have not ever seen it. Do you have a specific citation?
    - mtdewcmu 13y ago
      There is a theoretical benefit in being able to optimize at runtime. But, in practice, these advantages are virtually always too small to outperform code compiled statically.
      - pkolaczk 13y ago
        This is not a theoretical benefit - it is a very practical benefit, especially for object-oriented code with lots of indirection, virtual calls and dynamically loaded code. The reason it is not visible in microbenchmarks is because microbenchmarks are small and usually avoid indirection as much as possible, and even if there exist some, the code is all in one file so a static compiler can figure out all the call targets properly.
    - mtdewcmu 13y ago
      std::sort in C++ is known to be faster than qsort() in standard C, because C++ templates allow the comparison function to be inlined. I find it doubtful, though, that Java has a generic sort method that regularly outperforms qsort.
      - pkolaczk 13y ago
        I measured Collections.sort and it was ver close to C++ std:sort in performance, while C qsort was about 10x slower. It outperforms qsort for the same reason C++ does it - the call to comparison function is inlined.
mtdewcmu 13y ago
>>fast startup That's a real improvement. >>programs in C usually do much less with more code than high level languages Ok. So? >>Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages True. The speed boost isn't automatic. It's up to the programmer to write fast code. I have nothing against high-level languages and garbage collection. They certainly have a place. But if you use high-level languages exclusively, you'll never (or rarely) have the special joy of seeing your program run at the full speed of the hardware.

deeviant 13y ago

Dynamic dispatch in C? There is none. There bigger a project is, the more stuff it does. If a language does this stuff slow(aka ruby), then it will not run faster no matter what buzz words you invoke.

mtdewcmu 13y ago
Yeah... C's dynamic dispatch can be slow or fast. It's up to you, because you get to write it yourself.
- pkolaczk 13y ago
  It can't be as fast as in VM-based languages, because the code (typically) can't self-optimize / modify itself according to the usage patterns to inline dynamic calls. This is the stuff that VM can do, because it has much more information. This is one of the reasons a general sorting method like qsort is so slow in C compared to general sorting method in Java (Collections.sort). Sure, you can specialize manually or do some macros, but such manual approach gets hairy pretty quickly for something more complex than a simple sorting method.
  - mcguire 13y ago
    I keep hearing this, but I have not ever seen it. Do you have a specific citation?
  - mtdewcmu 13y ago
    There is a theoretical benefit in being able to optimize at runtime. But, in practice, these advantages are virtually always too small to outperform code compiled statically.
    - pkolaczk 13y ago
      This is not a theoretical benefit - it is a very practical benefit, especially for object-oriented code with lots of indirection, virtual calls and dynamically loaded code. The reason it is not visible in microbenchmarks is because microbenchmarks are small and usually avoid indirection as much as possible, and even if there exist some, the code is all in one file so a static compiler can figure out all the call targets properly.
  - mtdewcmu 13y ago
    std::sort in C++ is known to be faster than qsort() in standard C, because C++ templates allow the comparison function to be inlined. I find it doubtful, though, that Java has a generic sort method that regularly outperforms qsort.
    - pkolaczk 13y ago
      I measured Collections.sort and it was ver close to C++ std:sort in performance, while C qsort was about 10x slower. It outperforms qsort for the same reason C++ does it - the call to comparison function is inlined.

mtdewcmu 13y ago

>>fast startup That's a real improvement. >>programs in C usually do much less with more code than high level languages Ok. So? >>Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages True. The speed boost isn't automatic. It's up to the programmer to write fast code. I have nothing against high-level languages and garbage collection. They certainly have a place. But if you use high-level languages exclusively, you'll never (or rarely) have the special joy of seeing your program run at the full speed of the hardware.