Elegance vs. Performance

So /prog/, what would you choose between these two snippets of C code...


int *arr[3];
arr[0] = 1;
arr[1] = 2;
arr[2] = 3;

or...


int i;
int *arr[3];
for (i = 0; i < 3; i++)
  arr[i] = i+1;

The second one is more elegant, but requires more operations.

>>1 Here.
Fuck, I changed the way I wrote the snippets halfway through. Disregard the '*'s in the declaration of arr.

>>1
What you call elegance or what I'd call being a lazy fuck.

int arr[] = {1, 2, 3};

Forgot to mention that this is more elegant and has better performance than either solution present in >>1 (unless optimized by a compiler of course).

>>2

It's still valid, though most compilers will give you a warning.

>>3
Fair enough.

>>4 and >>5
Excellent point, however, consider a situation in which these operations are done using variables and several operations, for instance:


int *someFunc(int someFactor, int *someArr)
{
  for (int i = 0; i < 3; i++)
    someArr[i] *= (someFactor * someFactor) + SOMECONSTANT;
  return someArr;
}

>>6

Yes, it's valid, but it's incorrect and you will more then likely get a segmentation fault. You have a pointer to a pointer there, and you later dereference only one pointer when modifying memory.

The compiler probably unwinds the loop anyway, so who cares.

That's what you need proper macros for. Enjoy your shitty language without proper macros.

>>8

We're not accessing the data the pointers are pointing at so I don't really see the issue.

>>7

Then you'll obviously write it as a for loop, that way you may easily modify the program to either jump over some parts of the array, increase the iterations and so on.

1.
mov edi, [esp]
xor eax, eax
inc eax
stosd
inc eax
stosd
inc eax
stosd
10 bytes

2.
mov edi, [esp]
mov ecx, 3
:derp
xor eax, eax
inc eax
stosd
loop :derp
11 bytes

So hardly a difference for a compiler that can think.

>>14
I think you made a mistake. In example too, the label and xor eax,eax need to exchange places, otherwise you're writing only 1's

>>14
Recursion on comment considered harmful


#include <stdio.h>
#include <string.h>
int main()
 {
  int * arr[3]; int temp = '1'; int index = 0;
  while(index<2)
   {
   memset(arr + index, temp, index)
   }
  exit 0;
 }

any decent compiler optimizes this shit anyway

-funroll-loops

    　　 　　　　　　　　　 　／￣∧＿∧￣￣￣ //￣＼＼
    　　　　　　 ＿＿ ⊂／＿＿（´∀｀　）_＿　　/_⊃＿__|　|＼フ ヽ　　CFLAGS JUST KICKED
    　　　,　 ´＿　　／　　　／￣￣ ＿_　／￣　ヽ　　　 __ヽ￣￣　|　　IN, YO!
    　　/∠__／―/-。―／――∠＿／＿_∧　　| 　 　　　 | ∧＿.|　
    　　,========――´=========＝===/⌒ヽ=|.===＝＝| | ヽ￣〕　
    　 |　＿　　 |GENTOO| 　　 ＿ 　″ 　|⌒|　|/　　　_＿ /|　 ）ノ　　　　vroom
    　 ）_旧＿∈≡≡≡≡∋＿旧＿″＿||　ノ丿＿ -――┘ 丿　　　　　　vroom!
    　　 ＼　＼＿ノ ￣￣￣三三三＼　＼＿ノ　　　　三三三三　
    　　　　三三三三三三三三三三三三三三三三三三三三三三三三
    　　　　　　　三三三三三三三三三三三三三三三三三三三三三三三
    　　　　　　　　　　三三三三三三三三三三三三三三三三三三三三三三三三三三
    　　　　　　　　　　　　　　　　　　三三三三三三三三三三三三三三三三三三
    　　　　　　　　　　　　　　　　　　　　　　　　三三三三三三三三三三三

>>1
Uhh....In the first piece of code, you explicitly name the array elements. In the second, the shit is anonymous. The first case is inflexible, whereas the second case allows you to pretty easily...

Oh cripes, you suck. Either ask your college for a refund or go back to playing with your barbie dolls.

>>13

You have to clear the direction flag, if not that will result in undefined behavior.

>>13
mov dword [arr+0], 1
mov dword [arr+4], 2
mov dword [arr+8], 3
is even less bytes.

Either way,
section .data
arr: dd 1, 2, 3
is better.

>>21
And just for the record, what both of you idiots are babbling about is machine specific shit. The code would bork some ALPHA machines.

>>22
I find it improbable that >>1 or >>13 are using anything else than x86 or x86_64. Feel free to prove me wrong though. I'm also sure you'd be able to modify the assembly code to fit your ``non-standard'' architecture if you're using one, the examples listed are minimal. I'd also be hard pressed to say that anyone here didn't know that assembly code was architecture specific, it's practically by definition. The fact that you even bothered to type such an obvious statement indicates that you are unintelligent, yet want others to view to you highly, in which case I must advise you to not take /prog/ this seriously, relax this is just a textboard.

>>23
Listen you autistic jew, what you are rattling about is a non portable solution to a piece of portable C code. To put this in terms that you puny mind can understand, the OPs C code would compile and run on a SPARC, ALPHA, and, the x86. Whereas the assembler code wouldn't.

>>23
There are a couple ways to write x86 assembler you dumbass nigger. I just don't care for your style of assembler.

>>24
the OPs C code would compile and run on a SPARC, ALPHA, and, the x86. Whereas the assembler code wouldn't.
Everybody knows that, again, stating the obvious will only make you seem even less intelligent.

We are having the discussion since the optimal C solution has already been posted. Since you are the one lashing out whenever someone doesn't do what you want you are the one that's likely to be autistic. You should be able to abstract the x86 specific examples into more general assembly code, this is the mark of an intelligent person, since you are unable to do so you must be unintelligent, since this infuriates you, you must be socially unintelligent.

>>25
Your opinion is inconsequential, this is fortified by the fact that you are unintelligent. You simply don't matter. You are without value. Nobody cares about your opinion. I'm sure even you will be able to properly interpret one of the sentences above properly, and perhaps realize a thing or two about yourself.

>>26
"We are having the discussion since the optimal C solution has already been posted."

I can't find anything in the C89, C90, c99 standard that mentions anything about using assembly to produce optimal C code.

"You should be able to abstract the x86 specific examples into more general assembly code"

That was part of the reason why C was invented you fucking retard.

>>27
I can't tell if you're trolling or just really stupid.

>>28
I'm not the one who doesn't understand C.

>>29
In C/C++ you don't understand things. You just get used to them.

>>27,29

I must share >>28 sentiment here, the optimal C solution has been posted, and it wasn't the assembly code. Again you're unable to properly generate an abstraction, C can do things processors are unable to do in the same amount of lines (if we count one instruction as one line), the assembly code posted in this thread gives a general idea what processors are able to do, they can move bits between memory and registers. I'm sure the whole point >>13 was making is that the difference is small when compiled to assembly, so the most readable and modifiable solution is the optimal one.

However, you are still stuck at an infantile level of communication, sticking to worthless insults, you also seem to lack basic reading comprehension. You probably have some brain deficiency, or you just lack general intelligence. Either way I'd recommend you think a little more before you post, or perhaps leave this place altogether, you don't seem to be contributing with anything interesting and you're incapable of listening to anyone that is superior to you.

C/C++ has undefined behaviour.
Assembly has no.
------------------------------------
Assembly is more portable than C/C++

We can still run old DOS games after all these years! But given their C/C++ sources we won't be able to compile them in modern C/C++ environment. Write assembly, because C/C++ isn't portable.

>>32
C/C++ has undefined behaviour.
You made a non-bullshit statement in that post. I assume that was a mistake so I thought I'd like you know.

>>31
"I must share >>28 sentiment here, the optimal C solution has been posted, and it wasn't the assembly code. Again you're unable to properly generate an abstraction,"

I believe it was Dr. Richtie that said that C was portable assembler. How much more abstraction do you want you fucking idiot?

"the assembly code posted in this thread gives a general idea what processors are able to do, they can move bits between memory and registers. "

C89, C90, and C99 don't make any reference to C being dependent on assembly. Perhaps you should actually read one of the C standards instead of making up your own definition of what C is.

"However, you are still stuck at an infantile level of communication, sticking to worthless insults, you also seem to lack basic reading comprehension. "

You're projecting. I'm not the only trying to include shit that outside the standard definition of C.

"Either way I'd recommend you think a little more before you post,"

This is coming from a person who writes at the 8th grade level.

*that is outside the standard definition of C.*

>>20
The direction flag is always cleared in any sane ABI.

>>34
You should learn to read, write and interpret written English properly. I suggest you return to whatever basic educational facilities that are available to you and retake (I'm presuming you've already taken them, I realize that might not be the case considering your performance so far) the most basic courses in English, then attempt to learn programming, that way you'll be able to have a normal conversation about programming.

Before you do that I see no point in conversing with you, you seem to be very unintelligent and your behavior is infantile, at the very least basic education should make you somewhat acceptable.

This is coming from a person who writes at the 8th grade level.
I'm not the only trying to include shit that outside the standard definition of C
Right, go back to school, kid.

>>37
YHBT FAGGOT

>>36
You don't know what trash are in the flags before you run the routine. I'd rather risk using one instruction than getting a practically undetectable bug a couple of years from now. Not doing so should be considered really bad practice actually, as your routine working now is up to chance.

>>39
autistic faggot detected