brainlet here,why does "endl" makes my program run 7 times slower?is the gcc's implementation of endl is badly written?
posting other pics in a sec for comparison.
here is the code with line-breaking.i was expecting it to be slower because of the line breaks but 7 times slower?
try using a '\n' in the string instead of leaving it out. gotta get scientific on this bitch
because endl also forces a output stream flush. you should always use "\n" for line breaks and endl when you need to force flush
>>60692601
yeah \n is faster though still 5 times slower.
>>60692605
>>60692601
OP post above two result. I am curious
OMGOMGOMG GUYS I FOUND SOMETHING.unwrapping the loop makes it insanely fast.gcc shit with loops confirmed?
>>60692718
It runt 1000 times instead of 10000 now, right?
>>60692814
no,it ran 10 000 times just like the others.there's a line counter on the left of the ide.
>>60692530
>brainlet here,why does "endl" makes my program run 7 times slower?
No, because stdout is flushed on newline, while without any newline it is flushed on program exit.
>>60692661
>>60692601
See above
>>60692842
lol i just realized the line counter is fucked.it starts from 1 again after 1023 wtf
>>60692842
line counter returns at line 1010 though
loop unrolling does yield better performance but not this much
in windows use putchar_unlocked or something, or just write to handle directly and force int
>>60692718
shouldn't it be repetitions ofcout << "hello world!\n";
i++;
if( !( i < 10000 ) ) break;
instead of just the cout?
>>60692718
try compiling the original code with -funroll-loops
>tfw the gentoo meme is real