3 ms·

If optimization doesn't matter, then why are you talking about optimization? This is just plain stupid... Vectorization is a huge subject in many different kin

If optimization doesn't matter, then why are you talking about optimization? This is just plain stupid... Vectorization is a huge subject in many different kinds of software, RDBMs, scientific computing / HPC, even advertising... and then comes you and tells all those people spending billions of dollars a year on optimization that it... doesn't matter? How much does it have to matter before it "really" matters? Well, then you've never understood what you were dealing with. Or your reading-comprehension skills are so bad, that you cannot understand it when someone describes the difference between something that happens intentionally and something that happens through oversight... But, my guess is that you are just pretending to be stupid, because you enjoy trolling, and that's your way to do it. C signals aren't a required part of the language... (a "standard compliant" implementation doesn't have to have them) but C language is just poorly designed. There shouldn't have been a thing like "not required part of the language", but it happened out immediate convenience of someone who didn't want to apply themselves more to making a better design. Exactly the same is true for threads and atomics. A "standard compliant" implementation doesn't have to have them. Portable code shouldn't use this stuff. Read it again: this discussion is about language, not libraries. If you think that ability to make a system call makes a language concurrent, then it's a worthless definition, because this blurs the important distinction between languages that are designed to be concurrent and those which aren't. Everything short of stuff like HTML becomes a concurrent language, but you cannot have any meaningful discussion about benefits or downsides of an approach to concurrency, because it's "outsourced" to something outside the language. > C functions can handle interrupts. What... like processor interrupts? What on Earth are you talking about... Are you getting your text from a chatbot or something?

kazinator 3y ago
> Vectorization is a huge subject in many different kinds of software, RDBMs, scientific computing A lot of which is written in C. C compilers have support for vector instructions. Vector instructions can also be used via language extensions (that can look like a macro library and can be made to work without vectorization). > C signals aren't a required part of the language. ISO C defines signals, which are a required part of a hosted implementation; same as printf or malloc. It is not a "full blown" signal specification like in POSIX. sigprocmask isn't in C, neither is sigsetjmp/siglongjmp. > like processor interrupts? Yes. Interrupt handling requires some processor-specific code to which the interrupt is vectored first; it does certain necessary things like save the machine state and acknowledge the interrupt. From that, C code can be dispatched. The meat of the interrupt handling is in C. Lots of systems are written on the "bare hardware" like that. > this discussion is about language, not libraries. Since I'm an actual Lisp person, I do not care about this difference. "Language" is just the core special forms handled by an interpreter or compiler; library is everything else, including the run-time support needed by those special forms. The "special forms" part of C brings little to the table in terms of concurrency other than the ability to write reentrant code. From that departure point, you can do a lot. > There shouldn't have been a thing like "not required part of the language" Interfaces and constructs that are described in a standard, but optional, still exist. There is a difference between that and not standardizing it at all. Optional or not is mainly just a game of words: what can be implemented and what can be left out such that the implementation can still call itself "conforming". If you make, say, threads required, then what it means is that C implementations for small systems will opt out of implementing that anyway, and just not be able to call themselves conforming. Nothing changes; just the game of words and labels plays out differently. > Everything short of stuff like HTML becomes a concurrent language That is false. For instance Awk isn't a concurrent language. We can't write a re-entrant function in Awk that can be called safely at interrupt time. Most of what defines a concurrent language is in the model of the run-time. For instance, the concurrency in Java actually comes from the JVM, and there are other languages on the JVM which borrow the concurrency model. > Exactly the same is true for threads and atomics. A "standard compliant" implementation doesn't have to have them. Portable code shouldn't use this stuff. If a program uses ISO C threads or atomic and needs to ported to some system/compiler where they are not available, it is likely possible to implement them in the program itself. I could probably knock it off in under a week.

kazinator 3y ago

> Vectorization is a huge subject in many different kinds of software, RDBMs, scientific computing A lot of which is written in C. C compilers have support for vector instructions. Vector instructions can also be used via language extensions (that can look like a macro library and can be made to work without vectorization). > C signals aren't a required part of the language. ISO C defines signals, which are a required part of a hosted implementation; same as printf or malloc. It is not a "full blown" signal specification like in POSIX. sigprocmask isn't in C, neither is sigsetjmp/siglongjmp. > like processor interrupts? Yes. Interrupt handling requires some processor-specific code to which the interrupt is vectored first; it does certain necessary things like save the machine state and acknowledge the interrupt. From that, C code can be dispatched. The meat of the interrupt handling is in C. Lots of systems are written on the "bare hardware" like that. > this discussion is about language, not libraries. Since I'm an actual Lisp person, I do not care about this difference. "Language" is just the core special forms handled by an interpreter or compiler; library is everything else, including the run-time support needed by those special forms. The "special forms" part of C brings little to the table in terms of concurrency other than the ability to write reentrant code. From that departure point, you can do a lot. > There shouldn't have been a thing like "not required part of the language" Interfaces and constructs that are described in a standard, but optional, still exist. There is a difference between that and not standardizing it at all. Optional or not is mainly just a game of words: what can be implemented and what can be left out such that the implementation can still call itself "conforming". If you make, say, threads required, then what it means is that C implementations for small systems will opt out of implementing that anyway, and just not be able to call themselves conforming. Nothing changes; just the game of words and labels plays out differently. > Everything short of stuff like HTML becomes a concurrent language That is false. For instance Awk isn't a concurrent language. We can't write a re-entrant function in Awk that can be called safely at interrupt time. Most of what defines a concurrent language is in the model of the run-time. For instance, the concurrency in Java actually comes from the JVM, and there are other languages on the JVM which borrow the concurrency model. > Exactly the same is true for threads and atomics. A "standard compliant" implementation doesn't have to have them. Portable code shouldn't use this stuff. If a program uses ISO C threads or atomic and needs to ported to some system/compiler where they are not available, it is likely possible to implement them in the program itself. I could probably knock it off in under a week.