C

C is master race
In your face
gotta go fast
lets have a fucking blast
fuck yeah c

http://programming-motherfucker.com/buy.html

https://www.youtube.com/watch?v=GoyahR-rp_I

Whatever I have up till now accepted as most true and assured I have gotten either from the senses or through the senses. But from time to time I have found that the senses deceive, and it is prudent never to trust completely those who have deceived us even once.

—Rene Descartes, Meditations On First Philosophy

If there ever were a quote that described programming with C, it would be this. To many programmers, this makes C scary and evil. It is the Devil, Satan, the trickster Loki come to destroy your productivity with his seductive talk of pointers and direct access to the machine. Then, once this computational Lucifer has you hooked, he destroys your world with the evil "segfault" and laughs as he reveals the trickery in your bargain with him.

But, C is not to blame for this state of affairs. No my friends, your computer and the Operating System controlling it are the real tricksters. They conspire to hide their true inner workings from you so that you can never really know what is going on. The C programming language's only failing is giving you access to what is really there, and telling you the cold hard raw truth. C gives you the red pill. C pulls the curtain back to show you the wizard. C is truth.

Why use C then if it's so dangerous? Because C gives you power over the false reality of abstraction and liberates you from stupidity.

>>4

C is truth

No, it fucking isn't. C exists in a world where memory is uniform, caches don't exist, you only have one CPU and master on the system bus, and instructions aren't reordered. None of that has been true since the 80s. Stupid C programmers who believe otherwise are one of the greatest impediments to progress in systems software.

>>5
'>he doesn't know about C11

>>3
`>The future was predicted by this card game about the illuminati
Wow

Rust > C

>>6-7
e/g/in memes /g/ros

>>6
Who are you quoting?

Anyway, C needed a multithreaded memory model long before C11. Everyone who needed stuff like atomics hacked their own years ago so the C11 forms are scarcely used.

>>8
I guess these people don't realize the power of backward compatibility.Old C codebases are still operational and need minimal maintenance.
Old rust codebases, and even newer code gradually becomes deprecated and uncompilable,unable to advance past version X.
Codebases are always more valuable than language , just like apps > OS , internet > protocols and implementation > abstraction.

>>10
As if imperative mutable shit with null pointers can even have a decent multithreaded memory model.

>>12
Just as if decent multithreaded memory models can be implemented without imperative mutable shit. If it's not done in C or C++ it will be done in assembly.

C is a civilized tool from a begone age.

>>14
Ha! And what is the current age? The age of javascript no doubt!

>>15
Javashit is the new assembly, but that doesn't make current age "Javashit age" any more than the previous age was "assembly age".

>>12
That feel when Haskell STM is implemented in C...

https://ghc.haskell.org/trac/ghc/browser/ghc/rts/STM.c

>>5
Writing 'cache friendly' code means being able to easily predict and control data layout - you have this in C.
C didn't really need an official MT memory model because C was the language used to implement OS level MT primitives, so de facto models were enough.
And C is actually built with reordering in mind - expression evaluation orders are left implementation defined except for a few specific 'sequence points', at the time they probably didn't have the cpu reordering the instructions in mind, but from a language point of view a compiler or cpu reordering things is the same thing - all the language can do is leave it up to the implementation and have an "as-if rule", which C does.

// Helper macros for iterating over entries within a transaction
// record

#define FOR_EACH_ENTRY(_t,_x,CODE) do { \
StgTRecHeader *__t = (_t); \
StgTRecChunk *__c = __t -> current_chunk; \
StgWord __limit = __c -> next_entry_idx; \
TRACE("%p : FOR_EACH_ENTRY, current_chunk=%p limit=%ld", __t, __c, __limit); \
while (__c != END_STM_CHUNK_LIST) { \
StgWord __i; \
for (__i = 0; __i < __limit; __i ++) { \
TRecEntry *_x = &(__c -> entries[__i]); \
do { CODE } while (0); \
} \
__c = __c -> prev_chunk; \
__limit = TREC_CHUNK_NUM_ENTRIES; \
} \
exit_for_each: \
if (FALSE) goto exit_for_each; \
} while (0)
#define BREAK_FOR_EACH goto exit_for_each

>>17,19
Fuck you, nigger!

>>19
Simon Peyton Jones uses GOTO! Haskiefaggots betrayed by their leader, lolllooolollol.

double checkem = 2.2;

>>18
C makes no guarantees about the way the implementation allocates memory. It is true that memory layout is predictable in many C implentations, but this is not guaranteed by the language itself. C code that makes assumptions about memory layout is very much non-portable and implentation specific.

Prior to C11 (and continuing today, since most C users of note do not rely on C11 support) the situation with multi-threading was very similar; all behavior was implementation specific. In theory, other standards like POSIX solved this problem at least for particular platforms but you don't need to look very far to find supposedly POSIX conforming compilers that break badly under the right conditions with multithreading (*cough* gcc *cough*)

The as-if rule for ordering is a joke too; it does not even come close to capturing the semantics needed for any code that does more than just manipulate values in application memory. Once you introduce external interaction of any kind, be it MMIO, debugger run control, OS traps... it all falls down and you are left with implentation defined behavior again.

>>23
Cache sizes, number of cache levels and DMA channels are implementation details, you can't write portable code which is maximally memory efficient (or any kind of efficiency really).
Any half-decent C implementation will either give you apis/syscalls/intrinsincs/pragmas for controlling these things exactly.

The point is that C is the languages used to implement the lower level threading primitives, so you will be writing implementation specific code anyway, so not having an official standard for it isn't a big deal.

Once you introduce external interaction of any kind, be it MMIO, debugger run control, OS traps... it all falls down and you are left with implentation defined behavior again.

What falls down?
It being implementation specific is the entire point, that is what allows compilers (and in effect cpus, memory controllers or what have you) maximum leeway to reorder things.

>>24
I disagree. C is used in high performance applications as well; saying that the status quo is acceptable because C is used at lower levels doesn't excuse the lack of reliable standardization at higher ones. Many applications stand to benefit from this.

Concerning memory ordering, my point is that any code that works with externally visible memory must have ways to limit reordering only for the memory that is shared. C historically hasn't provided a good way to do this (volatile is a joke). C11 improves the situation somewhat in the case of threads but practically speaking people are unsure how well the semantics will work when applied to things like MMIO devices.

>>25

C is used in high performance applications as well;

Yeah with intrinsics and implementation specific apis.

excuse the lack of reliable standardization at higher ones. Many applications stand to benefit from this.

What are you gonna standardize?
Vector registers have different sizes, certain instruction sets support certain operations (horizontal vs vertical arithmetic for example), some are good at shuffles, others are better suited for synthesizes constants or data moves directly.
Some architectures have write combining memory or temporal hints, some have deprecated the use of these hints because the hardware are better at handling itself.

C11 improves the situation somewhat in the case of threads but practically speaking people are unsure how well the semantics will work when applied to things like MMIO devices.

That should tell you something of how useless it is to standardize.
Java went for full sequential consistency, but that is shit tier for architectures like powerpc and armv7 and older which only has very heavy weight synchronization for targeting seq consistency, and x86 guarantees acquire/release for aligned word sized loads/stores so memory barriers are unnecessary or the most part.

Compiler intrinsics is the way to handle this mess, and good C implementations has that down nicely.

i made this thread when i was high and it has over 20 replies

I'm always stoned and have replied to this thread over 20 times.

I stoned over 20 stoners who replied to this thread.

>>29
Allahu Akbar!

>>26

What are you gonna standardize?

The primitives. All primitives may not be supported on all platforms and the unit sizes / limits may differ but that is no different from the situation we already have with plain integer arithmetic. People should not need to cross reference 3 separate compiler manuals to get some of this shit to work.

I'll agree that getting memory ordering right is hard. I guess my biggest frustration is with the speed at which the language is currently evolving; sometimes it feels like Linux and pthreads set the whole industry back 10 years here.