Re: C Slower than Python?
- From: cri@xxxxxxxx (Richard Harter)
- Date: Thu, 09 Oct 2008 00:18:12 GMT
On Wed, 08 Oct 2008 22:03:18 +0100, Flash Gordon
<smap@xxxxxxxxxxxxxxxxx> wrote:
Richard Harter wrote, On 08/10/08 16:42:<snip>
Many thanks for rooting through the code.
<snip>
Below is some code that, in the grand tradition of clc, has not
been tested.
In that grand tradition it also has bugs :-)
It is probably closer to what the internal code in
Python is actually doing in your test. You might take a look at
it and compare its timings with your original code.
As a final remark, writing tests like this is always problematic.
To do it right you have to arrange the code in a way that only
tests the time of the operation you are measuring while not
giving the optimizer a chance to optimize away your test.
Where as in the real world, of course, the optimiser might be able to do
some of those very tricks to improve it further :-)
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
int main(void) {
char * a = NULL;
char * b = "abc";
char * c = "xyx";
char * buf = 0;
Not an error, but didn't you mean
char * buf = NULL;
Well, no, I meant 0. I never use NULL. The only reason it is in
the code is that I copied the first few lines of the original.
size_t szbuf = 0;
size_t len_a = 0;
size_t len_b = 0;
size_t len_c = 0;
size_t i;
Why a size_t for i? Surely long or unsigned long would be more appropriate.
Appropriate, perhaps, but size_t for indexing through an object
is always right.
size_t t;
Don't you mean clock_t?
I do. I hardly ever use clock so I looked it up. I misread the
standard.
Neither of the above are really relevant to your point though.
len_b = strlen(b);
len_c = strlen(c);
len_a = len_b + len_c + 1;
t = clock();
for (i=0;i<10000000;i++) {
if (len_a > szbuf) {
buf = malloc(len_a);
Memory leak (i.e. the real big bug I spotted). You should have done a
free(buf) first.
Generally speaking, it is a bug, but in this program it is not -
malloc is called exactly once. That said, the code should have a
free.
if (!buf) {
fprintf("Die Earth Pig, you have no memory.\n");
exit(EXIT_FAILURE);
}
szbuf = len_a;
}
strcpy(a,b);
strcpy(a+len_b,c);
How about...
memcpy(a,b,len_b);
memcpy(a+len_b,c,len_c+1);
Alternatively loose the +1 and add a[len_a]='\0';
Good catch. That should be faster.
}
printf(
"You have just wasted %lu clocks of CPU time.\n",
clock()-t);
You should have a cast there. Just after people have been discussing
times when they say you should not have a cast :-)
Well, for reasons that are personally enbarrassing, that code
would have been correct if clock had a size_t return.
exit(EXIT_SUCCESS);--
}
Flash Gordon
If spamming me sent it to smap@xxxxxxxxxxxxxxxxx
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Richard Harter, cri@xxxxxxxx
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
.
- Follow-Ups:
- Re: C Slower than Python?
- From: Flash Gordon
- Re: C Slower than Python?
- References:
- C Slower than Python?
- From: Bartc
- Re: C Slower than Python?
- From: Richard Harter
- Re: C Slower than Python?
- From: Flash Gordon
- C Slower than Python?
- Prev by Date: Re: Memory allignment/type casting question
- Next by Date: Re: How to get array size from a pointer?
- Previous by thread: Re: C Slower than Python?
- Next by thread: Re: C Slower than Python?
- Index(es):
Relevant Pages
|
