5 ms·

>Whereas C was from the onset one of the fastest or THE fastest language on any machine. You can't write performance critical code in C. C is great for high le

>Whereas C was from the onset one of the fastest or THE fastest language on any machine. You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly.

jamesaguilar 13y ago
True. The Linux kernel and most image processing libraries are written in assembly, after all. Actually, assembly will generally not give you much of a speedup over c. The exception is when you use assembly only features like vectorization in ways that compilers can't figure out.
codygman 13y ago
Well, actually there is no alternative to machine code: http://www.setec.org/mel.txt http://www.setec.org/mel.txt
coldtea 13y ago
>You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly. That statement makes no sense. Of course you can write performance critical code in C. People write all kinds of performance critical code in C. Heck, kernels are written in C. What's more "performance critical" than a kernel? Ray traycers are written in C. Real time systems are written in C. Servers are written in C. Databases are written in C. Socket libraries. Multimedia mangling apps like Premiere are written in C (or C++). Scientific number crunching libraries for huge datasets are written in C (and/or Fortran). The kind of "performance critical code" you have to write in assembly is a negligible part of overall performance critical code. And the speed benefit is not even that impressive.
- spc476 13y ago
  That's true now (and perhaps has been true for easily the past fifteen years). But up til the early-to-mid-90s, it was relatively easy for a decent assembly language programmer to beat a C compiler. In fact, it wasn't until the early mid-90s that general purpose CPUs broke 100MHz. Just be very thankful you don't have to deal with C compilers under MS-DOS what with the tiny, small, medium, compact, large and huge memory models (I think that's all of them).
  - ygra 13y ago
    Even now performance-critical code is assembly. Just take a look at your libc's memcpy implementation, for example. Most likely there's a default C implementation that is reasonably fast and a bunch of assembly versions for individual architectures.
    - coldtea 13y ago
      >Even now performance-critical code is assembly. The problem I have with this statement is that it implies other code, like the kernel, a ray-tracer, video editor, number crunching etc, stuff usually done in C/C++, are not "performance critical". Let's call what you describe "extremely performance critical" if you wish. With that said, MOST performance critical code is written in C/C++. Code that's not that much performance critical is written in whatever.

jamesaguilar 13y ago

True. The Linux kernel and most image processing libraries are written in assembly, after all. Actually, assembly will generally not give you much of a speedup over c. The exception is when you use assembly only features like vectorization in ways that compilers can't figure out.

codygman 13y ago

Well, actually there is no alternative to machine code: http://www.setec.org/mel.txt http://www.setec.org/mel.txt

coldtea 13y ago

>You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly. That statement makes no sense. Of course you can write performance critical code in C. People write all kinds of performance critical code in C. Heck, kernels are written in C. What's more "performance critical" than a kernel? Ray traycers are written in C. Real time systems are written in C. Servers are written in C. Databases are written in C. Socket libraries. Multimedia mangling apps like Premiere are written in C (or C++). Scientific number crunching libraries for huge datasets are written in C (and/or Fortran). The kind of "performance critical code" you have to write in assembly is a negligible part of overall performance critical code. And the speed benefit is not even that impressive.

spc476 13y ago
That's true now (and perhaps has been true for easily the past fifteen years). But up til the early-to-mid-90s, it was relatively easy for a decent assembly language programmer to beat a C compiler. In fact, it wasn't until the early mid-90s that general purpose CPUs broke 100MHz. Just be very thankful you don't have to deal with C compilers under MS-DOS what with the tiny, small, medium, compact, large and huge memory models (I think that's all of them).
- ygra 13y ago
  Even now performance-critical code is assembly. Just take a look at your libc's memcpy implementation, for example. Most likely there's a default C implementation that is reasonably fast and a bunch of assembly versions for individual architectures.
  - coldtea 13y ago
    >Even now performance-critical code is assembly. The problem I have with this statement is that it implies other code, like the kernel, a ray-tracer, video editor, number crunching etc, stuff usually done in C/C++, are not "performance critical". Let's call what you describe "extremely performance critical" if you wish. With that said, MOST performance critical code is written in C/C++. Code that's not that much performance critical is written in whatever.