Comparision of C Sharp and C performance

[Kenny McCormack]

(snip)

What rock did you just climb out from under?

(Or, equivalently, which reg are you a sock puppet of?)

 

[Seebs]

In fact I have to wonder, do you ever actually contribute anything
about the C programming language?

I saw it happen once.

Oddly, over in comp.unix.shell, he actually contributes topical material
and shows technical understanding, so it's not a general incapacity. I
guess he's just butthurt about comp.lang.c for some reason.

-s

 

[Keith Thompson]

C's clock() function gives elapsed times in msec.

No, it gives CPU time (not elapsed time), expressed as a value
of type clock_t. To get the time in seconds, the result must be
scaled by dividing by CLOCKS_PER_SEC.

On one system I just tried, clock_t is compatible with signed long,
and CLOCKS_PER_SEC is 1000000; on another, clock_t is compatible
with unsigned long, and CLOCKS_PER_SEC is 1000. (Note that on the
first system I tried, clock_t values will overflow in less than 36
CPU minutes.)

 

[stan]

I saw it happen once.

Oddly, over in comp.unix.shell, he actually contributes topical material
and shows technical understanding, so it's not a general incapacity. I
guess he's just butthurt about comp.lang.c for some reason.

I can add the same observation for awk stuff where he appears lucid,
but I have to admit I question more and more of what I see from
him. When I find myself agreeing with him I start to wonder if I AM wrong.

I must agree with your word choice "odd".

 

[spinoza1111]

It seems that you consider yourself quite knowledgeable and expert,
even superior to Dijkstra, yet you offer so little actual news or
information actually about C.

In fact I have to wonder, do you ever actually contribute anything
about the C programming language?



This sort of sarcasm, petty whining, attempted humor, ... can get
boorish when applied, in your words, "many times". Just a thought but
the phrase "you can be part of the problem, or you can be part of the
solution" springs to mind often when trying to follow threads.

The fact is that corporate programmers do have short careers which
tend not to be adequate to raise a family: studies have found that
many programmers find it almost impossible to get work after more than
ten years of experience, even if they retrain.

I was an anomaly not because I retrained, although I learned C in the
1980s and .Net more recently, but because I work out regularly even
today and therefore look significantly younger than I am, with the
result that I worked continuously from Nov 1971 to 2005.

Slogans from the 1960s don't change the fact that programmers, as
people who carry out the will of most uncaring managements in the most
excruciating detail, are treated like dirt, and respond not with
solidarity but with regression, here, to what Adorno called "the
nightmare of childhood": Fascism.

As for the topic/rant in question, if I ever set out to develop a
project for only a MS proprietary platform I'll probably care about C#
vs options but since my normal development world is not MS the
question isn't really important for me personally. My world also
slants more towards system stuff than the latest shiny user app - in
other words I'm not fascinated by eye candy. I seem to be in a
minority admittedly. But in my world the fact that C is used to build
C tools intuitively feels like a win. No intended swipe here but does
a C# compiler for C# exist? With source for study?

I wrote and published a Visual Basic .Net compiler for most of Quick
Basic for study. Cf. "Build Your Own .Net Language and Compiler",
Edward G Nilges, Apress 2004.

There's no reason why a C Sharp compiler couldn't be written for C
Sharp.

 

[spinoza1111]

spinoza1111wrote:


So about 90% of the speed of C.

Yes. And you get much higher levels of built-in reality for that ten
percent.

I didn't care; both versions overflowed to give the same wrong result. I
just didn't want the results dominated by the attempting 64-bit multiplies
on my 32-bit machine.




Check again. I got 5.4 seconds for C# and  3.0 seconds for C. Are you using
32-bits in C, where it's not always obvious?

Yes, and it's obvious. I am using int in C Sharp and long in C, where
"int" in C Sharp means 32 bits and "long" in C means 32 bits.

In this tiny program everything should fit into the cache.

Hmm..."the" cache. There is "a" stack at runtime, and Schildt was
correct in using the definite article. But "the" cache? Anyway, it
appears that if there was "a" cache, it worked better in .Net.

An optimising C compiler is a few MB, and is not needed to run the result..
To compile your C# code, I needed a 63MB download. Then I needed .NET which
probably was already in my OS, but appears to 'take up to 500MB of hard disk
space'.

Boo hoo. If safety means anything, then 500MB is worth it. Were not
running our Commodore 64 in Mom's basement any more.

 

[Kenny McCormack]

Be aware that this "stan" character is a toad. Let's not bother with him.

He is almost certainly also a sock of one of the regs - probably Seebs.

 

[spinoza1111]

Fair enough.  It's not exactly what I'd call an interesting test case for
real-world code.  I'd be a lot more interested in performance of, say,
large lists or hash tables.

-s

C code to hash several numbers, iterated to get somewhat better
performance numbers.

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#define ARRAY_SIZE 1000
#define SESSIONS 100000

int main(void)
{
int hash[ARRAY_SIZE];
int i;
int r;
int j;
int k;
int collisions;
time_t start;
time_t end;
double dif;
int tests;
int sessions;
time (&start);
for (sessions = 0; sessions < SESSIONS; sessions++)
{
for (i = 0; i < ARRAY_SIZE; i++) hash = 0;
collisions = 0;
tests = ARRAY_SIZE;
for (i = 0; i < tests; i++)
{
r = rand();
j = r % ARRAY_SIZE;
k = j;
if (hash[j] != 0) collisions++;
while(hash[j] != r && hash[j] != 0)
{
if (j >= ARRAY_SIZE) j = 0; else j++;
if (j==k)
{
printf("Table is full\n");
break;
}
}
if (hash[j] == 0) hash[j] = r;
}
}
time (&end);
dif = difftime (end,start);
printf("It took C %.2f seconds to hash %d numbers with %d
collisions, %d times\n",
dif, tests, collisions, sessions);
return 0; // Gee is that right?
}

C Sharp code to do the same:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
HashSet<int> hash = null;
hash = new HashSet<int>();
Random R = new Random(1);
int i;
int j;
TimeSpan dif;
DateTime start;
DateTime end;
start = DateTime.Now;
int sessions = 100000;
int tests = 1000;
for (i = 0; i < sessions; i++)
{
hash.Clear();
for (j = 0; j < tests; j++)
hash.Add(R.Next(32767));
}
end = DateTime.Now;
dif = end - start;
Console.WriteLine
("It took C Sharp " +
dif.ToString() + " " +
"seconds to hash " +
tests.ToString() + " numbers " +
sessions.ToString() + " times");
return; // Ha ha I don't have to worry about the
shibboleth
}
}
}


The C Sharp code is not only smaller above, it runs dramatically
faster: 24 secs on my machine as contrasted with 35 secs for the C
code.

This is because the HashSet (also available in Java) can be written as
fast as you like in that it's a part of the extended "os". It may
itself be written in C, and please note that this does NOT mean that
YOU should write in C after all, because the HashSet was written state
of the art by studly guys and gals at Microsoft, and painstakingly
reviewed by other studly guys and gals.

And no, I don't want to visit some creepy site to get best C practise
for hashing. The fact is that the research it takes at creepy come-to-
Jesus and ammo sites to find "good" C, quite apart from its being a
waste of spirit in an expense of shame, provides no "forensic"
assurance that the creepy guy who gave you the code didn't screw up or
insert a time bomb. HashSet is available, shrink-wrapped and out of
the box, and IT RUNS TWICE AS FAST.

HashSet can even safely run as managed code but be developed as Java
bytecode or .Net MSIL as a form of safe assembler language. When it is
maintained by the vendor, you get the benefit. Whereas el Creepo's
code is all you get, period, unless you call him a year later, only to
find that his ex-wife has thrown him out the house.

C is NOT more "efficient" than C Sharp. That is not even a coherent
thing to say.

Furthermore, even the best of us screw up (as I have screwn up) when
implementing the basics. Donald R Knuth has said that he always gets
binary search wrong the first time he recodes it. It is a mark of the
smart person to have trouble with low-level math and code; Einstein
(cf Walter Kaufman's bio) had in fact a great deal of difficulty
working out the details of relativistic mathematics and required help
from other mathematicians and physicists.

Therefore we class acts prefer C Sharp.

 

[spinoza1111]

Fair enough.  It's not exactly what I'd call an interesting test case for
real-world code.  I'd be a lot more interested in performance of, say,
large lists or hash tables.

-s

C code to hash several numbers, iterated to get somewhat better
performance numbers.

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#define ARRAY_SIZE 1000
#define SESSIONS 100000

int main(void)
{
    int hash[ARRAY_SIZE];
    int i;
    int r;
    int j;
    int k;
    int collisions;
    time_t start;
    time_t end;
    double dif;
    int tests;
    int sessions;
    time (&start);
    for (sessions = 0; sessions < SESSIONS; sessions++)
    {
        for (i = 0; i < ARRAY_SIZE; i++) hash = 0;
            collisions = 0;
            tests = ARRAY_SIZE;
            for (i = 0; i < tests; i++)
            {
                r = rand();
                j = r % ARRAY_SIZE;
                k = j;
                if (hash[j] != 0) collisions++;
                while(hash[j] != r && hash[j] != 0)
                {
                    if (j >= ARRAY_SIZE) j = 0; else j++;
                    if (j==k)
                    {
                        printf("Table is full\n");
                        break;
                    }
                }
                if (hash[j] == 0) hash[j] = r;
            }
        }
    time (&end);
    dif = difftime (end,start);
    printf("It took C %.2f seconds to hash %d numbers with %d
collisions, %d times\n",
           dif, tests, collisions, sessions);
    return 0; // Gee is that right?

}

C Sharp code to do the same:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            HashSet<int> hash = null;
            hash = new HashSet<int>();
            Random R = new Random(1);
            int i;
            int j;
            TimeSpan dif;
            DateTime start;
            DateTime end;
            start = DateTime.Now;
            int sessions = 100000;
            int tests = 1000;
            for (i = 0; i < sessions; i++)
            {
                hash.Clear();
                for (j = 0; j < tests; j++)
                    hash.Add(R.Next(32767));
            }
            end = DateTime.Now;
            dif = end - start;
            Console.WriteLine
                ("It took C Sharp " +
                 dif.ToString() + " " +
                 "seconds to hash " +
                 tests.ToString() + " numbers " +
                 sessions.ToString() + " times");
            return; // Ha ha I don't have to worry about the
shibboleth
        }
    }

}

The C Sharp code is not only smaller above, it runs dramatically
faster: 24 secs on my machine as contrasted with 35 secs for the C
code.

This is because the HashSet (also available in Java) can be written as
fast as you like in that it's a part of the extended "os". It may
itself be written in C, and please note that this does NOT mean that
YOU should write in C after all, because the HashSet was written state
of the art by studly guys and gals at Microsoft, and painstakingly
reviewed by other studly guys and gals.

And no, I don't want to visit some creepy site to get best C practise
for hashing. The fact is that the research it takes at creepy come-to-
Jesus and ammo sites to find "good" C, quite apart from its being a
waste of spirit in an expense of shame, provides no "forensic"
assurance that the creepy guy who gave you the code didn't screw up or
insert a time bomb. HashSet is available, shrink-wrapped and out of
the box, and IT RUNS TWICE AS FAST.

HashSet can even safely run as managed code but be developed as Java
bytecode or .Net MSIL as a form of safe assembler language. When it is
maintained by the vendor, you get the benefit. Whereas el Creepo's
code is all you get, period, unless you call him a year later, only to
find that his ex-wife has thrown him out the house.

C is NOT more "efficient" than C Sharp. That is not even a coherent
thing to say.

Furthermore, even the best of us screw up (as I have screwn up) when
implementing the basics. Donald R Knuth has said that he always gets
binary search wrong the first time he recodes it. It is a mark of the
smart person to have trouble with low-level math and code; Einstein
(cf Walter Kaufman's bio) had in fact a great deal of difficulty
working out the details of relativistic mathematics and required help
from other mathematicians and physicists.

Therefore we class acts prefer C Sharp.

And don't waste my time. Yes, the C hash is oversimplified and creates
clusters, slowing it down dramatically as the table fills up. A
"delicate stratagem" would be of course to make each entry a linked
list base which would reduce the search time on average for each new
number to K times the average number of collisions C. In the C code
above the search time is larger than K*C because it's affected by
neighboring collisions. As the table fills up, the search time
increases very rapidly towards the maximum which is the total table
size. In the linked list solution (not implemented here but all over
Knuth and the Knet like a rash) search time is ALWAYS K*C!

But that's my point. Whereas it's a very good idea to reinvent the
wheel the place to do it is in an ACM approved Komputer Science Skool,
not on the job. Anyone who neglects academic training is a net cost to
a Korporation that pays him to write C so he can learn what he shuddha
learnt. 'Course, I wouldn't be talking about any auto-didact here.
There is nothing wrong with being an auto-didact as long as you don't
set out to destroy alter-didacts with MSCSen and BSen from the Univ of
Illinois.

My guess is that the studly Dudleys who developed Hashset went to
Komputer Skool and learnt their Knuth. That's because when I was at
Princeton, I helped people with their Microsoft interview having
crashed and burned at it myself in the spirit of people who flunked
their exams in ancient China and who started Konfucian Skewls in
preference, with one exception, to deciding they we're Christ's baby
brother and starting the Tai'ping revolution. Microsoft was, for
technical positions, exclusively recruiting comp sci majors.

 

[spinoza1111]

I can add the same observation for awk stuff where he appears lucid,
but I have to admit I question more and more of what I see from
him. When I find myself agreeing with him I start to wonder if I AM wrong..

What the hell kind of thing is this to say about another person? It's
less wrong to be wrong on some technical matter than to lie, as
Richard Heathfield has lied, about another person's publications in
comp.risks, or to start what's little more than a rumor about Schildt.
These are evil acts. Being wrong on some technical matter is NOT evil.

If a person lies, you can't trust him on technical matters, whereas if
a person merely makes technical mistakes, you can at least trust him
like you trust a monkey with a typewriter or wikipedia. He might
occasionally have insights, as does Shakespeare's Fool in King Lear.

In fact, one of the lessons Gerald "The Psychology of Computer
Programming" Weinberg relays is that even junior people in structured
walkthroughs could spot bugs, in some cases faster than the "senior"
programmers.

What bothers you about Kenny is that he has a sense of humor and mocks
the utter pretense of the regs.

 

[spinoza1111]

It seems that you consider yourself quite knowledgeable and expert,
even superior to Dijkstra, yet you offer so little actual news or
information actually about C.

In fact I have to wonder, do you ever actually contribute anything
about the C programming language?



This sort of sarcasm, petty whining, attempted humor, ... can get
boorish when applied, in your words, "many times". Just a thought but
the phrase "you can be part of the problem, or you can be part of the
solution" springs to mind often when trying to follow threads.

As for the topic/rant in question, if I ever set out to develop a
project for only a MS proprietary platform I'll probably care about C#
vs options but since my normal development world is not MS the
question isn't really important for me personally. My world also
slants more towards system stuff than the latest shiny user app - in
other words I'm not fascinated by eye candy. I seem to be in a
minority admittedly. But in my world the fact that C is used to build
C tools intuitively feels like a win. No intended swipe here but does

The problem is that the C tools had to be built to make C even
minimally useful. I realize that this was in part intentional on
Kernighan and Ritchie's part. C was intended to be the essential
kernel of a system extended with libraries.

But the best laid plans...instead of being extended with best of breed
libraries, C programmers remained chained to the original libraries
such as the abominable string library. Note that in a sense, the
abomination of desolation that is the Nul terminated string is not a
part of the C language. Instead, true C is a RISC language that
completely omits strings. You don't have to use strings, or you can
use a correct implementation that embeds a length code, or joins
strings with links into unbounded ropes.

Samuel Johnson if he did not think Scotland had many noble and wild
prospects:

"Mr. Ogilvie then took new ground, where, I suppose, he thought
himself perfectly safe; for he observed, that Scotland had a great
many noble wild prospects. JOHNSON. 'I believe, Sir, you have a great
many. Norway, too, has noble wild prospects; and Lapland is remarkable
for prodigious noble wild prospects. But, Sir, let me tell you, the
noblest prospect which a Scotchman ever sees, is the high road that
leads him to England!'"

C likewise contains certain Noble and Wild prospects, but the Noblest
prospect which a C programmer ever sees is his first .Net C Sharp
program.

 

[bartc]

C code to hash several numbers, iterated to get somewhat better
performance numbers.

C Sharp code to do the same:

The C Sharp code is not only smaller above, it runs dramatically
faster: 24 secs on my machine as contrasted with 35 secs for the C
code.

C was a bit faster on my machine.

But, you are now starting to get away from good benchmarking practices, by
comparing a implementation of something in one language, with a built-in
version in another.

This is a little dangerous: you might well find that feature is faster, or
just a little slower, in ruby, python or perl. Does that mean these
scripting languages should replace C or even C#?

Therefore we class acts prefer C Sharp.

I quite respect C# as a language, but it would be nice if it could be
extracted from the clutches of MS and existed independently.

 

[bartc]

Hmm..."the" cache. There is "a" stack at runtime, and Schildt was
correct in using the definite article. But "the" cache? Anyway, it
appears that if there was "a" cache, it worked better in .Net.

Whatever. It's probably the same one you mentioned first. And if C# runs on
it, then it's quite likely to have cache memory, hardware stack, the
complete works.

 

[spinoza1111]

spinoza1111wrote:

C was a bit faster on my machine.

But, you are now starting to get away from good benchmarking practices, by
comparing a implementation of something in one language, with a built-in
version in another.

But that's my point. Not only do you not have to "reinvent the wheel",
the built-in wheel is better and safer to use.

This is a little dangerous: you might well find that feature is faster, or
just a little slower, in ruby, python or perl. Does that mean these
scripting languages should replace C or even C#?

No. The real issue is software safety.

I quite respect C# as a language, but it would be nice if it could be
extracted from the clutches of MS and existed independently.

It does: Google the mono project. Microsoft has in fact worked hard to
make .Net open architecture (if closed source).

 

[Moi]

000

In your C example, you are using linear probing combined
with a fill factor of 100%. That is a bad choice, IMO.

Also, beware of rand(). It is guaranteed to deliver only 15 bits of random.
Implementations _may_ produce a larger range of values.

HTH,
AvK

 

[Ben Bacarisse]

C was a bit faster on my machine.

But, you are now starting to get away from good benchmarking
practices, by comparing a implementation of something in one language,
with a built-in version in another.

I think it is much worse than that. The C# code can chose the table
size for good performance (and I can't imagine it would not). In the
C version, the table was chosen to be as bad as it could be without
failing (i.e. exactly the same size as the number of numbers being put
into the set).

There is no evidence that any attempt at a reasonable comparison is
being attempted, here.

To perform the same task, the obvious C solution would use a bit
array, since the number range in the C# code was quite small, but I
suspect that was an arbitrary choice.

 

[bartc]

It does: Google the mono project. Microsoft has in fact worked hard to
make .Net open architecture (if closed source).

OK I'll have a closer look at Mono for Windows, although I was really
talking about the core language, ie. without it's complex environment.

 

[Kenny McCormack]

C was a bit faster on my machine.

But, you are now starting to get away from good benchmarking practices, by
comparing a implementation of something in one language, with a built-in
version in another.

But that's my point. Not only do you not have to "reinvent the wheel",
the built-in wheel is better and safer to use.[/QUOTE]

Hot, sexy, broken. Full employment. C is good.

Seriously, does anyone not see just how bad the economy could get if
software actually worked?

 

[Seebs]

OK I'll have a closer look at Mono for Windows, although I was really
talking about the core language, ie. without it's complex environment.

In any event, it's a red herring; Mono exists to make people think C# is
an open language, when it is in fact nothing of the sort. It's a pure
deception, so far as I can tell.

-s

 

[Seebs]

In your C example, you are using linear probing combined
with a fill factor of 100%. That is a bad choice, IMO.

The unanswerable question:

Did he do that because he's fundamentally dishonest, and wanted to rig the
test to look bad for C, or did he do that because he doesn't understand
the algorithm well enough to do better?

-s