https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120422
Robert Dubner <rdubner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdubner at gcc dot gnu.org
--- Comment #2 from Robert Dubner <rdubner at gcc dot gnu.org> ---
(In reply to Kael Franco from comment #0)
> Created attachment 61512 [details]
> Patch
>
> strcmp() and strlen() are used a lot. This patch should reduce both
> functions usage by putting it in local variables. Please check if I missed
> anything.
Karl, I am a bit perplexed as to what problem you are trying to solve, and how
you think your patch is going to solve anything.
If I understand what you are proposing, you want to replace strcmp() calls with
memcmp() calls. A typical example:
- else if( strcmp(function_name, "__gg__when_compiled") == 0 )
+ else if( function_namelen == 19 && memcmp(function_name,
"__gg__when_compiled", 19) == 0 )
I wrote some code that runs on an x86_64 box, with the code compiled by GCC-16.
I'll include it at the end of this comment, so that you can see what I did.
Compiled with -00, one billion 26-character strcmp() comparisons take about 14
seconds and the same number of memcmp comparisons take 13 seconds. Compiled
with -O3, the times are 13 seconds and 11 seconds.
Perhaps if these comparisons were being done deep in an inner loop there would
be more justification for using strlen() to determine the string length and cut
down on the number of comparisons by checking the lengths first.
But the code you are suggesting changing is hardly inner loop. It executes
during compilation -- not during executable execution -- when calls to COBOL
intrinsic functions are being generated.
And my test program suggests that if a COBOL program had 1,000 such calls to
intrinsic functions... Well, each one might do six or so comparisons at about
10 nanoseconds each. The execution time for all of those comparisons would be
about 60 microseconds on my machine.
To my eye, the almost insignificant execution time savings resulting from
changing from strcmp to memcmp is far overwhelmed by the increased complexity
of the memcmp() code.
So, I am not going to sign off on it.
I can't know why you think memcmp() is significantly superior to strcmp().
Perhaps you have seen something in the past, or perhaps you see something on
some other system. I am curious as to why you think so.
Here's the timing program I wrote:
=======
#include <stdio.h>
#include <math.h>
#include <string.h>
#include <time.h>
int main(int argc, char **argv)
{
static const int outer = 1000;
static const int inner = 1000000;
static const char ref[27] = "abcdefghijklmnopqrstuvwxyz";
char ach[27] = "abcdefghijklmnopqrstuvwxyz";
int matches;
time_t start;
time_t end;
srand(0);
matches = 0;
start = time(NULL);
for(int i=0; i<outer; i++)
{
for(int j=0; j<inner; j++)
{
ach[10] = rand();
if( strcmp(ach, ref) == 0 )
{
matches += 1;
}
}
}
end = time(NULL);
printf("strcmp: We have %d matches in %ld seconds\n", matches, end-start);
srand(0);
matches = 0;
start = time(NULL);
for(int i=0; i<outer; i++)
{
for(int j=0; j<inner; j++)
{
ach[10] = rand();
if( memcmp(ach, ref, 26) == 0 )
{
matches += 1;
}
}
}
end = time(NULL);
printf("memcmp: We have %d matches in %ld seconds\n", matches, end-start);
}
