Same program in C and in C#. C# is faster than C. How Come ?

[c]

Hi every one,

Me and my Cousin were talking about C and C#, I love C and he loves
C#..and were talking C is ...blah blah...C# is Blah Blah ...etc

and then we decided to write a program that will calculate the
factorial of 10, 10 millions time and print the reusult in a file with
the name log.txt..

I wrote something like this

#include <stdio.h>
unsigned int fib (int n);

int main()
{
FILE *fp;
unsigned int loop =1 ;
if ( (fp = fopen( "log.txt", "a" )) != NULL )
for (loop; loop <= 10000000 ; loop++)
{

fprintf(fp,"%u\ n",fib(10));
}
fclose (fp);
return 0;
}

unsigned int fib (int n)
{ if (n != 1 )
return n * fib(n-1);
else
return 1;
}
and he did the something in C#
and then we all have the same laptop..DELL Inspiron 6000.

I ran my program, I took 18 seconds to get done..his program took 7
seconds..Wow

and then I asked him to run my program in his laptop..it's all the
same ..but I wanted to...I ran it...gave me the same time..

How come ..?!

Next day, I tried some Optimization

and developed the loop and wrote something like this

for (loop; loop <= 1000000 ; loop++)
{
fprintf(fp,"%u\ n %u\n %u\n %u\n %u\n
",fib(10),fib(1 0),fib(10),fib( 10),fib(10));
fprintf(fp,"%u\ n %u\n %u\n %u\n %u\n
",fib(10),fib(1 0),fib(10),fib( 10),fib(10));
}

But his program still faster than mine..

then, I tried the program under Slackware 12....it took 3.8 Seconds to
get done..Wow, I won the Challenge..

anyway, he want me to beat him under windows XP...Please guys help me
out..

[Tor Rustad]

Willem wrote:

Tor wrote:
) Some years ago, I was told that lazy commit, was the reason we didn't
) run *any* production systems on Linux, now it's allowed in *some* cases
) to use this OS. If an OS don't flush system buffers when a file is
) closed, or is doing a fflush() in an async manner, then it is impossible
) to code a bullet-proof C program with file I/O, in that environment.

You can actually turn that off in Linux, you know.

It appears, that write-back cache is turned off by default on e.g.
Windows and Solaris, but not on my Linux distro. I see that InnoDB MySQL
people suggest doing e.g.

hdparm -W 0 /dev/sda

to turn it off on Linux. BUT to my mind, this must be a work around,
since fsync() should do the job. If fsync() cannot be trusted to do the
right thing, that's a nasty Linux bug, and write-back cache must/should
be turned off manually.

) I think the simple answer here, is that the clock() implementation on
) Linux, measured processor time used in *user* space only, ignoring the
) (significant) time spent in system calls. :)

Hmm, not quite. The clock() function is supposed to only measure processor
time used, so time spent waiting for I/O to finish will not be counted.
(After all, during that time, other tasks can get their share of CPU time.)
It does count CPU time spent in the system call though, AFAIK.

You might be right, the point is anyway that the actual I/O was not
counted by clock(), as such, the clock() function is rather useless for
measuring performance of I/O bound programs.

--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>

[Richard]

Tor Rustad <to********@hot mail.comwrites:

Willem wrote:

>Tor wrote:
) Some years ago, I was told that lazy commit, was the reason we
didn't ) run *any* production systems on Linux, now it's allowed in
*some* cases ) to use this OS. If an OS don't flush system buffers
when a file is ) closed, or is doing a fflush() in an async manner,
then it is impossible ) to code a bullet-proof C program with file
I/O, in that environment.

You can actually turn that off in Linux, you know.

It appears, that write-back cache is turned off by default on
e.g. Windows and Solaris, but not on my Linux distro. I see that
InnoDB MySQL people suggest doing e.g.

hdparm -W 0 /dev/sda

to turn it off on Linux. BUT to my mind, this must be a work around,
since fsync() should do the job. If fsync() cannot be trusted to do
the right thing, that's a nasty Linux bug, and write-back cache
must/should be turned off manually.

Assuming journal markers are stored on the same device then I don't see
what the issue is. Lazy on or off, there is still the opportunity for
data loss and any restarting program (application or os) must examine
journal marks to determine the last safe write.