4 ms·

>see how powerful and versatile GPUs have become because they didn't carry that legacy. GPUs are the best example for why C is a good lower-level high-level la

• naasking 7y ago
  > GPUs are the best example for why C is a good lower-level high-level language, seeing how CUDA is programmed in C/C++. CUDA is not C or C++. That you can program GPUs in a C/C++-like language does not entail that C/C++ is a natural form of expression for that architecture. > Do you have any examples of architectures that could exist if only they weren't constrained by legacy C? Turing tarpit means that every architecture could be realized, but that doesn't make it a particularly efficient or a natural fit for the hardware. For instance, consider that every garbage collected language must distinguish pointers from integer types, but no such distinction exists in current hardware, and the bookkeeping required can incur significant performance and memory constraints (edit: C also makes this distinction but it doesn't enforce it). Lisp machines and tagged hardware architectures do make such a distinction though, and so more naturally fit. With such distinctions, you could even have a hardware GC.
  • ori_b 7y ago
    > CUDA is not C or C++. Cuda is a C++ API. On modern hardware, it's programmed in purely standard C++.
  • madmax96 7y ago
    >That you can program GPUs in a C/C++-like language does not entail that C/C++ is a natural form of expression for that architecture. It's not a matter of what is/isn't a "natural form of expression." The point of C/C++ is to be high-level enough for humans to build their own abstractions over hardware. (sounds like an OS, right?) The success of the design of C/C++ is in that the creators had no knowledge of modern GPUs, yet GPUs can efficiently execute them with a little care from developers. We use other abstractions (e.g. SciPy on Tensorflow) because they are more appropriate to solve our problems, but they are built on C. >Lisp machines and tagged hardware architectures do make such a distinction though, and so more naturally fit. With such distinctions, you could even have a hardware GC. And why would that not be backwards-compatible with legacy C? Particularly, I am rejecting the idea that C is somehow stunting hardware development - I see no evidence of this fact. I am also skeptical about the claim (although I will not reject it outright) that there is a language substantially better fit compared to C for low-level programming (e.g. embedded, kernel).
    • naasking 7y ago
      > It's not a matter of what is/isn't a "natural form of expression." The point of C/C++ is to be high-level enough for humans to build their own abstractions over hardware. Sure it matters. If primitives don't map naturally to the hardware, then you have to build a runtime to emulate those primitives, just like GC'd languages do. > The success of the design of C/C++ is in that the creators had no knowledge of modern GPUs, yet GPUs can efficiently execute them with a little care from developers You cannot run any arbitrary C program on a GPU. This fact is exactly why GPUs were able to innovate without legacy compatibility holding them back. Only later were GPUs generalised to support more sophisticated programs, which then permitted a subset of C to execute efficiently. The progress of GPUs proves exactly the opposite point that you are claiming. If C were so perfectly suited to any sort of hardware, then GPUs would have been able to run C programs right from the beginning, which is not true. > And why would that not be backwards-compatible with legacy C? That's not the point I'm making. Turing equivalence ensures that compatibility can be assured no matter what. The actual point is that CPU innovations were tested against C benchmark suites to check whether innovations effectively improved performance, and some or many of those that failed to show meaningful improvements were discarded, despite the fact that they would have had other benefits (obviously not all of them, but enough). It's simply natural selection for CPU innovation. It's incredibly naive to think that only hardware influences software and not vice versa. For instance, who would create a hardware architecture that didn't have pointers? It would simply never happen, because efficient C compatibility is too important. The problem is that C was given a disproportionately heavy weighting in these decisions. For instance, a tagged memory architecture would show zero improvement on C benchmarks, but it would have been huge for the languages that now dominate the software industry. > that there is a language substantially better fit compared to C for low-level programming (e.g. embedded, kernel). The limitations of C are well known (poor bit fields and bit manipulation, poor support for alignment and padding, no modules, poor standard library, etc, etc.). Zig addresses some of those issues. Ada has been better than C for a long time. A better language than all of these could definitely be designed given enough resources, eg. see the research effort "House" [1]. [1] http://programatica.cs.pdx.edu/House/ http://programatica.cs.pdx.edu/House/
      • madmax96 7y ago