On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote:

> DFS can be excused as he apparently does not know what
> happened.

I didn't know why at first, but Kaz Kylheku explained it: the speed
difference in printf() is due to the implementation used in tcc
(msvcrt.dll) vs that used in mingw gcc.

I tried to find printf() code in the source for gcc 11.1.0, but
couldn't. Do you know how to find it?

On 8/11/2021 2:54 PM, Scott Lurndal wrote:

> I was thinking more along the lines of this:
>
> static char line[12000000];
>
> /**
> * Catenate the words from 'matchwords' into 'line', computing the
> * word length of the longest single word along the way.
> *
> * @param matchwords A vector of character pointers, one for each word
> * @param matchcnt The number of entries in the matchwords vector.
> */
> void
> showresults(char **matchwords, size_t matchcnt)
> {
> size_t longest_word = 0ul;
> char *lp = line;
> char *elp = &line[sizeof(line)];
>
> for(size_t i = 0ul; i < matchcount; i++) {
> char *cp = *matchwords++;
> size_t len = 0ul;
> while ((*cp != '\0') && (lp < elp)) {
> len++;
> *lp++ = *cp++;
> }
> longest_word = max(longest_word, len);
> }
>
> if (lp < elp) *lp++ = '\0';
> else line[sizeof(line)-1] = '\0';
>
> puts(line);
> }
>
> It will silently truncate the output string if 'line'
> isn't large enough to collect all the words in 'matchwords'.
>
> The implementation of max is left to the student.

Well, I'm not a student (in the usual sense) and this isn't homework
(it's just a hobby), but I do appreciate the suggestions and code.

However:

* before constructing the string you have to find the longest word,
which you use to determine how many columns fit in the current width
of the terminal. Each word takes up the same horizontal space:
longest word + 2 blanks

* the output of your code is one long string, with no spaces between the
words and no newlines after every N columns

Substring to search for: catt
backscatterbackscatteredbackscatteringbackscattersbescattercattabucattailcattails...

If your terminal width was 70 characters, the longest word
(backscattering = 14) plus 2 spaces would dictate 4 columns (70/16 =
4.375), and the correct output is:

Substring to search for: catt
backscatter backscattered backscattering backscatters
bescatter cattabu cattail cattails
cattalo cattaloes cattalos cattan
catted catter catteries cattery
catti cattie cattier catties
cattiest cattily cattimandoo cattiness
catting cattish cattishly cattishness
cattle cattlebush cattlefold cattlegate
cattlehide cattleless cattleman cattlemen
cattleship cattleya cattleyak cattleyas
catty cattycorner cattycornered cattyman
cattyphoid copycatted copycatting discatter
overscatter rescattering scatt scatted
scatter scatterable scatteration scatteraway
scatterbrain scatterbrained scatterbrains scattered
scatteredly scatteredness scatterer scatterers
scattergood scattergram scattergraph scattergun
scattering scatteringly scatterings scatterling
scatterment scattermouch scatterplot scatterplots
scatters scattershot scattersite scattery
scattier scattiest scatting scatts
scatty tomcatted tomcatting unscattered
wildcatted wildcatter wildcatting

91 matches for catt in 0.0417 seconds

Bart <bc@freeuk.com> wrote:
> On 11/08/2021 16:06, Scott Lurndal wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >> On Wednesday, 11 August 2021 at 14:52:54 UTC+1, Scott Lurndal wrote:
> >>>
> >>> strcat is almost never the right interface to use. It needs
> >>> to scan the entire string to find the terminal nul-byte before
> >>> appending. As the string gets longer, each strcat takes longer
> >>> than the one before.
> >>>
> >>> Just keep a pointer to the next element and increment the
> >>> pointer each time you add a new element.
> >>>
> >> Most strings are short. Building up a url with strcat is not going to
> >> stress a 3GHz machine. If the strings become huge then, yes, you
> >> need to look at more efficient ways of concatenating them.
> >
> > Building it with snprintf() will be far more flexible and efficient.
> >
> > Every cycle matters.
> >
>
>
> Start with this:
>
> char str[100];
> char* s;
>
> Then a loop like this (all unoptimised code to stop it being optimised
> out of existence):

Again this nonsense with unoptimized benchmarks. Write your
benchmark to realisticaly simulate actual load. If you
have real code and compiler optimizes part of it out of
existence, then this is good things, means that task
can be done simpler/faster than what programmer expected.

> for (int i=0; i<10000000; ++i) {
> strcpy(str,"one ");
> strcat(str,"two ");
> strcat(str,"three ");
> strcat(str,"four ");
> strcat(str,"five");
> }
> puts(str);
>
>
> took 1 second (on my Windows PC running tcc). If use sprintf():
>
> for (int i=0; i<10000000; ++i) {
> s=str;
> s+=sprintf(s,"%s","one ");
> s+=sprintf(s,"%s","two ");
> s+=sprintf(s,"%s","three ");
> s+=sprintf(s,"%s","four ");
> sprintf(s,"%s","five");
> }
> puts(s);
>
> then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1
> seconds. I thought you said every cycle matters?

On may machine, using cc -O2 I get:

time ./b2
five

real 0m0.049s
user 0m0.044s
sys 0m0.004s

Assembler output for the crucial part is:

movl $10000000, %eax #, ivtmp_1
.p2align 4,,10
.p2align 3
..L2:
movl $8293, %ecx #,
movl $32, %esi #,
subl $1, %eax #, ivtmp_1
movw %si, 18+str(%rip) #, MEM[(void *)&str + 14B]
movl $543518319, str(%rip) #, MEM[(void *)&str]
movl $544175988, 4+str(%rip) #, MEM[(void *)&str + 4B]
movl $1701996660, 8+str(%rip) #, MEM[(void *)&str + 8B]
movw %cx, 12+str(%rip) #, MEM[(void *)&str + 8B]
movl $1920298854, 14+str(%rip) #, MEM[(void *)&str + 14B]
movq %rdx, s(%rip) # tmp98, s
movl $1702259046, 19+str(%rip) #, MEM[(void *)&str + 19B]
movb $0, 23+str(%rip) #, MEM[(void *)&str + 19B]
jne .L2 #,
leaq 19+str(%rip), %rdi #,
call puts@PLT

As you see, there are no call to 'sprintf' but the code is dully
doing all interation that you prescribed and putting characters
in buffer. And FYI, there is no string line "one", ..., etc
in the assembly, all string copying is done via integer moves.

BTW: Even with -O0 (or no optimization flag) is see no calls
to 'sprintf', but loop is slower and take 0.246s. This
is 5 times slower than optimized loop above and clearly
shows that unoptimized benchmarks make no sense.

BTW2: You write code using 'sprintf' if you know that compiler
will optimize it (as it did above). Otherwise look what is
fast in compiler you use (your bcc???).

--
Waldek Hebisch

On 11/08/2021 20:55, DFS wrote:
> On 8/11/2021 11:47 AM, Bart wrote:
>
>> Start with this:
>>
>>      char str[100];
>>      char* s;
>>
>> Then a loop like this (all unoptimised code to stop it being optimised
>> out of existence):
>>
>>    for (int i=0; i<10000000; ++i) {
>>        strcpy(str,"one ");
>>        strcat(str,"two ");
>>        strcat(str,"three ");
>>        strcat(str,"four ");
>>        strcat(str,"five");
>>    }
>>    puts(str);
>>
>>
>> took 1 second (on my Windows PC running tcc). If use sprintf():
>>
>>    for (int i=0; i<10000000; ++i) {
>>        s=str;
>>        s+=sprintf(s,"%s","one ");
>>        s+=sprintf(s,"%s","two ");
>>        s+=sprintf(s,"%s","three ");
>>        s+=sprintf(s,"%s","four ");
>>           sprintf(s,"%s","five");
>>    }
>>    puts(s);
>
>
> Did you mean to leave off the s+= in the last line?

Yes; because s is not needed further in that iteration.

(But the last puts should operate on str, not s, which just shows the
last substring.)

>
>
>> then it takes 5.5 seconds. With snprintf() as you suggest, it takes
>> 6.1 seconds. I thought you said every cycle matters?
>
> FWIW: also on Windows
>
> compiled with tcc
> strcat : 0.7s
> sprintf: 6.3s
>
> compiled with Mingw-w64 GCC
> strcat : 0.4s
> sprintf: 4.4s

I was trying to see whether sprintf/snprintf was more efficient than
strcat for concatenating several short strings, as was postulated.

Well, apparently not for strings totalling only 23 characters. Maybe the
differences would be narrower for longer strings, but I tried it with
strings totalling 158 characters, and there was an even wider gap
between the strcat and sprintf loops.

(Note my gcc seems to do a similar trick here as with printf, in using a
version of sprintf which is not the one in msvcrt.dll. One that is about
1/3 faster, but is still significantly slower than strcat for this test.)

This is really not surprising, since strcat can implemented much more
simply than sprintf.

I tried to find a crossover point, a total length of string at which an
sprintf loop was faster than a strcat one, and there wasn't one! At
least not under a 2.5MB total string anyway.

DFS <nospam@dfs.com> writes:
>On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote:
>
>> DFS can be excused as he apparently does not know what
>> happened.
>
>I didn't know why at first, but Kaz Kylheku explained it: the speed
>difference in printf() is due to the implementation used in tcc
>(msvcrt.dll) vs that used in mingw gcc.
>
>I tried to find printf() code in the source for gcc 11.1.0, but
>couldn't. Do you know how to find it?

As Keith has attempted to explain to Bart, repeatedly, printf is
not part of the compiler. It is just a library function called
like any other function.

The source for printf will be available in the source package
corresponding to the library that your application links with.

If it's msvcrt.dll, you'll need to ask Microsoft for the source.

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf.c;h=1a98662f9321fae6b04735b99e06a89bef931d51;hb=HEAD

On 11/08/2021 21:47, David Brown wrote:
> On 11/08/2021 17:47, Bart wrote:

>> Start with this:
>>
>>     char str[100];
>>     char* s;
>>
>> Then a loop like this (all unoptimised code to stop it being optimised
>> out of existence):
>
> As you well know, timing unoptimised code is an utterly pointless
> exercise. You need to do something to make sure the operations are
> carried out, such as judicious use of volatile, or using "global"
> variables rather than local ones. Disabling optimisation is like
> comparing the speed of cars while forcing them to remain in first gear.

No, it's ensuring that all of them follow the same route. Otherwise each
will find their own shortcuts, or may not bother going anywhere at all
if they see they're simply going to end up back home anyway.

That's helpful if you're trying to compare different cars or different
routes.

>>
>>   for (int i=0; i<10000000; ++i) {
>>       strcpy(str,"one ");
>>       strcat(str,"two ");
>>       strcat(str,"three ");
>>       strcat(str,"four ");
>>       strcat(str,"five");
>>   }
>>   puts(str);
>>
>>
>> took 1 second (on my Windows PC running tcc). If use sprintf():
>>
>>   for (int i=0; i<10000000; ++i) {
>>       s=str;
>>       s+=sprintf(s,"%s","one ");
>>       s+=sprintf(s,"%s","two ");
>>       s+=sprintf(s,"%s","three ");
>>       s+=sprintf(s,"%s","four ");
>>          sprintf(s,"%s","five");
>>   }
>>   puts(s);
>>
>> then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1
>> seconds. I thought you said every cycle matters?
>>
>
> <https://godbolt.org/z/954eccfsM>
>
> gcc (and I really mean gcc - no libraries are involved) generates
> identical code in both cases, and so I would assume (without testing)
> that the speed is the same.

Yeah, but that's taking my test literally, with string literals that the
compiler knows about.

It's possible that a call like sprintf(s, "%s", t) could be optimised
into a strcpy call and even inlined, without needing to know what t is,
however that is not what I'm seeing.

On the following revised test, the string to be concatenated is hidden
from the compiler. The sprintf loop is always slower than the strcat
loop, even using gcc-O3 and clang-O3 and cl /O2.

Maybe on your super-duper computer with link time optimisations and
such, it will be different. But this is what I'm observing with on Windows:

------------------------------------
c.c
------------------------------------

#include <stdio.h>
#include <time.h>
#include <string.h>

extern char* getstr(void);

char str[100000];

int main(void) {
char* s;
int n=1000000;
int t=clock();

for (int i=0; i<n; ++i) {
strcpy(str,getstr());
strcat(str,getstr());
strcat(str,getstr());
strcat(str,getstr());
strcat(str,getstr());
}
puts(str);
printf("%d\n",(int)strlen(str));

printf("time1 %d\n",(int)(clock()-t));
t=clock();

for (int i=0; i<n; ++i) {
s=str;
s+=sprintf(s,"%s",getstr());
s+=sprintf(s,"%s",getstr());
s+=sprintf(s,"%s",getstr());
s+=sprintf(s,"%s",getstr());
sprintf(s,"%s",getstr());
}
puts(str);

printf("%d\n",(int)strlen(str));
printf("time2 %d\n",(int)(clock()-t));

puts("");

}

------------------------------------
d.c
------------------------------------
char* getstr(void){return "ABCDEFGHIJKLMNOPQRSTUVWXYZ ";}

Build as:

gcc -O3 c.c d.c

Run as:

a # or ./a.out on certain OSes

This is what I get on Windows:

------------------------------------------------
C:\c>gcc --version
gcc (tdm64-1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
<snip>

C:\c>gcc -O3 c.c d.c

C:\c>a
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRS
TUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
135
time1 144
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRS
TUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
135
time2 733
------------------------------------------------

clang -O3 gives 196/714.
DMC -o gives 421/1108.
lc -O gives 457/3155.
cl /2 gives 426/742
tcc gives 187/1438
bcc gives 208/1357
gcc -O0 gives 144/865

Finally this loop in my scripting language to do the same task:

function getstr=
"ABCDEFGHIJKLMNOPQRSTUVWXYZ "
end

to 1 million do
s:=getstr()
s+:=getstr()
s+:=getstr()
s+:=getstr()
s+:=getstr()
od

println s
println s.len

took 680ms; faster than gcc-O3 using sprintf.

Someone asserted that using sprintf to do this stuff was more efficient
than strcat; I disagreed. My findings suggested that strcat is faster.

You say your tests (on my program with fixed strings) would have them be
the same speed. So when is sprintf actually faster?

On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 11/08/2021 16:06, Scott Lurndal wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> On Wednesday, 11 August 2021 at 14:52:54 UTC+1, Scott Lurndal wrote:
>>>>>
>>>>> strcat is almost never the right interface to use. It needs
>>>>> to scan the entire string to find the terminal nul-byte before
>>>>> appending. As the string gets longer, each strcat takes longer
>>>>> than the one before.
>>>>>
>>>>> Just keep a pointer to the next element and increment the
>>>>> pointer each time you add a new element.
>>>>>
>>>> Most strings are short. Building up a url with strcat is not going to
>>>> stress a 3GHz machine. If the strings become huge then, yes, you
>>>> need to look at more efficient ways of concatenating them.
>>>
>>> Building it with snprintf() will be far more flexible and efficient.
>>>
>>> Every cycle matters.
>>>
>>
>>
>> Start with this:
>>
>> char str[100];
>> char* s;
>>
>> Then a loop like this (all unoptimised code to stop it being optimised
>> out of existence):
>
> Again this nonsense with unoptimized benchmarks. Write your
> benchmark to realisticaly simulate actual load. If you
> have real code and compiler optimizes part of it out of
> existence, then this is good things, means that task
> can be done simpler/faster than what programmer expected.

No it is a bad thing. You want such a test to tell you a general thing:
is strcat to concatenate multiple short strings generally better than
multiple calls to sprintf?

That it can optimise both away in this specific, silly benchmark tells
you nothing.

See my reply to David Brown a few minutes ago where I did enable
optimisation on my compilers, with a revised test.

>> for (int i=0; i<10000000; ++i) {
>> strcpy(str,"one ");
>> strcat(str,"two ");
>> strcat(str,"three ");
>> strcat(str,"four ");
>> strcat(str,"five");
>> }
>> puts(str);
>>
>>
>> took 1 second (on my Windows PC running tcc). If use sprintf():
>>
>> for (int i=0; i<10000000; ++i) {
>> s=str;
>> s+=sprintf(s,"%s","one ");
>> s+=sprintf(s,"%s","two ");
>> s+=sprintf(s,"%s","three ");
>> s+=sprintf(s,"%s","four ");
>> sprintf(s,"%s","five");
>> }
>> puts(s);
>>
>> then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1
>> seconds. I thought you said every cycle matters?
>
> On may machine, using cc -O2 I get:
>
> time ./b2
> five
>
> real 0m0.049s
> user 0m0.044s
> sys 0m0.004s
>
> Assembler output for the crucial part is:
>
> movl $10000000, %eax #, ivtmp_1
> .p2align 4,,10
> .p2align 3
> .L2:
> movl $8293, %ecx #,
> movl $32, %esi #,
> subl $1, %eax #, ivtmp_1
> movw %si, 18+str(%rip) #, MEM[(void *)&str + 14B]
> movl $543518319, str(%rip) #, MEM[(void *)&str]
> movl $544175988, 4+str(%rip) #, MEM[(void *)&str + 4B]
> movl $1701996660, 8+str(%rip) #, MEM[(void *)&str + 8B]
> movw %cx, 12+str(%rip) #, MEM[(void *)&str + 8B]
> movl $1920298854, 14+str(%rip) #, MEM[(void *)&str + 14B]
> movq %rdx, s(%rip) # tmp98, s
> movl $1702259046, 19+str(%rip) #, MEM[(void *)&str + 19B]
> movb $0, 23+str(%rip) #, MEM[(void *)&str + 19B]
> jne .L2 #,
> leaq 19+str(%rip), %rdi #,
> call puts@PLT

This is what I get for the c.c module of my last past, with gcc -O3 -S
(comments and other noise deleted):

printf:
push r12 #
push rbx #
sub rsp, 56 #,
lea rbx, 88[rsp] # tmp86,
mov QWORD PTR 88[rsp], rdx #,
mov r12, rcx # __format, tmp89
mov ecx, 1 #,
mov QWORD PTR 96[rsp], r8 #,
mov QWORD PTR 104[rsp], r9 #,
mov QWORD PTR 40[rsp], rbx # MEM[(char * *)&__local_argv], tmp86
call [QWORD PTR __imp___acrt_iob_func[rip]] #
mov r8, rbx #, tmp86
mov rdx, r12 #, __format
mov rcx, rax # _2, tmp90
call __mingw_vfprintf #
add rsp, 56 #,
pop rbx #
pop r12 #
ret
..LC0:
sprintf.constprop.0:
sub rsp, 56 #,
lea rdx, .LC0[rip] #,
lea rcx, str[rip] #,
mov QWORD PTR 80[rsp], r8 #,
lea r8, 80[rsp] # tmp86,
mov QWORD PTR 88[rsp], r9 #,
mov QWORD PTR 40[rsp], r8 # MEM[(char * *)&__local_argv], tmp86
call __mingw_vsprintf #
add rsp, 56 #,
ret
sprintf.constprop.1:
sub rsp, 56 #,
lea rdx, .LC0[rip] #,
mov QWORD PTR 80[rsp], r8 #,
lea r8, 80[rsp] # tmp86,
mov QWORD PTR 88[rsp], r9 #,
mov QWORD PTR 40[rsp], r8 # MEM[(char * *)&__local_argv], tmp86
call __mingw_vsprintf #
add rsp, 56 #,
ret
..LC1:
.ascii "%d\12\0"
..LC2:
.ascii "time1 %d\12\0"
..LC3:
.ascii "time2 %d\12\0"
..LC4:
.ascii "\0"
.section .text.startup,"x"
main:
push r13 #
push r12 #
push rbp #
push rdi #
push rsi #
push rbx #
sub rsp, 40 #,
mov esi, 1000000 # ivtmp_24,
lea rbx, str[rip] # tmp134,
call __main #
call clock #
mov edi, eax # t, tmp135
..L6:
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _1, tmp136
call strcpy #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _2, tmp137
call strcat #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _3, tmp138
call strcat #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _4, tmp139
call strcat #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _5, tmp140
call strcat #
sub esi, 1 # ivtmp_24,
jne .L6 #,
lea rcx, str[rip] #,
lea rbp, str[rip] # tmp131,
call puts #
lea rcx, str[rip] #,
lea rsi, .LC0[rip] # tmp132,
call strlen #
lea rcx, .LC1[rip] #,
mov rdx, rax # tmp118, tmp141
call printf #
call clock #
lea rcx, .LC2[rip] #,
sub eax, edi # tmp142, t
mov edi, 1000000 # ivtmp_23,
mov edx, eax # tmp120, tmp142
call printf #
call clock #
mov r13d, eax # t, tmp143
..L7:
call getstr #
mov rdx, rsi #, tmp132
mov rcx, rbp #, tmp131
mov r8, rax # tmp144,
call sprintf.constprop.0 #
movsx rbx, eax # _43, tmp145
call getstr #
add rbx, rbp # s, tmp131
mov rdx, rsi #, tmp132
mov rcx, rbx #, s
mov r8, rax # tmp146,
call sprintf.constprop.1 #
cdqe
add rbx, rax # s, _47
call getstr #
mov rcx, rbx #, s
mov rdx, rsi #, tmp132
mov r8, rax # tmp148,
call sprintf.constprop.1 #
cdqe
add rbx, rax # s, _51
call getstr #
mov rdx, rsi #, tmp132
mov rcx, rbx #, s
mov r8, rax # tmp150,
call sprintf.constprop.1 #
movsx r12, eax # _55, tmp151
call getstr #
add r12, rbx # s, s
mov rdx, rsi #, tmp132
mov r8, rax # tmp152,
mov rcx, r12 #, s
call sprintf.constprop.1 #
sub edi, 1 # ivtmp_23,
jne .L7 #,
lea rcx, str[rip] #,
call puts #
lea rcx, str[rip] #,
call strlen #
lea rcx, .LC1[rip] #,
mov rdx, rax # tmp127, tmp153
call printf #
call clock #
lea rcx, .LC3[rip] #,
sub eax, r13d # tmp154, t
mov edx, eax # tmp129, tmp154
call printf #
lea rcx, .LC4[rip] #,
call puts #
xor eax, eax #
add rsp, 40 #,
pop rbx #
pop rsi #
pop rdi #
pop rbp #
pop r12 #
pop r13 #
ret
str:
.space 100000
.ident "GCC: (tdm64-1) 10.3.0"

On 11/08/2021 23:13, Bart wrote:
> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
>> Bart <bc@freeuk.com> wrote:

> This is what I get for the c.c module of my last past, with gcc -O3 -S
> (comments and other noise deleted):
>
> printf:
>     push    r12  #
....
> I guess this is again either all my fault for not knowing what options I
> need to make the code as sweet as yours, or Windows' for being such a
> crap OS, or both.

Better is this godbolt link to that same module (using gcc x64 11.2):

https://godbolt.org/z/Yz9vEzhaY

The displayed code is a lot cleaner and clearer. I'm not even sure what
OS it's for! (It doesn't look like Win64, so at least you can't be
Windows-bashing with it.)

However there are explicit calls to both strcat and sprintf. Changing
the latter to snprintf makes it even longer (not sure how that helps
save cycles as SL said).

On 8/11/2021 5:33 PM, Scott Lurndal wrote:
> DFS <nospam@dfs.com> writes:
>> On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote:
>>
>>> DFS can be excused as he apparently does not know what
>>> happened.
>>
>> I didn't know why at first, but Kaz Kylheku explained it: the speed
>> difference in printf() is due to the implementation used in tcc
>> (msvcrt.dll) vs that used in mingw gcc.
>>
>> I tried to find printf() code in the source for gcc 11.1.0, but
>> couldn't. Do you know how to find it?
>
> As Keith has attempted to explain to Bart, repeatedly, printf is
> not part of the compiler. It is just a library function called
> like any other function.
>
> The source for printf will be available in the source package
> corresponding to the library that your application links with.
>
> If it's msvcrt.dll, you'll need to ask Microsoft for the source.
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf.c;h=1a98662f9321fae6b04735b99e06a89bef931d51;hb=HEAD

Thanks

Bart <bc@freeuk.com> wrote:
> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >> On 11/08/2021 16:06, Scott Lurndal wrote:
> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>> On Wednesday, 11 August 2021 at 14:52:54 UTC+1, Scott Lurndal wrote:
> >>>>>
> >>>>> strcat is almost never the right interface to use. It needs
> >>>>> to scan the entire string to find the terminal nul-byte before
> >>>>> appending. As the string gets longer, each strcat takes longer
> >>>>> than the one before.
> >>>>>
> >>>>> Just keep a pointer to the next element and increment the
> >>>>> pointer each time you add a new element.
> >>>>>
> >>>> Most strings are short. Building up a url with strcat is not going to
> >>>> stress a 3GHz machine. If the strings become huge then, yes, you
> >>>> need to look at more efficient ways of concatenating them.
> >>>
> >>> Building it with snprintf() will be far more flexible and efficient.
> >>>
> >>> Every cycle matters.
> >>>
> >>
> >>
> >> Start with this:
> >>
> >> char str[100];
> >> char* s;
> >>
> >> Then a loop like this (all unoptimised code to stop it being optimised
> >> out of existence):
> >
> > Again this nonsense with unoptimized benchmarks. Write your
> > benchmark to realisticaly simulate actual load. If you
> > have real code and compiler optimizes part of it out of
> > existence, then this is good things, means that task
> > can be done simpler/faster than what programmer expected.
>
> No it is a bad thing. You want such a test to tell you a general thing:
> is strcat to concatenate multiple short strings generally better than
> multiple calls to sprintf?

AFAICS DFS result showed than on his machine sprintf was
worse. Note I was not the person who advocated use of
'sprintf' -- without testing it is potential trap (as
you and DFS showed). If one wants highest speed, IIRC
BSD folks had a version of strcpy that returned pointer
to destination. This could be fastest, but is nonstandard
so less chance for optimized version in compiler.

> That it can optimise both away in this specific, silly benchmark tells
> you nothing.

Benchmark tells you that compiler can inline very efficient
version of 'sprintf' (and 'strcat') for constant string. This
is important special case that is frequent in practice.

> See my reply to David Brown a few minutes ago where I did enable
> optimisation on my compilers, with a revised test.

Yes, that is valid benchmark. I came to similar benchmark
with similar result, for variable argument 'sprintf' goes
to library routine and at least for short strings is
much slower than 'strcat' or 'strcpy' and 'strlen.
On my machine 'sprintf', 'strcat' and 'strcpy' eventually
arrive to hairy SSE code, which in principle could be
quite fast for long strings, but has significant cost
for short strings (still, library 'strlen' is faster
than inline 'rep scanb' on my machine).

> I guess this is again either all my fault for not knowing what options I
> need to make the code as sweet as yours, or Windows' for being such a
> crap OS, or both.

Well, you used variable strings. In principle gcc could have
an optimized version of 'sprintf' for such case, but it seems
that your or my gcc does not have it. However, the point is
that without turning on optimization on you do not know what
tricks gcc will use to speed up (or not :( ) your program.

--
Waldek Hebisch

On 12/08/2021 00:00, Bart wrote:
> On 11/08/2021 21:47, David Brown wrote:
>> On 11/08/2021 17:47, Bart wrote:
>
>>> Start with this:
>>>
>>>      char str[100];
>>>      char* s;
>>>
>>> Then a loop like this (all unoptimised code to stop it being optimised
>>> out of existence):
>>
>> As you well know, timing unoptimised code is an utterly pointless
>> exercise.  You need to do something to make sure the operations are
>> carried out, such as judicious use of volatile, or using "global"
>> variables rather than local ones.  Disabling optimisation is like
>> comparing the speed of cars while forcing them to remain in first gear.
>
> No, it's ensuring that all of them follow the same route. Otherwise each
> will find their own shortcuts, or may not bother going anywhere at all
> if they see they're simply going to end up back home anyway.

How many years have you been playing this game? Compilers can do what
they want with the code - whatever flags you give them. Compilers can
and do make optimisations despite your attempts to say "unoptimised".
There is no such thing as "unoptimised" code, just as there is no such
thing as "optimised" code (except in very small test cases). There is
only a question of applying different types of transforms and passes,
and of "trying harder" or not. You don't know the passes and transforms
used by any particular compiler under any given circumstance with any
given piece of code. (I believe that applies even to the tools you
wrote yourself, as you only seem to know what they do by trial and error.)

And when testing the speed of something, you give them a fair chance -
you don't cripple them first.

If you understood more than just your personally self-limited subset of
C, perhaps read a bit of the standards, perhaps listened a bit when
others explain things to you (instead of merely whining about it all
being too complicated or not the way /you/ would have done it), you'd
know this. And you would know how to write code in a way that you can
test the speed of constructs /without/ throwing the baby out with the
bathwater.

>>
>> <https://godbolt.org/z/954eccfsM>
>>
>> gcc (and I really mean gcc - no libraries are involved) generates
>> identical code in both cases, and so I would assume (without testing)
>> that the speed is the same.
>
> Yeah, but that's taking my test literally, with string literals that the
> compiler knows about.
>

Yes. You gave what you thought was a test, and called a test, and I
showed that it is not only irrelevant, but it shows that you were wrong.

Now, /in general/ I would expect strcpy() and other related functions to
be faster than using sprintf or snprintf. I would also expect them to
be inlined much better. But in the particular case of your test, there
is no difference. And in the particular cases Scott had been
discussing, I imagine there are other factors that also mean sprintf is
a more efficient option. (I have no idea what those circumstances might
be - you'd have to ask him - but I doubt if Scott was thinking of code
like yours.)

> It's possible that a call like sprintf(s, "%s", t) could be optimised
> into a strcpy call and even inlined, without needing to know what t is,
> however that is not what I'm seeing.
>
> On the following revised test, the string to be concatenated is hidden
> from the compiler. The sprintf loop is always slower than the strcat
> loop, even using gcc-O3 and clang-O3 and cl /O2.
>
> Maybe on your super-duper computer with link time optimisations and
> such, it will be different. But this is what I'm observing with on Windows:
>

I don't really care what you are getting "on Windows" - you don't know
what you are testing, and don't even understand that you don't know what
you are testing, so the details don't matter. You are not comparing
apples with apples - you are not even comparing apples with oranges.
You are comparing a mystery fruit with another mystery fruit which might
or might not be the same kind.

That is why I used godbolt for looking at the details - there we /do/
know what is being tested, with the results being assembly that we can
compare, dependent on the source code, the compiler chosen, and the
flags - but not libraries, OS's, computers, or any other messy details.
(Obviously such code generation comparisons only work for some kinds of
testing, but they are vastly better than "I tried using some toolchain I
have, but I don't know what it is, how it works or how to use it".)

Your new test code does stop gcc (trunk version, which is a development
version of gcc 12) from turning the sprintf into strcat. Without
knowing any other details, I would expect the sprintf version to be slower.

>
> Someone asserted that using sprintf to do this stuff was more efficient
> than strcat; I disagreed. My findings suggested that strcat is faster.
>

All your findings show is that for your setup and your test programs,
strcat is faster. Neither your setup nor your test program are
realistic for real coding - certainly not in circumstances where the
programmer understands about execution speed and in a program for which
that is important.

Don't get me wrong here - I fully expect that for a simple short test
string, strcat will be faster than sprintf. I just don't think you have
thought about any possible complicating circumstances or effects that
occur in the real programming world, before leaping off with another
"test" program in your eagerness to "prove" someone wrong (and then,
inevitably, to throw in some code in one of your personal languages to
"prove" that it is "better" than C).

> You say your tests (on my program with fixed strings) would have them be
> the same speed. So when is sprintf actually faster?

Since I am not making the claim about sprintf and strcat speeds, and
have not used them in a way that lets me judge their relative speeds in
different circumstances, I can only make some guesses as to when sprintf
might be faster.

First, note that a library implementation of sprintf could quite happily
have an optimisation that first checks if the format string is "%s" and
has dedicated handling for that rather common case. This would mean
sprintf, used like this, would be about as fast as strcpy.

Second, note that if you are dealing with very long strings, then
strcat() must traverse the entire string so far in order to find the
end. The sprintf version does not. As the size of the strings grow,
this traversal will totally dominate the timing, making sprintf faster.

(Even more efficient would be functions like strlcat, or the other
variations that have been made over the years that return more useful
results than strcat that avoid the need to re-establish the length of
the string every time. It would be nice to have seen some of these
standardised and codified in the C standards.)

On 12/08/2021 00:30, Bart wrote:
> On 11/08/2021 23:13, Bart wrote:
>> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
>>> Bart <bc@freeuk.com> wrote:
>
>> This is what I get for the c.c module of my last past, with gcc -O3 -S
>> (comments and other noise deleted):
>>
>> printf:
>>      push    r12  #
> ...
>> I guess this is again either all my fault for not knowing what options
>> I need to make the code as sweet as yours, or Windows' for being such
>> a crap OS, or both.
>
> Better is this godbolt link to that same module (using gcc x64 11.2):
>
> https://godbolt.org/z/Yz9vEzhaY
>
> The displayed code is a lot cleaner and clearer.

It is not "cleaner and clearer" - it is much messier because you have
put everything into one big function combined with clock timing stuff
and outputs. To make code "clean and clear", structure it properly -
put different things in different functions, and then it is possible to
see the relevant differences in the results.

> I'm not even sure what
> OS it's for! (It doesn't look like Win64, so at least you can't be
> Windows-bashing with it.)

You display your ignorance proudly, as though it were a medal. Bizarre.

If you look at the list of compilers available, it is quickly apparent
that this particular compiler is native gcc on x86 Linux. Other options
available include MSVC running under Wine, and various cross-compilers.

No matter - one of the points of this kind of test is that it is looking
at the compiler output alone, with little or no OS-specific details.

>
> However there are explicit calls to both strcat and sprintf. Changing
> the latter to snprintf makes it even longer (not sure how that helps
> save cycles as SL said).

Yes indeed - after adding the "getstr" to your code, gcc no longer
optimises the code the same way.

On 12/08/2021 09:29, David Brown wrote:
> On 12/08/2021 00:00, Bart wrote:

> Yes. You gave what you thought was a test, and called a test, and I
> showed that it is not only irrelevant, but it shows that you were wrong.
>
>
> Now, /in general/ I would expect strcpy() and other related functions to
> be faster than using sprintf or snprintf. I would also expect them to
> be inlined much better.

Malcolm suggested that use of strcat was fine for assembling short
strings, SL suggested using snprintf every time because 'every cycle
counts'.

However, if compilers can optimise that aggressively, why don't they
also optimise strcat into sprintf if it is actually faster?

My assumption was that in real code, strcat and sprintf are actually
being called as functions. Specifically, as functions in an internal
library that is already compiled.

In that case, you want to know whether CALLING strcat in a loop was
faster or slower than calling sprintf in a loop.

One way of ensuring that optimisers don't interfere with such code (by
ending up not calling a function, or not doing anything) is to turn off
optimisation. Or by writing a more elaborate test, but even then you can
never be sure what a compiler might sneakily be doing to invalid your tests.

As it turned out, my more elaborate, optimised test confirmed the
results of the simpler, non-optimised one - strcat loops were faster.

(Another way of doing it is to call strcat and sprintf via the FFI of
another language, eg. mine, which also confirmed it.)

>> It's possible that a call like sprintf(s, "%s", t) could be optimised
>> into a strcpy call and even inlined, without needing to know what t is,
>> however that is not what I'm seeing.
>>
>> On the following revised test, the string to be concatenated is hidden
>> from the compiler. The sprintf loop is always slower than the strcat
>> loop, even using gcc-O3 and clang-O3 and cl /O2.
>>
>> Maybe on your super-duper computer with link time optimisations and
>> such, it will be different. But this is what I'm observing with on Windows:
>>
>
> I don't really care what you are getting "on Windows" - you don't know
> what you are testing, and don't even understand that you don't know what
> you are testing, so the details don't matter. You are not comparing
> apples with apples - you are not even comparing apples with oranges.
> You are comparing a mystery fruit with another mystery fruit which might
> or might not be the same kind.
>
> That is why I used godbolt for looking at the details - there we /do/
> know what is being tested,

That doesn't tell you much about non-optimising compilers, or attempts
to call C functions from other languages, which is MY interest.

You may also be distributing C source and don't know what someone is
going to do with it.

The optimisations are just a bonus when you eventually get around to
using an optimising C compiler in some cases, but your program must work
adequately without that.

So please accept that we have different aims and different interests.

> Don't get me wrong here - I fully expect that for a simple short test
> string, strcat will be faster than sprintf.

Try this version of getstr():

char* getstr(void){
enum {N=10000};
static char* s=NULL;

if (s) return s;

s=malloc(N+1);
memset(s,'A',N);
s[N]=0;
return s;
}

You may need to adjust the timing loop in the other module for fewer
iterations, and ensure the str[] array is big enough for 5 copies. (And
maybe comment out the bits that print the strings!)

You might be surprised at the results.

(With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
440/2320 msec - sprintf was still several times slower.)

> I just don't think you have
> thought about any possible complicating circumstances or effects that
> occur in the real programming world, before leaping off with another
> "test" program in your eagerness to "prove" someone wrong (and then,
> inevitably, to throw in some code in one of your personal languages to
> "prove" that it is "better" than C).

No, I was just fed up with Scott Lurndal treating me with contempt. He
said something I'd challenged then refused to back it up, claiming he
was too busy.

That interpreted code (which uses counted strings) was as fast as the C
loop using sprintf was a bit of a surprise to me, but I found it
interesting to share.

If you don't like me using my personal languge, here it is in Python:

--------------------
def getstr():
return "ABCDEFGHIJKLMNOPQRSTUVWXYZ "

for i in range(1000000):
s=""
s+=getstr()
s+=getstr()
s+=getstr()
s+=getstr()
s+=getstr()

print (s)
print (len(s))
--------------------

This took 1.8 seconds with CPython (1/2 to 1/3 the speed of the sprintf
loop) and 0.2 seconds with PyPy (several times the speed of the C). This
language uses counted strings too.

On 12/08/2021 09:39, David Brown wrote:
> On 12/08/2021 00:30, Bart wrote:
>> On 11/08/2021 23:13, Bart wrote:
>>> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
>>>> Bart <bc@freeuk.com> wrote:
>>
>>> This is what I get for the c.c module of my last past, with gcc -O3 -S
>>> (comments and other noise deleted):
>>>
>>> printf:
>>>      push    r12  #
>> ...
>>> I guess this is again either all my fault for not knowing what options
>>> I need to make the code as sweet as yours, or Windows' for being such
>>> a crap OS, or both.
>>
>> Better is this godbolt link to that same module (using gcc x64 11.2):
>>
>> https://godbolt.org/z/Yz9vEzhaY
>>
>> The displayed code is a lot cleaner and clearer.
>
> It is not "cleaner and clearer" - it is much messier because you have
> put everything into one big function combined with clock timing stuff
> and outputs.

I was talking about the assembly code

To make code "clean and clear", structure it properly -
> put different things in different functions, and then it is possible to
> see the relevant differences in the results.
>
>> I'm not even sure what
>> OS it's for! (It doesn't look like Win64, so at least you can't be
>> Windows-bashing with it.)
>
> You display your ignorance proudly, as though it were a medal. Bizarre.

Ignorance about what? I genuinely don't know what machines these
compilers target, because it doesn't tell you. Not for GCC x64 anyway.

Yes, I can see from the call sequences that it is not Win64 ABI, and is
probably 'SYS V', but that's about it.

The important thing is that it shows more realistic code than you and
antispam posted. It should have been clear that that my original code
could collapse down to nothing if optimised, something I even said would
happen.

You both should instead have put together a more solid test that
compared the merits of strcat and sprintf that would hold up better.

Instead you are just more interested in bart-bashing points.

And in the end, which of those two functions is better; what conclusion
have you reached by trashing my own test? You vaguely suggest that
sprintf is better, but where's your benchmark?

On 12/08/2021 13:10, Bart wrote:
> On 12/08/2021 09:29, David Brown wrote:
>> On 12/08/2021 00:00, Bart wrote:
>
>> Yes.  You gave what you thought was a test, and called a test, and I
>> showed that it is not only irrelevant, but it shows that you were wrong.
>>
>>
>> Now, /in general/ I would expect strcpy() and other related functions to
>> be faster than using sprintf or snprintf.  I would also expect them to
>> be inlined much better.
>
> Malcolm suggested that use of strcat was fine for assembling short
> strings, SL suggested using snprintf every time because 'every cycle
> counts'.
>

Other people can answer for their own opinions and comments.

> However, if compilers can optimise that aggressively, why don't they
> also optimise strcat into sprintf if it is actually faster?
>

Did you read what I wrote? It is likely, as far as I can guess, that
sprintf will be faster than strcat in cases where you have long strings
and where the return value from sprintf can be used to avoid re-scanning
strings to find their endpoints. I would imagine that is a little too
niche for optimisations, and would also be dependent on the library
implementation. This makes it very different from optimising library
calls into inlined code or clearly simpler functions.

There are always limits to optimisation - sometimes an optimisation is
theoretically possible, but a given compiler doesn't implement it. And
there are often cases where an optimisation might seem to be obviously
valid, when there are actually good reasons why the compiler can't be
sure the optimisation is correct. The folks that write high-end
compilers are really good at making sure there are no unwarranted
assumptions in their optimisations.

> My assumption was that in real code, strcat and sprintf are actually
> being called as functions. Specifically, as functions in an internal
> library that is already compiled.
>

That was an assumption - it was not a requirement, either from Scott's
posts or from your own test code. If your statements rely on that kind
of thing, say so.

> In that case, you want to know whether CALLING strcat in a loop was
> faster or slower than calling sprintf in a loop.
>
> One way of ensuring that optimisers don't interfere with such code (by
> ending up not calling a function, or not doing anything) is to turn off
> optimisation. Or by writing a more elaborate test, but even then you can
> never be sure what a compiler might sneakily be doing to invalid your
> tests.

Turning off optimisations is a silly way to do this - it is a silly way
to do anything, really. But you didn't learn that the last 99 times it
has come up, so I don't expect you to have a light-bulb moment here either.

>
> As it turned out, my more elaborate, optimised test confirmed the
> results of the simpler, non-optimised one - strcat loops were faster.
>

No one disputes the expected relative speeds of typical library
implementations of strcat and sprintf when dealing with short strings in
code such as these examples. That does not make your tests helpful or
relevant.

>
>>> It's possible that a call like sprintf(s, "%s", t) could be optimised
>>> into a strcpy call and even inlined, without needing to know what t is,
>>> however that is not what I'm seeing.
>>>
>>> On the following revised test, the string to be concatenated is hidden
>>> from the compiler. The sprintf loop is always slower than the strcat
>>> loop, even using gcc-O3 and clang-O3 and cl /O2.
>>>
>>> Maybe on your super-duper computer with link time optimisations and
>>> such, it will be different. But this is what I'm observing with on
>>> Windows:
>>>
>>
>> I don't really care what you are getting "on Windows" - you don't know
>> what you are testing, and don't even understand that you don't know what
>> you are testing, so the details don't matter.  You are not comparing
>> apples with apples - you are not even comparing apples with oranges.
>> You are comparing a mystery fruit with another mystery fruit which might
>> or might not be the same kind.
>>
>> That is why I used godbolt for looking at the details - there we /do/
>> know what is being tested,
>
> That doesn't tell you much about non-optimising compilers, or attempts
> to call C functions from other languages, which is MY interest.

No one (sane and knowledgable) cares about the speed of code generated
by non-optimising compilers, or compilers with the optimisation turned off.

No one (sane and knowledgable) who calls library functions from another
language cares about the results of a compiler running test code - they
care about the /library/, its implementation, and efficiency.

So if you are interested in the performance of strcat and sprintf when
used from a different language, look at the library, not the C compiler.
Examine and test things that are /relevant/, either to the discussions
here or relevant to your own interests.

>
> You may also be distributing C source and don't know what someone is
> going to do with it.
>
> The optimisations are just a bonus when you eventually get around to
> using an optimising C compiler in some cases, but your program must work
> adequately without that.
>
> So please accept that we have different aims and different interests.
>
>> Don't get me wrong here - I fully expect that for a simple short test
>> string, strcat will be faster than sprintf.
>
> Try this version of getstr():
>
>  char* getstr(void){
>      enum {N=10000};
>      static char* s=NULL;
>
>      if (s) return s;
>
>      s=malloc(N+1);
>      memset(s,'A',N);
>      s[N]=0;
>      return s;
>  }
>
> You may need to adjust the timing loop in the other module for fewer
> iterations, and ensure the str[] array is big enough for 5 copies. (And
> maybe comment out the bits that print the strings!)
>
> You might be surprised at the results.
>
> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
> 440/2320 msec - sprintf was still several times slower.)
>

I haven't claimed that sprintf is faster - I merely gave a possible
explanation why it might be faster, for some situations.

But looking at the code generated for your latest change, I notice
something vital - gcc (on godbolt) is converting many of the "strcat"
calls into "stpcpy" calls. stpcpy is not a standard C function, but is
(AFAICS) in POSIX standards. It is like strcpy, except it returns a
pointer to the end of the combined string - and is thus vastly more
efficient in this case.

Try your timings with "-std=c99", which stops gcc from using functions
that are not in the C standard (and, obviously, not in the source code).

There is a suggestion to add stpcpy (and spncpy) to the C standards:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2352.htm>

(These threads do sometimes end up revealing interesting things.)

>
>> I just don't think you have
>> thought about any possible complicating circumstances or effects that
>> occur in the real programming world, before leaping off with another
>> "test" program in your eagerness to "prove" someone wrong (and then,
>> inevitably, to throw in some code in one of your personal languages to
>> "prove" that it is "better" than C).
>
> No, I was just fed up with Scott Lurndal treating me with contempt. He
> said something I'd challenged then refused to back it up, claiming he
> was too busy.
>
> That interpreted code (which uses counted strings) was as fast as the C
> loop using sprintf was a bit of a surprise to me, but I found it
> interesting to share.
>
> If you don't like me using my personal languge, here it is in Python:
>
> --------------------
> def getstr():
>     return "ABCDEFGHIJKLMNOPQRSTUVWXYZ "
>
> for i in range(1000000):
>     s=""
>     s+=getstr()
>     s+=getstr()
>     s+=getstr()
>     s+=getstr()
>     s+=getstr()
>
> print (s)
> print (len(s))
> --------------------
>
> This took 1.8 seconds with CPython (1/2 to 1/3 the speed of the sprintf
> loop) and 0.2 seconds with PyPy (several times the speed of the C). This
> language uses counted strings too.

Python is much more useful as an example, since it is something other
people can and do use.

Counted strings are going to do better in a test like this. There are
many different data structures that can be used to hold string data,
each with their benefits and disadvantages. That is another reason why
blanket statements (whether by you or by Scott) without context about
the relative speed of two functions or techniques are usually
meaningless. You have to compare real-world speeds in the situations
you are using them.

On 12/08/2021 13:26, Bart wrote:
> On 12/08/2021 09:39, David Brown wrote:
>> On 12/08/2021 00:30, Bart wrote:
>>> On 11/08/2021 23:13, Bart wrote:
>>>> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
>>>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> This is what I get for the c.c module of my last past, with gcc -O3 -S
>>>> (comments and other noise deleted):
>>>>
>>>> printf:
>>>>       push    r12  #
>>> ...
>>>> I guess this is again either all my fault for not knowing what options
>>>> I need to make the code as sweet as yours, or Windows' for being such
>>>> a crap OS, or both.
>>>
>>> Better is this godbolt link to that same module (using gcc x64 11.2):
>>>
>>> https://godbolt.org/z/Yz9vEzhaY
>>>
>>> The displayed code is a lot cleaner and clearer.
>>
>> It is not "cleaner and clearer" - it is much messier because you have
>> put everything into one big function combined with clock timing stuff
>> and outputs.
>
> I was talking about the assembly code

The same applies to the assembly code as to the source code here. (That
is not always the case, of course.)

>
>   To make code "clean and clear", structure it properly -
>> put different things in different functions, and then it is possible to
>> see the relevant differences in the results.
>>
>>> I'm not even sure what
>>> OS it's for! (It doesn't look like Win64, so at least you can't be
>>> Windows-bashing with it.)
>>
>> You display your ignorance proudly, as though it were a medal.  Bizarre.
>
> Ignorance about what? I genuinely don't know what machines these
> compilers target, because it doesn't tell you. Not for GCC x64 anyway.
>

It tells you "running under Wine" for the Windows-only compilers. That
should be a big clue. You can also look at the documentation for it.

> Yes, I can see from the call sequences that it is not Win64 ABI, and is
> probably 'SYS V', but that's about it.
>
> The important thing is that it shows more realistic code than you and
> antispam posted. It should have been clear that that my original code
> could collapse down to nothing if optimised, something I even said would
> happen.

No, your later examples are not more realistic than your earlier ones,
and putting the two algorithms into one function along with other
boilerplate code instead of two simple functions (that's what my
complaint was about) is not more realistic in any sense.

Show me a /realistic/ use-case for combining the same simple string to
itself a million times.

>
> You both should instead have put together a more solid test that
> compared the merits of strcat and sprintf that would hold up better.
>

Why? All I was doing was showing that the test you gave was pointless.
The result was that you then produced a slightly less pointless test,
which is an improvement.

> Instead you are just more interested in bart-bashing points.
>
> And in the end, which of those two functions is better; what conclusion
> have you reached by trashing my own test? You vaguely suggest that
> sprintf is better, but where's your benchmark?
>

My conclusion from trashing your test is that your test was pointless.
It gave no indication whether one function was better than the other in
any way. Later modifications to your test showed that strcat was faster
than sprintf in that particular meaningless and unrealistic example.

I don't have /any/ concrete conclusions about the relative speeds of
these functions. I can estimate that in general, strcat will usually be
faster than sprintf as independent library functions, and also that in
some cases sprintf might be faster. And I can certainly conclude that
it will all depend on details of the code, the compiler, optimisations,
library implementations, and no doubt also the system it is running on.

Timing meaningless code is usually pointless. If you have a program
that does a lot of string manipulation, and you have investigated and
discovered that the string manipulation is a serious bottleneck and does
not run as fast as you want, then make timings of different algorithms
and functions for that code. (If the speed is not a problem, then of
course you aim for source-code clarity and maintainability, rather than
speed.)

That is the lesson /you/ should take away from all this.

On Thursday, 12 August 2021 at 15:28:27 UTC+1, David Brown wrote:
> On 12/08/2021 13:10, Bart wrote:
> > On 12/08/2021 09:29, David Brown wrote:
> >> On 12/08/2021 00:00, Bart wrote:
> >
> >> Yes. You gave what you thought was a test, and called a test, and I
> >> showed that it is not only irrelevant, but it shows that you were wrong.
> >>
> >>
> >> Now, /in general/ I would expect strcpy() and other related functions to
> >> be faster than using sprintf or snprintf. I would also expect them to
> >> be inlined much better.
> >
> > Malcolm suggested that use of strcat was fine for assembling short
> > strings, SL suggested using snprintf every time because 'every cycle
> > counts'.
> >
> Other people can answer for their own opinions and comments.
>
> Python is much more useful as an example, since it is something other
> people can and do use.
>
> Counted strings are going to do better in a test like this. There are
> many different data structures that can be used to hold string data,
> each with their benefits and disadvantages. That is another reason why
> blanket statements (whether by you or by Scott) without context about
> the relative speed of two functions or techniques are usually
> meaningless. You have to compare real-world speeds in the situations
> you are using them.
>
Very few people use C for heavy string processing. They use C for a little bit
of minor string processing in programs which are basically doing something
else. And, interestingly enough, C is a good choice for implementing a
string processing package itself. But C isn't a good choice for the application-
specific code which calls that string processing package.

If you are just doing minor string processing, efficiency doesn't matter. The processing
time wil be dominated by other things, or it will be so short that it's not an issue
at all. Not all cycles are equal, because most machines spend a lot of cycles
idling. Only a cycle which the user/customer notices is worth eliminating.

If you are doing major string processing, my experience here is with bioinformatics,
where data is often either large numbers (tens of thousands) of strings representing
genes, of a few hundred to low thousands of characters long, or small numbers (tens)
of string representing entire neucleotide sequences, which can be up to a billion
characters long (the human genome is 3,000 mega base pairs, spread over 22 normal
chromosomes and two sex chromosomes). However time pressures aren't tight -
a few hours to do an analysis might not be good, but it's not catastrophic. In practise
you need to avoid N by N operations. I used MatLab, because it was lab policy that
everyone used MatLab, not because of its string handling capabilities.

David Brown <david.brown@hesbynett.no> writes:
>On 12/08/2021 13:10, Bart wrote:
>> On 12/08/2021 09:29, David Brown wrote:
>>> On 12/08/2021 00:00, Bart wrote:
>>
>>> Yes.  You gave what you thought was a test, and called a test, and I
>>> showed that it is not only irrelevant, but it shows that you were wrong.
>>>
>>>
>>> Now, /in general/ I would expect strcpy() and other related functions to
>>> be faster than using sprintf or snprintf.  I would also expect them to
>>> be inlined much better.
>>
>> Malcolm suggested that use of strcat was fine for assembling short
>> strings, SL suggested using snprintf every time because 'every cycle
>> counts'.
>>
>
>Other people can answer for their own opinions and comments.

Except I have no interest in arguing with Bart. Particularly when
he misrepresents what I said by conflating two different arguments.

On 12/08/2021 17:52, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 12/08/2021 13:10, Bart wrote:
>>> On 12/08/2021 09:29, David Brown wrote:
>>>> On 12/08/2021 00:00, Bart wrote:
>>>
>>>> Yes.  You gave what you thought was a test, and called a test, and I
>>>> showed that it is not only irrelevant, but it shows that you were wrong.
>>>>
>>>>
>>>> Now, /in general/ I would expect strcpy() and other related functions to
>>>> be faster than using sprintf or snprintf.  I would also expect them to
>>>> be inlined much better.
>>>
>>> Malcolm suggested that use of strcat was fine for assembling short
>>> strings, SL suggested using snprintf every time because 'every cycle
>>> counts'.
>>>
>>
>> Other people can answer for their own opinions and comments.
>
> Except I have no interest in arguing with Bart. Particularly when
> he misrepresents what I said by conflating two different arguments.
>

Fair enough. If you think expanding on your posts might be of interest
to others here, then please do so.

On 12/08/2021 15:28, David Brown wrote:
> On 12/08/2021 13:10, Bart wrote:

>> That doesn't tell you much about non-optimising compilers, or attempts
>> to call C functions from other languages, which is MY interest.
>
> No one (sane and knowledgable) cares about the speed of code generated
> by non-optimising compilers, or compilers with the optimisation turned off.
>
> No one (sane and knowledgable) who calls library functions from another
> language cares about the results of a compiler running test code - they
> care about the /library/, its implementation, and efficiency.

That is just your opinion. Many of us do care about it, since
unoptimised code can give highly useful trade-offs (like 100 times
faster build speeds - ask any Rust developer whether they would like a
100x faster build just once).

Any native code non-optimising compiler can still generate code that
will wipe the floor with any interpreted scripting language.

So there is a place for such implementations.

(I'd also imagine that my non-optimising compilers would generate faster
code on your machine, than gcc-O3 on mine.)

> So if you are interested in the performance of strcat and sprintf when
> used from a different language, look at the library, not the C compiler.

You could just write a benchmark if the results are actually in dispute.
Just stating an opinion wouldn't be enough for Scott, but then neither
are hard facts apparently.

>> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
>> 440/2320 msec - sprintf was still several times slower.)
>>
>
> I haven't claimed that sprintf is faster - I merely gave a possible
> explanation why it might be faster, for some situations.

You said it's probably faster for short strings. It seems it can be
faster for much longer ones, but presumably not quoye as long as DFS's.

> But looking at the code generated for your latest change, I notice
> something vital - gcc (on godbolt) is converting many of the "strcat"
> calls into "stpcpy" calls. stpcpy is not a standard C function, but is
> (AFAICS) in POSIX standards. It is like strcpy, except it returns a
> pointer to the end of the combined string - and is thus vastly more
> efficient in this case.

strcat is a very simple function - at least in spec - and thus could
lend itself easily to optimisation.

I use it extensively from outside of C, but usually in cases that are
not speed-critical (such as generating diagnostic listings, or
synthesising command strings for system()).

But I rarely use any *printf functions via FFIs; format strings just
don't belong outside of C.

For building text files in-memory by concatenating, a method I also use
all the time, I use streamlined functions of my own.

> That is another reason why
> blanket statements (whether by you or by Scott) without context about
> the relative speed of two functions or techniques are usually
> meaningless. You have to compare real-world speeds in the situations
> you are using them.

Funny how one remark by Scott that was likely erroneous and misleading
attracts virtually no comment. But someone TRIES to show that they are
wrong, and you try to annihilate them.

DFS <nospam@dfs.com> wrote:
> On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote:
>
> > DFS can be excused as he apparently does not know what
> > happened.
>
> I didn't know why at first, but Kaz Kylheku explained it: the speed
> difference in printf() is due to the implementation used in tcc
> (msvcrt.dll) vs that used in mingw gcc.

That is the trigger. But when you outut to Windows console
almost all time is spent in console code and graphic
processing (possibly inside a GPU). IIRC other folks noted
that char-by-char output slows console quite a lot. Outputting
to a file is simple way to isolate console effects, even with
char-by-char (unbuffered) output file will be much faster
than console (of course, exact speed will depend in speed
of system callse).

> I tried to find printf() code in the source for gcc 11.1.0, but
> couldn't. Do you know how to find it?

As other explained, printf is library function so you should look
for sources of library that you use (but apparently, on Windows
after some intial stage it will go to closed-source Microsoft library).

Inside gcc you may search for 'builtin_printf'. In particular,
gcc may optimize some prinft variants to simpler versions.
In older versions of gcc relevant file was 'gcc/builtins.c'.

--
Waldek Hebisch

On 12/08/2021 15:44, David Brown wrote:
> On 12/08/2021 13:26, Bart wrote:

> Show me a /realistic/ use-case for combining the same simple string to
> itself a million times.

Show me a use-case for testing vehicles by driving round and round the
same circular track.

It seems you just don't get benchmarks. Many are necessarily repetitive,
and need to concentrate on a specific thing that is being tested. And
all are meaningless.

I could change my getstr() routine to return a random string of random
length, but that makes it harder to measure and compare results, and you
would just find another reason to discredit it.

Here's a challenge for you: some students each present you with an
opaque implementation of [for example] strcat (but renamed to avoid
confusion). You need to grade according them according to how efficient
(ie. how fast) they are on a range of test inputs.

How would you go about testing them? Don't forget you're not allowed to
use loops, or apply the same inputs more than once.

How would you distinguish an entry which is fast because of technique,
from one which is fast because of a clever compiler which can take
advantage of the specific test context?

What would you think of a compiler smart enough to recognise the
function as doing what strcat does, and replaces it with the
highly-optimised built-in strcat; would you consider that a good or bad
thing, from the point of view of doing your job?

Bart <bc@freeuk.com> wrote:
> On 12/08/2021 09:29, David Brown wrote:
> > On 12/08/2021 00:00, Bart wrote:
>
> Try this version of getstr():
>
> char* getstr(void){
> enum {N=10000};
> static char* s=NULL;
>
> if (s) return s;
>
> s=malloc(N+1);
> memset(s,'A',N);
> s[N]=0;
> return s;
> }
>
> You may need to adjust the timing loop in the other module for fewer
> iterations, and ensure the str[] array is big enough for 5 copies. (And
> maybe comment out the bits that print the strings!)

I used the following with 'strcpy' and 'strlen':

#include <stdio.h>
#include <string.h>

char str[60*1000];

extern char * get_str(void);

int
main(void) {
char * s;
char * ns;
for (int i=0; i<100000; ++i) {
ns = get_str();
s = str;
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
}
puts(str);
return 0;
}

but redirected output to '/dev/null'.

time ./b5a > /dev/null

real 0m0.400s
user 0m0.400s
sys 0m0.000s

so 400ms for this version doing 100000

With 'sprintf':

#include <stdio.h>
#include <string.h>

char str[60*1000];

extern char * get_str(void);

int
main(void) {
char * s;
char * ns;
for (int i=0; i<100000; ++i) {
ns = get_str();
s = str;
s += sprintf(s, "%s", ns);
s += sprintf(s, "%s", ns);
s += sprintf(s, "%s", ns);
s += sprintf(s, "%s", ns);
sprintf(s, "%s", ns);
}
puts(str);
return 0;
}

time ./b5c > /dev/null

real 0m0.473s
user 0m0.468s
sys 0m0.000s
BTW: For my tests I used 'get_str', so I renamed yours to 'get_str'
to fit.

> You might be surprised at the results.
>
> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
> 440/2320 msec - sprintf was still several times slower.)

Well, there are various design points. On short strings on my
machine I get similar time as you with 'sprintf' and 2.4s
using 'strcat' + 'strlen'. But on longer strings seem to be
much faster (as I wrote on my machine string handling is via
SSE instructions).

--
Waldek Hebisch

On 12/08/2021 17:59, Bart wrote:
> On 12/08/2021 15:28, David Brown wrote:
>> On 12/08/2021 13:10, Bart wrote:
>
>>> That doesn't tell you much about non-optimising compilers, or attempts
>>> to call C functions from other languages, which is MY interest.
>>
>> No one (sane and knowledgable) cares about the speed of code generated
>> by non-optimising compilers, or compilers with the optimisation turned
>> off.
>>
>> No one (sane and knowledgable) who calls library functions from another
>> language cares about the results of a compiler running test code - they
>> care about the /library/, its implementation, and efficiency.
>
> That is just your opinion. Many of us do care about it, since
> unoptimised code can give highly useful trade-offs (like 100 times
> faster build speeds - ask any Rust developer whether they would like a
> 100x faster build just once).

I have no experience of Rust. But I can tell assure you that "gcc -O0"
does not run 100 times faster than "gcc -O2", and is nowhere near as
useful. It is rare for the speed of C compilation - even when optimised
- to be of a significant hinder to professional (or serious hobby) C
developers. I'm sure there are /some/ people out there regularly
recompiling the Linux kernel natively on a Pi 1, but there can't be
many. There are possibly some who mistakenly think compilation without
optimisation is a good way to do a quick check of code quality.
Regardless, how many of those that you think intentionally compile with
optimisations disabled are particularly interested in the run-time speed
of the resulting code?

>
> Any native code non-optimising compiler can still generate code that
> will wipe the floor with any interpreted scripting language.
>

For most (for a very vague, hand-waving and unsubstantiated measurement
of "most") code, run-time speed is not particularly important.

I did not say that people don't run compilers without optimisations. I
said that people who care about the speed of the results don't run
compilers without optimisations.

(Actually, I did miss out a class of programmers who may run compilers
without optimisations, while caring about speed. There are some
commercial toolchains where there are price differences for licenses or
versions with and without optimisations.)

> So there is a place for such implementations.
>
> (I'd also imagine that my non-optimising compilers would generate faster
> code on your machine, than gcc-O3 on mine.)
>

So what?

If I want code to be fast, I enable optimisations. If I want it to be
small, I enable optimisations. If I want static error checking to catch
errors in my code at the earliest opportunity, I enable optimisations.
If I don't care about any of that, then C is highly unlikely to be the
right language for the task. I cannot imagine any circumstance in which
I'd want to disable optimisation during code development.

>> So if you are interested in the performance of strcat and sprintf when
>> used from a different language, look at the library, not the C compiler.
>
> You could just write a benchmark if the results are actually in dispute.
> Just stating an opinion wouldn't be enough for Scott, but then neither
> are hard facts apparently.
>

No one has given any hard facts to counter his personal experience, and
your opinions are not likely to be attributed much weight. (I know /I/
can't write a benchmark to counter his post, because I believe he was
thinking of particular use-cases, and I don't know what they are.)

Nevertheless, my point stands - if you are interested in the speed of
library functions, then concentrate on the library functions, not the
compiler. (That's assuming you know what library you are using, of course.)

>
>>> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
>>> 440/2320 msec - sprintf was still several times slower.)
>>>
>>
>> I haven't claimed that sprintf is faster - I merely gave a possible
>> explanation why it might be faster, for some situations.
>
> You said it's probably faster for short strings. It seems it can be
> faster for much longer ones, but presumably not quoye as long as DFS's.
>

I said sprintf is going to be faster for /longer/ strings, because (in
code sequences like your test code) it avoids the need to continually
re-scan strings to find their length. That is, I think, quite obvious.

(It's always possible that I jumbled my words in a post and wrote the
opposite of what I meant. I'm sure you'll let me know if that was the
case.)

>> But looking at the code generated for your latest change, I notice
>> something vital - gcc (on godbolt) is converting many of the "strcat"
>> calls into "stpcpy" calls.  stpcpy is not a standard C function, but is
>> (AFAICS) in POSIX standards.  It is like strcpy, except it returns a
>> pointer to the end of the combined string - and is thus vastly more
>> efficient in this case.
>
> strcat is a very simple function - at least in spec - and thus could
> lend itself easily to optimisation.
>

Yes.

> I use it extensively from outside of C, but usually in cases that are
> not speed-critical (such as generating diagnostic listings, or
> synthesising command strings for system()).
>
> But I rarely use any *printf functions via FFIs; format strings just
> don't belong outside of C.
>

Format strings of various sorts are used in many languages. But I can
fully understand not wanting C-specific printf and format strings in
other languages.

> For building text files in-memory by concatenating, a method I also use
> all the time, I use streamlined functions of my own.
>
>> That is another reason why
>> blanket statements (whether by you or by Scott) without context about
>> the relative speed of two functions or techniques are usually
>> meaningless.  You have to compare real-world speeds in the situations
>> you are using them.
>
>
> Funny how one remark by Scott that was likely erroneous and misleading
> attracts virtually no comment. But someone TRIES to show that they are
> wrong, and you try to annihilate them.
>

I don't know that Scott's remark was erroneous or misleading - but it
could certainly have helped with some more explanation. (Then we might
be in a position to judge better whether or not it was correct.)

I haven't been trying to "annihilate" you - that's paranoia. I have not
even disagreed with your main point about strcat being faster (in
general) than sprintf - nor has anyone else, I think. But I /have/
disagreed with some of your methods, and tried to explain why and how to
improve on them.

On 12/08/2021 18:20, Bart wrote:
> On 12/08/2021 15:44, David Brown wrote:
>> On 12/08/2021 13:26, Bart wrote:
>
>
>> Show me a /realistic/ use-case for combining the same simple string to
>> itself a million times.
>
>
> Show me a use-case for testing vehicles by driving round and round the
> same circular track.

There are plenty, as you well know. Pushing an analogy past its
breaking point does not make you right.

>
> It seems you just don't get benchmarks. Many are necessarily repetitive,
> and need to concentrate on a specific thing that is being tested. And
> all are meaningless.

I did not say benchmarks are not useful - they are, in some cases, when
they can be used to measure something useful. I objected to your
characteristic of your code as "realistic", which it most certainly is not.

>
> I could change my getstr() routine to return a random string of random
> length, but that makes it harder to measure and compare results, and you
> would just find another reason to discredit it.
>

That would change the kind of benchmark, perhaps giving more useful
results (without improving the realism at all). But it is still not
clear what you would be testing or how it relates to speeds and
bottlenecks in /real/ code. If the speed of string concatenation in
real world code (of a particular type) is limited by cache speeds rather
than processor speeds, then the function that gives the fastest results
will be the one that uses fewer memory accesses - not the one that wins
on such limited synthetic benchmarks. At the moment, all you are doing
is benchmarking the speed of your benchmark, which is not relevant to
real programming.

> Here's a challenge for you: some students each present you with an
> opaque implementation of [for example] strcat (but renamed to avoid
> confusion). You need to grade according them according to how efficient
> (ie. how fast) they are on a range of test inputs.
>
> How would you go about testing them? Don't forget you're not allowed to
> use loops, or apply the same inputs more than once.
>

I would want to know under what circumstances the functions are intended
to be used. Otherwise, the question is meaningless.

> How would you distinguish an entry which is fast because of technique,
> from one which is fast because of a clever compiler which can take
> advantage of the specific test context?
>
> What would you think of a compiler smart enough to recognise the
> function as doing what strcat does, and replaces it with the
> highly-optimised built-in strcat; would you consider that a good or bad
> thing, from the point of view of doing your job?

Those are all good questions to consider before deciding how the
implementations should be judged.

Usually, I'd pick the one that is most clearly correctly implemented.
Black box implementations get zero marks on that score, regardless of
whether they passed or failed any tests.