3 ms·

This is a really, really misguided take on C and C++... They don't prioritize anything. They are just bad languages with a random assortment of features mostly

This is a really, really misguided take on C and C++... They don't prioritize anything. They are just bad languages with a random assortment of features mostly reflecting how people thought about computers in the 70's. Just think about this: vectorization is one of the obvious ways to get better performance in a wide range of situations. Neither C nor C++ have any support for that. Parallelism -- C++ kinda has something... C has zilch. Memory locality anyone? I mean, Common Lisp has a bunch of tools to aid compiler in optimizing code in the language itself, whereas C has like... "inline" and the ability to mess with alignment in structs, and I cannot really think about anything else. Stuff like UB isn't making the language perform better or easier to optimize. It's more of a gimmick that compiler authors for C and C++ found to produce more efficient code. It's a misfeature, or a lack of feature, that allowed for accidental beneficial side-effects. Intentional optimization devices in a language are tools that prove the code to be intentionally correct first, and that proof allows the compiler to elide some checks or to generate a more efficient equivalent code, based on the knowledge of the correctness of the proof (or, at least, upon explicit instructions from the code author to generate "unsafe" code).

fooker 3y ago
Wow, don’t get so invested in hating a technology, it’s just a tool.
kazinator 3y ago
> vectorization is one of the obvious ways to get better performance in a wide range of situations. Or, well, in a narrow range of situations where you have certain kinds of hardware with vectorization support. > C has zilch C has operating systems written in it which use parallel processing internally and make parallel processing available to applications. True, that may be done using techniques that are not described in ISO C. Common Lisp has undefined behavior, a familiar example being (rplacd '(1 . 2) 3): clobbering a literal object. Optimizations in Common Lisp are exactly like UB in C: you make declarations which specify that certain things hold true, and in an unsafe mode like (declare (optimize (safety 0) (speed 3))), the compiler blindly trusts your assertions and generates code accordingly. If you asserted that some variable is a fixnum, but it's actually a character string, that character string value's bit pattern will likely be treated as a fixnum. Or other consequences. Common Lisp is nice in that you can control speed and safety tradeoffs on a fine granularity, but you do trade safety to get speed. Common Lisps (not to mention Schemes) have extensions, just like C implementations. In plenty of code you see things like #+allegro (do this) #+sbcl (do that).
- crabbone 3y ago
  > certain kinds of hardware This certain kind of hardware exists on virtually all consumer-grade and server-grade CPUs produced in the last decade. This is where optimizations matter in the first place. It doesn't matter that operating system written in C: it has no concurrency in the language. Here are examples of concurrency in the language: in Java, you have "synchronized", in Go you have "select" in Erlang you have "receive", in Ada you have "task" and so on. These languages provide some way to deal with concurrency and language implementations must have concurrency primitives. There's nothing like that in C. You don't have to implement C in such a way that it supports concurrency in any way. No part of the standard requires it (unlike in C++, where you have threads since C++11). > Optimizations in Common Lisp are exactly like UB in C: My guess is that you have never even seen Common Lisp. You just wrote absolute nonsense.
  - kazinator 3y ago
    > This is where optimizations matter in the first place. It's also where optimizations often don't matter. > My guess is that you have never even seen Common Lisp (invoke-restart 'next-guess) > C: it has no concurrency in the language. That is now literally false. ISO C now has threads and atomics. Also, C has supported signals for eons: C code can be interrupted to run a signal handler, which requires reentrancy. However, it is correct that concurrent systems have been written in C without support in the language. In C, concurrency can be in a library/module, and you can develop that as part of the system from the ground up. This has enabled OS researchers to explore new concurrency mechanisms. The stagnant backwaters of Eiffel and Ada would not have come up with the Futex, for instance. Or RCU. In C, when you write a function that works only with its local variables, that is understood to be reentrant (with pretty much every compiler on the planet except maybe something for an 8 bit microcontroller with a kilobyte of RAM.) So that is actually one very important, basic piece of language-level support for concurrency. Code can be written in C to run on bare hardware such that with only a minimal amount of glue, C functions can handle interrupts. When a C function accesses external resources, that is obvious, and those accesses can be protected using external means also. That's generally how it works.

fooker 3y ago

Wow, don’t get so invested in hating a technology, it’s just a tool.

kazinator 3y ago

> vectorization is one of the obvious ways to get better performance in a wide range of situations. Or, well, in a narrow range of situations where you have certain kinds of hardware with vectorization support. > C has zilch C has operating systems written in it which use parallel processing internally and make parallel processing available to applications. True, that may be done using techniques that are not described in ISO C. Common Lisp has undefined behavior, a familiar example being (rplacd '(1 . 2) 3): clobbering a literal object. Optimizations in Common Lisp are exactly like UB in C: you make declarations which specify that certain things hold true, and in an unsafe mode like (declare (optimize (safety 0) (speed 3))), the compiler blindly trusts your assertions and generates code accordingly. If you asserted that some variable is a fixnum, but it's actually a character string, that character string value's bit pattern will likely be treated as a fixnum. Or other consequences. Common Lisp is nice in that you can control speed and safety tradeoffs on a fine granularity, but you do trade safety to get speed. Common Lisps (not to mention Schemes) have extensions, just like C implementations. In plenty of code you see things like #+allegro (do this) #+sbcl (do that).

crabbone 3y ago
> certain kinds of hardware This certain kind of hardware exists on virtually all consumer-grade and server-grade CPUs produced in the last decade. This is where optimizations matter in the first place. It doesn't matter that operating system written in C: it has no concurrency in the language. Here are examples of concurrency in the language: in Java, you have "synchronized", in Go you have "select" in Erlang you have "receive", in Ada you have "task" and so on. These languages provide some way to deal with concurrency and language implementations must have concurrency primitives. There's nothing like that in C. You don't have to implement C in such a way that it supports concurrency in any way. No part of the standard requires it (unlike in C++, where you have threads since C++11). > Optimizations in Common Lisp are exactly like UB in C: My guess is that you have never even seen Common Lisp. You just wrote absolute nonsense.
- kazinator 3y ago
  > This is where optimizations matter in the first place. It's also where optimizations often don't matter. > My guess is that you have never even seen Common Lisp (invoke-restart 'next-guess) > C: it has no concurrency in the language. That is now literally false. ISO C now has threads and atomics. Also, C has supported signals for eons: C code can be interrupted to run a signal handler, which requires reentrancy. However, it is correct that concurrent systems have been written in C without support in the language. In C, concurrency can be in a library/module, and you can develop that as part of the system from the ground up. This has enabled OS researchers to explore new concurrency mechanisms. The stagnant backwaters of Eiffel and Ada would not have come up with the Futex, for instance. Or RCU. In C, when you write a function that works only with its local variables, that is understood to be reentrant (with pretty much every compiler on the planet except maybe something for an 8 bit microcontroller with a kilobyte of RAM.) So that is actually one very important, basic piece of language-level support for concurrency. Code can be written in C to run on bare hardware such that with only a minimal amount of glue, C functions can handle interrupts. When a C function accesses external resources, that is obvious, and those accesses can be protected using external means also. That's generally how it works.