While programming optimization that makes ones' code completely unreadable is often a bad thing, there are places for it, like that one inner loop of your code that takes up 98% of the program's running time.
What are you tricks for improving performance in C, other than the obvious inline assembly or the like?
AHAHAHAHAHAHAHAHAHAHAHAHAHAHA FUCKING CLUELESS CPU NOOBS
>>10 YOU BETTER BE JOKING NIGGER. THAT AIN'T OPTIMIZATION AT ALL.
IT IS SHIT CODE >>11
char **x, **y; YOU FAIL, FURTHERMORE, http://en.wikipedia.org/wiki/Xor_swap#The_XCHG_instruction These compilers are more likely to recognize and optimize a conventional (temporary-based) swap than to recognize the high-level language statements that correspond to a XOR swap.
FUCKING NOOB
FUCK
Name:
Anonymous2007-09-16 0:14 ID:O8wP71a+
>>12 OKAY YOU FUQIN ANGERED AN EXPERT PROGRAMMER
GODFUCKIGNDAMN
FIRST OF ALL, YOU DONT FUQIN KNOW WHAT A MAN PAGE IS
SECONDLY, THIS IS /prog/ DO NOT DEMAND USEFUL ANSWERS THE WAY YOU WANT THEM TO BE
THIRDLY PROGRAMMING IS ALL ABOUT PHILOSOPHY AND ``ABSTRACT BULLSHITE'' THAT YOU WILL NEVER COMPREHEND
AND FUQIN LASTLY, FUCK OFF WITH YOUR BULLSHYT
EVERYTHING HAS ALREADY BEEN ANSWERED IN>>5,10,11
Name:
Anonymous2007-09-16 0:27 ID:Sy2QIfmT
Declare variables as static so the CPU doesnt have to set aside memory on the stack in each function call. Just be sure to reset it each time.
int foo(int a)
{
static int variable;
// ....
variable = 0;
}
Name:
Anonymous2007-09-16 0:29 ID:Sy2QIfmT
Another cool one I learnt in high school, if you're passing in aggregate types, its better to pass it in as reference so it doesn't have to get copied
int foo (struct foobar* myStruct)
{
return 1;
}
struct foobar a;
foo(&a)
Name:
Anonymous2007-09-16 0:31 ID:Sy2QIfmT
Of course, as >>12 was hinting at, if you have critical code in a tight loop, it's better to use the inline assembly, which is guaranteed to make your code run faster.
Noob? There's hundreds of kilobytes of assembly code in the program I'm working on, and it all has a very specific purpose (SIMD instructions for SAD/SATD/SSD/SSIM operations on large numbers of pixels). Obviously, assembly for something that can't be SIMD-optimized is *usually* a waste of time.
Thanks for the suggestions, for those of you that made them :)
>>17 and not knowing that that usage is undefined in the first place. YOU FUCKING WANKER I'LL JUST QUOTE ME: char **x, **y; YOU RETARDED MONKEYFUCK WANKER SAGE FOR GREATER JUSTICE
The problem with this is that faster hardware gives everyone an edge. When you're competing against other video encoders from other companies and organizations, what matters is your speed and/or quality edge over theirs. Since faster hardware speeds up everyone, it doesn't help one compete :)
Let the compiler to the good job. It's bad enough already you're doing C; no need to make your life more miserable when there are several awesome OMG OPTIMIZED C compilers. Just compile with -momg-optimized.
Name:
Anonymous2007-09-16 5:15 ID:6UUG73P+
My trick is to express my intent to the C compiler in such a way that communicates my intent to any humans that might be reading (including myself in two weeks' time). Compilers are pretty fuckin' good these days, there's no need to do strength reduction by hand since you can always compile with at least -O1 on today's hardware...
But anyway, yeah, if you want to know whether an integer is odd, use (x % 2) == 1 rather than the implicit boolean equivalent. It's more readable and the compiler produces an equivalent sequence of instructions anyway.
>>31
FUCK YOU FUCKING FAG
XOR SWAP TWO SIGNED INTEGERS AND TELL ME WHAT HAPPENDS YOU FUCKING PIECE OF SHIT
UNDEFINED BEHAVIOR TOO
I KNOW ALL OF THIS
I LIVE INSIDE STANDARDS
Name:
Anonymous2007-09-16 5:35 ID:S8KoCl51
apply the ``const'' qualifier where appropriate -- the compiler will moan in satisfaction when it is able to engage more optimizations as it spurts out code
Name:
Anonymous2007-09-16 5:45 ID:M+Nq55G4
>>32 THIS IS /prog/ YOUR STANDARDS DO NOT APPLY HERE
Name:
Anonymous2007-09-16 6:01 ID:Sy2QIfmT
>>33
Yes, passing const references to objects really pleases the compiler like Lady Godiva.
Also, if you ever need to initialize an array to all zeros, use memset(array, 0, sizeof(array));
Some compilers can detect this call and replace it with a single rep stosd instruction (given array length which lies on 4 byte boundary)
The above has no sequence points, they get modified multiple times, the result of which is undefined. Variables cannot be modified more than once between sequence points according to the C standard.
Relevant C standard text: J.2 Undefined Behavior Between two sequence points, an object is modified more than once, or is modified and the prior value is read other than to determine the value to be stored (6.5).
So apparently you don't live inside standards. Just because it works on a few compilers doesn't mean it works on them all.
>>34
This is about C, which is 100% defined by the standard. There are no other authoritative sources. Except maybe.. "Learning C for DUMMIES!"