3 ms·

If C did not exist, it would be necessary to invent it. There is CPU-bound code out there, where every cycle saved in an inner loop equates to hours of improve

If C did not exist, it would be necessary to invent it. There is CPU-bound code out there, where every cycle saved in an inner loop equates to hours of improved runtime or thousands of additional client transactions/second. Safer languages have made great strides in the kinds of dynamic profiling and optimization that can equal the performance of optimized C/C++, but there remain real penalties in startup and profiling time.

oofabz 13y ago
How about Ocaml or Rust? They are both safer than C and are almost as fast. I don't think we'd reinvent C on modern machines, which have millions of times more memory than K&R had to work with on their PDP-7.
habitue 13y ago
I think some things like null terminated strings etc are not inevitable in a fast language like C. There were definitely design mistakes that cost security and don't directly affect performance significantly.
- Scaevolus 13y ago
  It affects performance more on old, register poor, slow CPUs. Memory latency dominates processing time now, but it used to be a real issue.
  - pjmlp 13y ago
    Sure, but we always had the option to switch off bound checking on the code spots where it really made a difference.
- _delirium 13y ago
  If anything, null-terminated strings are bad for performance as often as good for it. One example that comes up reasonably often: comparing strings that have different lengths but common prefixes is fast with length-tagged (Pascal-style) strings, but expensive with C-style strings, because you have to scan both strings until you find either a string end, or a difference. So instead of quickly answering "not equal" after one integer comparison, you could end up doing hundreds (or thousands) of byte comparisons in degenerate cases. Anything that calls strlen() also ends up doing extra work.
  - adobriyan 13y ago
    Well, as far as kernel is concerned strings aren't a problem. Outside VFS they don't exist. Inside VFS everything is chopped into usually short pathname components which are hashed for dcache consumption. On x86_64 hashing is not byte-by-byte anymore. Fixing pathetic macro system and type system (if that qualifies at all) would get rid of many many bugs.
pjmlp 13y ago
You just made me smile. I have done systems programming in Assembly, BASIC dialects, Pascal dialects, Modula-2, Ada, Oberon, without writing a single line of C. There was a time C was confined to UNIX System V at some university labs and the world at large had other sytems languages to choose from. Interest in C raised, because we wanted to have at home some kind of compiler for homework and while at the same time UNIX variants started to spread into the industry. I know kids these days, raised in the VM golden age, think many of the current language features are only possible in a VM based environment, it wasn't like that 20 years ago. There are hardly any feature ANSI/ISO C has over other systems languages, other than having 30+ years of investment into compiler backends and complaining other languages tend to be a bit more verbose.
tokenrove 13y ago
There were systems languages before C, and there will be systems languages after it. Saving a cycle or two is not the strong point of C, either.

oofabz 13y ago

How about Ocaml or Rust? They are both safer than C and are almost as fast. I don't think we'd reinvent C on modern machines, which have millions of times more memory than K&R had to work with on their PDP-7.

habitue 13y ago

I think some things like null terminated strings etc are not inevitable in a fast language like C. There were definitely design mistakes that cost security and don't directly affect performance significantly.

Scaevolus 13y ago
It affects performance more on old, register poor, slow CPUs. Memory latency dominates processing time now, but it used to be a real issue.
- pjmlp 13y ago
  Sure, but we always had the option to switch off bound checking on the code spots where it really made a difference.
_delirium 13y ago
If anything, null-terminated strings are bad for performance as often as good for it. One example that comes up reasonably often: comparing strings that have different lengths but common prefixes is fast with length-tagged (Pascal-style) strings, but expensive with C-style strings, because you have to scan both strings until you find either a string end, or a difference. So instead of quickly answering "not equal" after one integer comparison, you could end up doing hundreds (or thousands) of byte comparisons in degenerate cases. Anything that calls strlen() also ends up doing extra work.
- adobriyan 13y ago
  Well, as far as kernel is concerned strings aren't a problem. Outside VFS they don't exist. Inside VFS everything is chopped into usually short pathname components which are hashed for dcache consumption. On x86_64 hashing is not byte-by-byte anymore. Fixing pathetic macro system and type system (if that qualifies at all) would get rid of many many bugs.

pjmlp 13y ago

You just made me smile. I have done systems programming in Assembly, BASIC dialects, Pascal dialects, Modula-2, Ada, Oberon, without writing a single line of C. There was a time C was confined to UNIX System V at some university labs and the world at large had other sytems languages to choose from. Interest in C raised, because we wanted to have at home some kind of compiler for homework and while at the same time UNIX variants started to spread into the industry. I know kids these days, raised in the VM golden age, think many of the current language features are only possible in a VM based environment, it wasn't like that 20 years ago. There are hardly any feature ANSI/ISO C has over other systems languages, other than having 30+ years of investment into compiler backends and complaining other languages tend to be a bit more verbose.

tokenrove 13y ago

There were systems languages before C, and there will be systems languages after it. Saving a cycle or two is not the strong point of C, either.