6 ms·

> Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C la

> Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today. Second, the relevant questions with regard to CPU performance have changed a lot. Most notably: - CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything - Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things. The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all. I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.

ori_b 7y ago
> The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: The problem with this line of argument: assembly has also not changed. If the things you talk about mattered, we would be using a different assembly.
- fctorial 7y ago
  > we would be using a different assembly. We are. It's called microcode.
  - ori_b 7y ago
    And, you write microcode?
nomel 7y ago
> CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Keeping things physically close in memory has always been a strong requirement, as long as cache, pages, and larger than one-byte-memory buses have existed.
- nickitolas 7y ago
  Give me an example of where C is allowed to optimize your data layout and/or locality. Afaik it is incredibly restrictive in this sense, because of how well defined it is. The less things it gives as guarantees with regards to layout the more wiggle room it would have, and languages like C cannot do some things that languages with a gc can do that can improve cache locality.
  - dooglius 7y ago
    It's not, that's the point, the language/compiler cannot interfere with the programmer fine tuning data structures to suit the underlying architecture.
    - nickitolas 7y ago
      I thought the discussion was around compiler optimizations? That's the point
      - dooglius 7y ago
        I didn't read it as such. The point behind what I and the parent are saying is, the programmer is going to do much better at optimal memory layout than an optimizer can, and C allows manual control while languages which can mess with memory layout necessarily cannot.
zelly 7y ago
Yes, the "high performance" argument for C is a joke at this point. Modern programs are not bound by ALU heavy cycles. It's all about cache locality. C does not help besides forcing you, out of lack of expressiveness, to stick to simplistic data structures without too much indirection. Where it fails is at being unable to inline well (sans spooky LTO magic) because it effectively has no type system, bottlenecking your instruction cache where C++/Rust/Java would create optimized code. If C really were made to map to hardware, it would have a better story (at the language level) for heterogenous computing, SIMD, vectorization, etc. But instead vendors had to create DSLs for these things, because of course the base language doesn't support it, because it's not low level. Being tedious and almost as unexpressive as asssembly does not make a low level language. C doesn't map to the machine and never did. Compilers and chip vendors map to C. Further reading: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479

ori_b 7y ago

> The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: The problem with this line of argument: assembly has also not changed. If the things you talk about mattered, we would be using a different assembly.

fctorial 7y ago
> we would be using a different assembly. We are. It's called microcode.
- ori_b 7y ago
  And, you write microcode?

nomel 7y ago

> CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Keeping things physically close in memory has always been a strong requirement, as long as cache, pages, and larger than one-byte-memory buses have existed.

nickitolas 7y ago
Give me an example of where C is allowed to optimize your data layout and/or locality. Afaik it is incredibly restrictive in this sense, because of how well defined it is. The less things it gives as guarantees with regards to layout the more wiggle room it would have, and languages like C cannot do some things that languages with a gc can do that can improve cache locality.
- dooglius 7y ago
  It's not, that's the point, the language/compiler cannot interfere with the programmer fine tuning data structures to suit the underlying architecture.
  - nickitolas 7y ago
    I thought the discussion was around compiler optimizations? That's the point
    - dooglius 7y ago
      I didn't read it as such. The point behind what I and the parent are saying is, the programmer is going to do much better at optimal memory layout than an optimizer can, and C allows manual control while languages which can mess with memory layout necessarily cannot.

zelly 7y ago

Yes, the "high performance" argument for C is a joke at this point. Modern programs are not bound by ALU heavy cycles. It's all about cache locality. C does not help besides forcing you, out of lack of expressiveness, to stick to simplistic data structures without too much indirection. Where it fails is at being unable to inline well (sans spooky LTO magic) because it effectively has no type system, bottlenecking your instruction cache where C++/Rust/Java would create optimized code. If C really were made to map to hardware, it would have a better story (at the language level) for heterogenous computing, SIMD, vectorization, etc. But instead vendors had to create DSLs for these things, because of course the base language doesn't support it, because it's not low level. Being tedious and almost as unexpressive as asssembly does not make a low level language. C doesn't map to the machine and never did. Compilers and chip vendors map to C. Further reading: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479