On Monday, August 9, 2021 at 12:17:59 AM UTC+3, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 08/08/2021 20:21, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >>>> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
> >>>
> >>> You're right; this program:
> >>>
> >>> #include <stdio.h>
> >>> int main(void) {
> >>> for (int i=0; i<10000; ++i)
> >>> printf("%-16s","1234567890"); // no newlines
> >>> }
> >>>
> >>> runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
> >>> never noticed before.
> >> You often post times with no indication of what's being measured.
> >
> > Huh? The test program is shown above. A tcc-compiled program takes 7
> > times as long as gcc- or clang-compiled one. On Windows (I know Linux
> > has super-fast console output).
> >
> > What I'm measuring is how long between starting the program, and
> > finishing writing stuff to the screen, because on Windows you can see
> > all this output scrolling up the screen.
> You've been in the business for many years. I can't believe you don't
> know what I mean.
> >> The
> >> compiler probably has little to do with it. What C library is being
> >> used? How is the output handled?
> >
> > I don't know, but... should anyone really have to delve into the exact
> > implementation of printf to get it to do its job properly? It should
> > just work! Which means not working a magnitude slower than it should.
> I my machine is three times faster than yours (just to get a simple
> number) we are talking about three orders of magnitude. Do you think
> that's down to the implementation of printf? You certainly haven't
> posted any data to support that.
> > See my other post a few minutes after yours for further investigations.
> >
> >>> You can try bypassing printf in gcc by using sprintf to a string for a
> >>> complete line of output, then using puts() on the string. However you
> >>> shouldn't need to do this.
> >> Why do you think the problem (whatever it is) has got anything to do
> >> with gcc if the problem disappears when the output is redirected?
> >
> > The 'problem' is with clang/gcc calling 'printf'. All compilers are
> > told to use printf, yet only these two compilers end up being slow.
> I thought you said the problem goes away when the output is redirected?
> gcc and clang don't generate code that does not call printf when the
> output is redirected.
> > But if that is the case, who's fault is that, and what can one do
> > about it? Do you think it is likely to involve messing with the
> > options for these gcc or clang installations?
> >
> > Because you seem keen to put the blame elsewhere.
> Because I think the blame must be elsewhere, but I'm not going to
> install Windows (and all the other stuff one might need) just to find
> out.

That, probably, wouldn't help.
Bart and DFS are unique people with unique capabilities.
DFS more so, but Bart's ability to hit roadbles that almost nobody else hit also shouldn't be underestimated.
Out of interest, I logged into machine where I have several cygwin installations
(all coming with various versions of Altera Nios II EDS suit) ranging from 2009 to 2018.
I compiles Bart's program and run it. I looked a bit slow, but not dramatically so.
I timed it with time. Depending on the version, time varied between 90 and 370 msec.
Yes, it's very slow (under MSYS2, on my significantly older and slower home desktop, it took 20ms,
of which, I'd guess, more than half is loading program rather than running it) but not *nearly* as slow
as reported by Bart and DFS.

But then I figured out how to make it *really* slow.
First, you should find *very* old cygwin. Of all my installations only one from 2009 is old enough.
Second, you should compile/link with flag '-mno-cygwin".
Third, you should run the executive in normal windows command window rather than in cygwing window.
Only then you will be able to see the slowness.
It seems, this particular combination of tools and environment dislikes very long lines.

It's still not guaranteed, that you'll see times, reported by Bart. It depends on many factors, most
importantly, on the exact size of your command window.
Personally, I had never seen more than 2.5 or 3 seconds.
But that difference , at least, can be explained by difference in speed between my hardware
(4-5 y.o. Haswell with 32GB of RAM and decent SSD) and the hardware used by Bart.

> > What can you tell DFS to make fix this problem when using gcc?
> To get 1000-fold increase in speed, ditch Windows. If he or she must
> use Windows, find out what's taking the time.
>
> --
> Ben.

On 08/08/2021 23:30, Michael S wrote:
> On Monday, August 9, 2021 at 12:17:59 AM UTC+3, Ben Bacarisse wrote:

>>>
>>> Because you seem keen to put the blame elsewhere.
>> Because I think the blame must be elsewhere, but I'm not going to
>> install Windows (and all the other stuff one might need) just to find
>> out.
>
> That, probably, wouldn't help.
> Bart and DFS are unique people with unique capabilities.
> DFS more so, but Bart's ability to hit roadbles that almost nobody else hit also shouldn't be underestimated.
> Out of interest, I logged into machine where I have several cygwin installations
> (all coming with various versions of Altera Nios II EDS suit) ranging from 2009 to 2018.
> I compiles Bart's program and run it. I looked a bit slow, but not dramatically so.
> I timed it with time. Depending on the version, time varied between 90 and 370 msec.
> Yes, it's very slow (under MSYS2, on my significantly older and slower home desktop, it took 20ms,
> of which, I'd guess, more than half is loading program rather than running it) but not *nearly* as slow
> as reported by Bart and DFS.
>
> But then I figured out how to make it *really* slow.
> First, you should find *very* old cygwin. Of all my installations only one from 2009 is old enough.
> Second, you should compile/link with flag '-mno-cygwin".

Cygwin and MSYS2? I'm talking about plain Windows. I've no idea what's
going on in those products; maybe they use different console programs or
different C runtimes from those used from plain Windows.

Third, you should run the executive in normal windows command window
rather than in cygwing window.
> Only then you will be able to see the slowness.
> It seems, this particular combination of tools and environment dislikes very long lines.
>
> It's still not guaranteed, that you'll see times, reported by Bart. It depends on many factors, most
> importantly, on the exact size of your command window.
> Personally, I had never seen more than 2.5 or 3 seconds.
> But that difference , at least, can be explained by difference in speed between my hardware
> (4-5 y.o. Haswell with 32GB of RAM and decent SSD) and the hardware used by Bart.

Try these two versions:

#include <stdio.h>

int main(void) {
for (int i=0; i<2000; ++i) {
printf("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n");
}
}

--------------------------------------------

#include <stdio.h>

int main(void) {
for (int i=0; i<2000; ++i) {
for (int j=0; j<79; ++j) printf("X");
puts("");
}
}

The first generally runs in 1.7 seconds (display is 60 rows of 100
chars), the second in 25-26 seconds, using bcc/tcc/DMC/CL compilers.

But with gcc/clang, both run in 25-26 seconds (lccwin took 20 seconds)

What's going on in those latter compilers? You tell me.

My idea was that gcc ends up calling fprintf a character at a time, or
maybe fputc (it doesn't import printf).

BTW I don't appreciate your getting personal. I'm only reporting what
I've actually observed.

Remarks along the lines of 'Ah, well Windows is dead slow anyway, what
difference does another magnitude slow make' are not helpful.

On 8/8/2021 6:30 PM, Michael S wrote:

> Bart and DFS are unique people with unique capabilities. DFS more so,

What are you babbling about?

> but Bart's ability to hit roadbles that almost nobody else hit also
> shouldn't be underestimated.

There's no reason for anyone to get different results that what Bart and
I experienced.

Running Win10 21H1. Wanted a better compiler than tcc (0.9.27), so I
installed the gcc from:

https://github.com/brechtsanders/winlibs_mingw/releases/download/11.2.0-12.0.1-9.0.0-r1/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64-9.0.0-r1.7z
(gcc 11.2.0)

$gcc -Wall source.c -o prog.exe

created a huge executable that ran printf() very slowly.

Tried another one:

https://github.com/skeeto/w64devkit/releases/tag/v1.8.0 (gcc 11.1.0)

also created a huge executable that ran printf() very slowly.

gcc Windows: slow 3.15s
tcc Windows: quick 0.24s
gcc Linux : incredibly quick (like 0.01, no time to blink)

And that's just 726 words.

Code is standard printf() stuff I think:

//get max number of columns to print on each line
//tcols = number of columns on terminal screen
//add 2 to longword to account for spaces

int maxcols = ((int)(tcols/(longword+2)));
int cols=1;
for(int i=0;i<matchcnt;i++)
{ printf("%-*s ", longword, matchwords[i]);
cols++;
if(cols>maxcols) {
printf("\n");
cols=1;
}
}

Remove the column breaks and it's just as slow.

> Out of interest, I logged into machine where I have several cygwin
> installations (all coming with various versions of Altera Nios II EDS
> suit) ranging from 2009 to 2018. I compiles Bart's program and run
> it. I looked a bit slow, but not dramatically so. I timed it with
> time. Depending on the version, time varied between 90 and 370 msec.
> Yes, it's very slow (under MSYS2, on my significantly older and
> slower home desktop, it took 20ms, of which, I'd guess, more than
> half is loading program rather than running it) but not *nearly* as
> slow as reported by Bart and DFS.
>
> But then I figured out how to make it *really* slow. First, you
> should find *very* old cygwin. Of all my installations only one from
> 2009 is old enough. Second, you should compile/link with flag
> '-mno-cygwin". Third, you should run the executive in normal windows
> command window rather than in cygwing window. Only then you will be
> able to see the slowness. It seems, this particular combination of
> tools and environment dislikes very long lines.
>
> It's still not guaranteed, that you'll see times, reported by Bart.
> It depends on many factors, most importantly, on the exact size of
> your command window.

My code polls the size of the terminal window before printing, to
determine how many columns of the widest word in the result set will fit
cleanly. Whether the window is wide (10 columns) or narrow (5
columns), the gcc Windows printf() is about the same: just over 3
seconds to print 726 words.

I think Kaz Kylheku nailed it: difference in printf() implementation
between tcc and gcc.

> Personally, I had never seen more than 2.5 or 3
> seconds. But that difference , at least, can be explained by
> difference in speed between my hardware (4-5 y.o. Haswell with 32GB
> of RAM and decent SSD) and the hardware used by Bart.

I run an 11-year-old chip: i5-750@2.67GHz, 8GB mem, Mushkin Reactor SSD.

Bart <bc@freeuk.com> writes:

> On 08/08/2021 22:17, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are
>>> told to use printf, yet only these two compilers end up being slow.
>> I thought you said the problem goes away when the output is redirected?
>> gcc and clang don't generate code that does not call printf when the
>> output is redirected.
>
> I thought I explained what might have been happening: gcc might end up
> calling a routine in msvcrt that works a character at a time, rather
> than a string at a time. And the former might be slower when sent to
> the console so you don't see a problem with file output.

gcc is a compiler. It generates code that calls printf or similar.
After that, what happens is nothing to do with gcc.

>>> What can you tell DFS to make fix this problem when using gcc?
>> To get 1000-fold increase in speed, ditch Windows. If he or she must
>> use Windows, find out what's taking the time.
>
> Where did the 1000-fold increase come from? The slowdown on my last
> test was about 14 times, in line with what DFS reported.

You reported 21s, I measured 0.007s, both using gcc. The difference is
almost certainly be due to implementation components other than gcc.

--
Ben.

On 2021-08-08, Bart <bc@freeuk.com> wrote:
> On 08/08/2021 13:51, DFS wrote:
>> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
>
> You're right; this program:
>
> #include <stdio.h>
> int main(void) {
> for (int i=0; i<10000; ++i)
> printf("%-16s","1234567890"); // no newlines
> }
>
> runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
> never noticed before.
>
> My bcc compiler, which also calls printf in msvcrt, does it in 2.3
> seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
> Clang is 21 seconds (which is taking being a gcc clone to extremes).
>
> All very strange. I don't know how much this is important, or how much
> text you're printing to the screen, since 500 printfs per second is
> still faster than anyone can read it. The problem disappears if you
> redirect to a file.

It might depend on whether the output stream is buffered or not.
I'd expect output to the console to be unbuffered.
What happens if you change it to fully buffered, adding

setvbuf(stdout, NULL, _IOFBF, 0);

at the start of the program?

On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote:
> On 8/8/2021 6:30 PM, Michael S wrote:
>
> > Bart and DFS are unique people with unique capabilities. DFS more so,
> What are you babbling about?

Your shared love to strange tools that wouldn't in top#5 list of choice of professional and likely not in top#10.

> > but Bart's ability to hit roadbles that almost nobody else hit also
> > shouldn't be underestimated.
> There's no reason for anyone to get different results that what Bart and
> I experienced.
>
> Running Win10 21H1. Wanted a better compiler than tcc (0.9.27), so I
> installed the gcc from:
>
> https://github.com/brechtsanders/winlibs_mingw/releases/download/11.2.0-12.0.1-9.0.0-r1/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64-9.0.0-r1.7z
> (gcc 11.2.0)

That loooks like mingw-64. The same compiler/libraries that I tried first and that finished the task in 20 msec - 1000 times faster than you (or Bart) reported.

AFAIK, it's C RTL is based on Microsoft's DLL that was originally distributed with VS2013.
Recently, they (MSYS2 maintainers) added a variant of library that is called ucrt-something,
probably based on more up to date Microsoft's DLL. I didn't try it yet.

I didn't see the slowness because I was running it from msys2 command window, i.e. the same environment in which that it was tested by maintainers.
When I take generated exe file and try to run it in regular windows command window (cmd.exe)
or in powershell window then I see extreme slowness - order of 4.5 sec in cmd.exe and 6.5 sec in powereshell.
When I changed the size of cmd window to "traditional" defaults of 80x25, it slowed down to 6 seconds.

>
> $gcc -Wall source.c -o prog.exe
>
> created a huge executable that ran printf() very slowly.
>

Huge executive is due to presence of symbols. gcc -s (symbols stripped) is just big, not huge.

Slowness is due to interaction between startup code in mingw64 library and windows command prompt environment,
probably not provisioned by maintainers since they expect their console programs to be run under msys2.

As said by several people here, under such combo stdout behaves as unbuffered. So, 160,000 system calls.
By themselves, 160,000 system calls are not particularly slow, but Windows console subsystem seems obliged
to redraw the whole window each time the character does not fit in window width.
Or, may be, even more often, may be, once per character.
So far I didn't figure out how to find exact details.

>
> Tried another one:
>
> https://github.com/skeeto/w64devkit/releases/tag/v1.8.0 (gcc 11.1.0)
>

If you want to use msys2-maintained gcc compiler then I strongly recommend
to stick to "official" msys2 distribution.
https://www.msys2.org/

> also created a huge executable that ran printf() very slowly.
>
> gcc Windows: slow 3.15s
> tcc Windows: quick 0.24s
> gcc Linux : incredibly quick (like 0.01, no time to blink)
>

0.01 I'd call o.k. rather than "incredibly quick"

> And that's just 726 words.
>
>
>
> Code is standard printf() stuff I think:
>
> //get max number of columns to print on each line
> //tcols = number of columns on terminal screen
> //add 2 to longword to account for spaces
>
> int maxcols = ((int)(tcols/(longword+2)));
> int cols=1;
> for(int i=0;i<matchcnt;i++)
> {
> printf("%-*s ", longword, matchwords[i]);
> cols++;
> if(cols>maxcols) {
> printf("\n");
> cols=1;
> }
> }
>
> Remove the column breaks and it's just as slow.
> > Out of interest, I logged into machine where I have several cygwin
> > installations (all coming with various versions of Altera Nios II EDS
> > suit) ranging from 2009 to 2018. I compiles Bart's program and run
> > it. I looked a bit slow, but not dramatically so. I timed it with
> > time. Depending on the version, time varied between 90 and 370 msec.
> > Yes, it's very slow (under MSYS2, on my significantly older and
> > slower home desktop, it took 20ms, of which, I'd guess, more than
> > half is loading program rather than running it) but not *nearly* as
> > slow as reported by Bart and DFS.
> >
> > But then I figured out how to make it *really* slow. First, you
> > should find *very* old cygwin. Of all my installations only one from
> > 2009 is old enough. Second, you should compile/link with flag
> > '-mno-cygwin". Third, you should run the executive in normal windows
> > command window rather than in cygwing window. Only then you will be
> > able to see the slowness. It seems, this particular combination of
> > tools and environment dislikes very long lines.
> >
> > It's still not guaranteed, that you'll see times, reported by Bart.
> > It depends on many factors, most importantly, on the exact size of
> > your command window.
> My code polls the size of the terminal window before printing, to
> determine how many columns of the widest word in the result set will fit
> cleanly. Whether the window is wide (10 columns) or narrow (5
> columns), the gcc Windows printf() is about the same: just over 3
> seconds to print 726 words.
>
> I think Kaz Kylheku nailed it: difference in printf() implementation
> between tcc and gcc.
> > Personally, I had never seen more than 2.5 or 3
> > seconds. But that difference , at least, can be explained by
> > difference in speed between my hardware (4-5 y.o. Haswell with 32GB
> > of RAM and decent SSD) and the hardware used by Bart.
> I run an 11-year-old chip: i5-...@2.67GHz, 8GB mem, Mushkin Reactor SSD.

As written above, now I found a way (on somewhat slower HW then the one used originally) to increase the time to 6 seconds.

On Monday, August 9, 2021 at 8:46:20 AM UTC+3, Ike Naar wrote:
> On 2021-08-08, Bart <b...@freeuk.com> wrote:
> > On 08/08/2021 13:51, DFS wrote:
> >> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
> >
> > You're right; this program:
> >
> > #include <stdio.h>
> > int main(void) {
> > for (int i=0; i<10000; ++i)
> > printf("%-16s","1234567890"); // no newlines
> > }
> >
> > runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
> > never noticed before.
> >
> > My bcc compiler, which also calls printf in msvcrt, does it in 2.3
> > seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
> > Clang is 21 seconds (which is taking being a gcc clone to extremes).
> >
> > All very strange. I don't know how much this is important, or how much
> > text you're printing to the screen, since 500 printfs per second is
> > still faster than anyone can read it. The problem disappears if you
> > redirect to a file.
> It might depend on whether the output stream is buffered or not.
> I'd expect output to the console to be unbuffered.
> What happens if you change it to fully buffered, adding
>
> setvbuf(stdout, NULL, _IOFBF, 0);
>
> at the start of the program?

Such addition changes nothing.
But setvbuf(stdout, NULL, _IOFBF, 512); cuts the run time from 6 sec down to 170-300 msec.

On Monday, August 9, 2021 at 11:38:43 AM UTC+3, Michael S wrote:
> On Monday, August 9, 2021 at 8:46:20 AM UTC+3, Ike Naar wrote:
> > On 2021-08-08, Bart <b...@freeuk.com> wrote:
> > > On 08/08/2021 13:51, DFS wrote:
> > >> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
> > >
> > > You're right; this program:
> > >
> > > #include <stdio.h>
> > > int main(void) {
> > > for (int i=0; i<10000; ++i)
> > > printf("%-16s","1234567890"); // no newlines
> > > }
> > >
> > > runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
> > > never noticed before.
> > >
> > > My bcc compiler, which also calls printf in msvcrt, does it in 2.3
> > > seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
> > > Clang is 21 seconds (which is taking being a gcc clone to extremes).
> > >
> > > All very strange. I don't know how much this is important, or how much
> > > text you're printing to the screen, since 500 printfs per second is
> > > still faster than anyone can read it. The problem disappears if you
> > > redirect to a file.
> > It might depend on whether the output stream is buffered or not.
> > I'd expect output to the console to be unbuffered.
> > What happens if you change it to fully buffered, adding
> >
> > setvbuf(stdout, NULL, _IOFBF, 0);
> >
> > at the start of the program?
> Such addition changes nothing.
> But setvbuf(stdout, NULL, _IOFBF, 512); cuts the run time from 6 sec down to 170-300 msec.

BTW, by setting setvbuf(stdout, NULL, _IONBF, 0); I was able to reproduce a "slow" behaviour with Microsoft's dev tools.

On 09/08/2021 01:46, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 08/08/2021 22:17, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are
>>>> told to use printf, yet only these two compilers end up being slow.
>>> I thought you said the problem goes away when the output is redirected?
>>> gcc and clang don't generate code that does not call printf when the
>>> output is redirected.
>>
>> I thought I explained what might have been happening: gcc might end up
>> calling a routine in msvcrt that works a character at a time, rather
>> than a string at a time. And the former might be slower when sent to
>> the console so you don't see a problem with file output.
>
> gcc is a compiler. It generates code that calls printf or similar.

Actually, it doesn't. As I said, it calls an inline version of printf in
its stdio.h, which ends up calling __mingw_vfprintf.

I /can/ get it to call the same printf I do, by using this declaration
in place of stdio.h:

extern int printf(const char*, ...);

The problem is that it - my gcc installation - does something different.

> After that, what happens is nothing to do with gcc.

You're still trying to play that card.

>>>> What can you tell DFS to make fix this problem when using gcc?
>>> To get 1000-fold increase in speed, ditch Windows. If he or she must
>>> use Windows, find out what's taking the time.
>>
>> Where did the 1000-fold increase come from? The slowdown on my last
>> test was about 14 times, in line with what DFS reported.
>

> You reported 21s, I measured 0.007s, both using gcc.

The upper limit of what can be achieved on my Windows system using i/o
via msvcrt.dll seems to be about 1.7 seconds for my test (2000
80-character strings, approx 100K chars per second.

It will slow down in every case if I write much shorter strings, or
single characters.

I can't do much about that. Yet some compilers - sorry compilers plus
whatever components they've been bundled with - exhibit that slowness
even with long strings.

> The difference is
> almost certainly be due to implementation components other than gcc.
>

Sure; I'm using a gcc 'bundle', as nearly everyone will be. But such
installations are huge; most people will have to trust whatever
components have been included.

> You reported 21s, I measured 0.007s, both using gcc.

I think that was test was 10000 16-character strings, with no newlines
so less impact of scrolling. 7ms means 23M characters per second on a
graphical, bit-mapped, scrolling character display.

(Or I assume it is graphical; if a text-mode display, then that's not
playing the game.)

At 23Mcps, I don't know what tricks the terminal driver is doing to
achieve that. Maybe it's writing into a virtual screen (a text-mode
buffer not bit-mapped), and only updating the display intermittently. Or
maybe its better at using whatever hardware acceleration exists.

The tricks could probably be done on Windows too (eg. using DirectDraw
or whatever). But probably not via the clunky console routines that MS
provides.

But that is all besides the point, which is this: gcc/clang
installations on plain Windows using a normal console window, do
something that makes printing via printf even slower than it already is.

On 09/08/2021 06:46, Ike Naar wrote:
> On 2021-08-08, Bart <bc@freeuk.com> wrote:
>> On 08/08/2021 13:51, DFS wrote:
>>> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
>>
>> You're right; this program:
>>
>> #include <stdio.h>
>> int main(void) {
>> for (int i=0; i<10000; ++i)
>> printf("%-16s","1234567890"); // no newlines
>> }
>>
>> runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
>> never noticed before.
>>
>> My bcc compiler, which also calls printf in msvcrt, does it in 2.3
>> seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
>> Clang is 21 seconds (which is taking being a gcc clone to extremes).
>>
>> All very strange. I don't know how much this is important, or how much
>> text you're printing to the screen, since 500 printfs per second is
>> still faster than anyone can read it. The problem disappears if you
>> redirect to a file.
>
> It might depend on whether the output stream is buffered or not.
> I'd expect output to the console to be unbuffered.
> What happens if you change it to fully buffered, adding
>
> setvbuf(stdout, NULL, _IOFBF, 0);
>
> at the start of the program?
>

No, only if I use 512 instead of 0 as posted elsewhere.

On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> On 09/08/2021 01:46, Ben Bacarisse wrote:
> > Bart <b...@freeuk.com> writes:
> >
> >> On 08/08/2021 22:17, Ben Bacarisse wrote:
> >>> Bart <b...@freeuk.com> writes:
> >>
> >>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are
> >>>> told to use printf, yet only these two compilers end up being slow.
> >>> I thought you said the problem goes away when the output is redirected?
> >>> gcc and clang don't generate code that does not call printf when the
> >>> output is redirected.
> >>
> >> I thought I explained what might have been happening: gcc might end up
> >> calling a routine in msvcrt that works a character at a time, rather
> >> than a string at a time. And the former might be slower when sent to
> >> the console so you don't see a problem with file output.
> >
> > gcc is a compiler. It generates code that calls printf or similar.
> Actually, it doesn't. As I said, it calls an inline version of printf in
> its stdio.h, which ends up calling __mingw_vfprintf.
>
> I /can/ get it to call the same printf I do, by using this declaration
> in place of stdio.h:
> extern int printf(const char*, ...);
> The problem is that it - my gcc installation - does something different.
> > After that, what happens is nothing to do with gcc.
> You're still trying to play that card.
> >>>> What can you tell DFS to make fix this problem when using gcc?
> >>> To get 1000-fold increase in speed, ditch Windows. If he or she must
> >>> use Windows, find out what's taking the time.
> >>
> >> Where did the 1000-fold increase come from? The slowdown on my last
> >> test was about 14 times, in line with what DFS reported.
> >
>
> > You reported 21s, I measured 0.007s, both using gcc.
> The upper limit of what can be achieved on my Windows system using i/o
> via msvcrt.dll seems to be about 1.7 seconds for my test (2000
> 80-character strings, approx 100K chars per second.
>
> It will slow down in every case if I write much shorter strings, or
> single characters.
>
> I can't do much about that. Yet some compilers - sorry compilers plus
> whatever components they've been bundled with - exhibit that slowness
> even with long strings.
> > The difference is
> > almost certainly be due to implementation components other than gcc.
> >
> Sure; I'm using a gcc 'bundle', as nearly everyone will be. But such
> installations are huge; most people will have to trust whatever
> components have been included.
> > You reported 21s, I measured 0.007s, both using gcc.
> I think that was test was 10000 16-character strings, with no newlines
> so less impact of scrolling. 7ms means 23M characters per second on a
> graphical, bit-mapped, scrolling character display.
>
> (Or I assume it is graphical; if a text-mode display, then that's not
> playing the game.)
>
> At 23Mcps, I don't know what tricks the terminal driver is doing to
> achieve that. Maybe it's writing into a virtual screen (a text-mode
> buffer not bit-mapped), and only updating the display intermittently. Or
> maybe its better at using whatever hardware acceleration exists.
>

I'd guess, it's much simpler.
A Linux terminal maintains a big queue, which, in absence of special commands from the user,
is polled by rendering thread on consumer end 50 or 60 times per second.
You can see a very similar behavior if you run your "slow" exe from terminal (mintty.exe), supplied with msys2.

I'd guess, something similar can be achieved with cmd.exe console by using non-default console output mode
(see SetConsoleMode()) but I never tried it.

In my practice, I typically *want* printf output to be seen on screen ASAP and don't care in a slightest about achieved throughput. So, I strongly prefer "slow" defaults of cmd.exe and quite often find myself fighting against "fast" defaults of mintty by insertion of fflush().

> The tricks could probably be done on Windows too (eg. using DirectDraw
> or whatever). But probably not via the clunky console routines that MS
> provides.
>
> But that is all besides the point, which is this: gcc/clang
> installations on plain Windows using a normal console window, do
> something that makes printing via printf even slower than it already is.

On 09/08/2021 11:59, Michael S wrote:
> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:

>> At 23Mcps, I don't know what tricks the terminal driver is doing to
>> achieve that. Maybe it's writing into a virtual screen (a text-mode
>> buffer not bit-mapped), and only updating the display intermittently. Or
>> maybe its better at using whatever hardware acceleration exists.
>>
>
> I'd guess, it's much simpler.
> A Linux terminal maintains a big queue, which, in absence of special commands from the user,
> is polled by rendering thread on consumer end 50 or 60 times per second.
> You can see a very similar behavior if you run your "slow" exe from terminal (mintty.exe), supplied with msys2.
>
> I'd guess, something similar can be achieved with cmd.exe console by using non-default console output mode
> (see SetConsoleMode()) but I never tried it.

Let's take this program:

#include <stdio.h>

int main(void) {
for (int i=0; i<1000000; ++i) {
printf("%d\n",i);
}
}

On Windows, using normal-speed printf, it takes 88 seconds to print
those 1 million numbers (about 80Kcps). But all of them get displayed.
(The binary to text conversion, tested using sprintf, is 0.4 seconds of
that.)

How long does the program take on a normal Linux system? Does each of
those one million numbers get displayed? Or is it only the last
screenful at the time that polling for display update gets done.

If not showing every number, and doing one million scroll operations,
then I'd consider that cheating, and would render timings such as 7ms
meaningless.

(My program run with gcc and without setvbuf or other workarounds took 8
minutes, or about 10Kcps, 8 times as slow as it could have been.

This 8x accords with there being about 8 characters output per printf
call, which include crlf (a detail which would make it marginally slower
than Linux anyway).)

On 09/08/2021 14:55, Bart wrote:
> On 09/08/2021 11:59, Michael S wrote:
>> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
>
>>> At 23Mcps, I don't know what tricks the terminal driver is doing to
>>> achieve that. Maybe it's writing into a virtual screen (a text-mode
>>> buffer not bit-mapped), and only updating the display intermittently. Or
>>> maybe its better at using whatever hardware acceleration exists.
>>>
>>
>> I'd guess, it's much simpler.
>> A Linux terminal maintains a big  queue, which, in absence of special
>> commands from the user,
>> is polled by rendering thread on consumer end 50 or 60 times per second.
>> You can see a very similar behavior if you run your "slow" exe from
>> terminal (mintty.exe), supplied with msys2.
>>
>> I'd guess, something similar can be achieved with cmd.exe console by
>> using non-default console output mode
>> (see SetConsoleMode()) but I never tried it.
>
> Let's take this program:
>
> #include <stdio.h>
>
> int main(void) {
>     for (int i=0; i<1000000; ++i) {
>         printf("%d\n",i);
>     }
> }
>
>
> On Windows, using normal-speed printf, it takes 88 seconds to print
> those 1 million numbers (about 80Kcps). But all of them get displayed.
> (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> that.)
>
> How long does the program take on a normal Linux system? Does each of
> those one million numbers get displayed? Or is it only the last
> screenful at the time that polling for display update gets done.
>
> If not showing every number, and doing one million scroll operations,
> then I'd consider that cheating, and would render timings such as 7ms
> meaningless.
>
> (My program run with gcc and without setvbuf or other workarounds took 8
> minutes, or about 10Kcps, 8 times as slow as it could have been.
>
> This 8x accords with there being about 8 characters output per printf
> call, which include crlf (a detail which would make it marginally slower
> than Linux anyway).)
>

I've been mostly staying out of this conversation - I don't have a
Windows system available for any testing. However, I /can/ do some
timings on Linux.

Testing in a terminal window on my desktop (Linux Mint with Mate, so
approximately Gnome 2), it took 2.1 seconds. All million numbers are
there, and I can scroll back through the window buffer to see them.
Running it multiple times did not affect the timing, though the buffer
for the terminal gets bigger as it still holds all the lines. (This is
not typical behaviour on Windows command-prompt windows.)

Running on a Linux virtual console outside of X, it took 117 seconds on
the same system.

Running within a "screen" environment, with a default 1000 line history,
it was 1.85 seconds - it seems likely that the shorter buffer made it
more efficient.

None of that was using any special settings or commands - it's just the
program you gave, compiled with gcc 9 out of the box, no flags.

Piping the output into a file (6.6 million characters), to test the
speed without rendering the text, was about 0.09 seconds.

Timing for "cat" on this file, in a terminal window, was about 1 second.
So was the time taken to run "time ./test | cat".

Make of all that what you will.

On Monday, 9 August 2021 at 15:08:44 UTC+1, David Brown wrote:
> On 09/08/2021 14:55, Bart wrote:
> > On 09/08/2021 11:59, Michael S wrote:
> >> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> >
> >>> At 23Mcps, I don't know what tricks the terminal driver is doing to
> >>> achieve that. Maybe it's writing into a virtual screen (a text-mode
> >>> buffer not bit-mapped), and only updating the display intermittently. Or
> >>> maybe its better at using whatever hardware acceleration exists.
> >>>
> >>
> >> I'd guess, it's much simpler.
> >> A Linux terminal maintains a big queue, which, in absence of special
> >> commands from the user,
> >> is polled by rendering thread on consumer end 50 or 60 times per second.
> >> You can see a very similar behavior if you run your "slow" exe from
> >> terminal (mintty.exe), supplied with msys2.
> >>
> >> I'd guess, something similar can be achieved with cmd.exe console by
> >> using non-default console output mode
> >> (see SetConsoleMode()) but I never tried it.
> >
> > Let's take this program:
> >
> > #include <stdio.h>
> >
> > int main(void) {
> > for (int i=0; i<1000000; ++i) {
> > printf("%d\n",i);
> > }
> > }
> >
> >
> > On Windows, using normal-speed printf, it takes 88 seconds to print
> > those 1 million numbers (about 80Kcps). But all of them get displayed.
> > (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> > that.)
> >
> > How long does the program take on a normal Linux system? Does each of
> > those one million numbers get displayed? Or is it only the last
> > screenful at the time that polling for display update gets done.
> >
> > If not showing every number, and doing one million scroll operations,
> > then I'd consider that cheating, and would render timings such as 7ms
> > meaningless.
> >
> > (My program run with gcc and without setvbuf or other workarounds took 8
> > minutes, or about 10Kcps, 8 times as slow as it could have been.
> >
> > This 8x accords with there being about 8 characters output per printf
> > call, which include crlf (a detail which would make it marginally slower
> > than Linux anyway).)
> >
> I've been mostly staying out of this conversation - I don't have a
> Windows system available for any testing. However, I /can/ do some
> timings on Linux.
>
> Testing in a terminal window on my desktop (Linux Mint with Mate, so
> approximately Gnome 2), it took 2.1 seconds. All million numbers are
> there, and I can scroll back through the window buffer to see them.
> Running it multiple times did not affect the timing, though the buffer
> for the terminal gets bigger as it still holds all the lines. (This is
> not typical behaviour on Windows command-prompt windows.)
>
> Running on a Linux virtual console outside of X, it took 117 seconds on
> the same system.
>
> Running within a "screen" environment, with a default 1000 line history,
> it was 1.85 seconds - it seems likely that the shorter buffer made it
> more efficient.
>
> None of that was using any special settings or commands - it's just the
> program you gave, compiled with gcc 9 out of the box, no flags.
>
> Piping the output into a file (6.6 million characters), to test the
> speed without rendering the text, was about 0.09 seconds.
>
> Timing for "cat" on this file, in a terminal window, was about 1 second.
> So was the time taken to run "time ./test | cat".
>
> Make of all that what you will.
>
On a modern desktop system, parsing a printf format string, applying the
arguments, and creating a sequence of characters to pass to stdout doesn't
take much time. It's what happens after that stage that accounts for the
dufferences, which can be a factor of hundreds of thousands. Scrolling
a bit-mapped display on the CPU on every line write is going to be much
much slower than discarding the characters.

On Monday, August 9, 2021 at 5:08:44 PM UTC+3, David Brown wrote:
> On 09/08/2021 14:55, Bart wrote:
> > On 09/08/2021 11:59, Michael S wrote:
> >> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> >
> >>> At 23Mcps, I don't know what tricks the terminal driver is doing to
> >>> achieve that. Maybe it's writing into a virtual screen (a text-mode
> >>> buffer not bit-mapped), and only updating the display intermittently. Or
> >>> maybe its better at using whatever hardware acceleration exists.
> >>>
> >>
> >> I'd guess, it's much simpler.
> >> A Linux terminal maintains a big queue, which, in absence of special
> >> commands from the user,
> >> is polled by rendering thread on consumer end 50 or 60 times per second.
> >> You can see a very similar behavior if you run your "slow" exe from
> >> terminal (mintty.exe), supplied with msys2.
> >>
> >> I'd guess, something similar can be achieved with cmd.exe console by
> >> using non-default console output mode
> >> (see SetConsoleMode()) but I never tried it.
> >
> > Let's take this program:
> >
> > #include <stdio.h>
> >
> > int main(void) {
> > for (int i=0; i<1000000; ++i) {
> > printf("%d\n",i);
> > }
> > }
> >
> >
> > On Windows, using normal-speed printf, it takes 88 seconds to print
> > those 1 million numbers (about 80Kcps). But all of them get displayed.
> > (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> > that.)
> >
> > How long does the program take on a normal Linux system? Does each of
> > those one million numbers get displayed? Or is it only the last
> > screenful at the time that polling for display update gets done.
> >
> > If not showing every number, and doing one million scroll operations,
> > then I'd consider that cheating, and would render timings such as 7ms
> > meaningless.
> >
> > (My program run with gcc and without setvbuf or other workarounds took 8
> > minutes, or about 10Kcps, 8 times as slow as it could have been.
> >
> > This 8x accords with there being about 8 characters output per printf
> > call, which include crlf (a detail which would make it marginally slower
> > than Linux anyway).)
> >
> I've been mostly staying out of this conversation - I don't have a
> Windows system available for any testing. However, I /can/ do some
> timings on Linux.
>
> Testing in a terminal window on my desktop (Linux Mint with Mate, so
> approximately Gnome 2), it took 2.1 seconds. All million numbers are
> there, and I can scroll back through the window buffer to see them.

Yes, they are there, in the buffer. But absolute majority of them they quite certainly never were seen on display.
It's just physically impossible, considering that display's vertical refresh
rate is measured in dozens per second.

> Running it multiple times did not affect the timing, though the buffer
> for the terminal gets bigger as it still holds all the lines. (This is
> not typical behaviour on Windows command-prompt windows.)
>

Much worse than "not typical".
For both cmd.exe and powershell not just an "out-of-the-box" default is very short (although less short for powershell), but configurable maximum is also short - 9999 lines.

> Running on a Linux virtual console outside of X, it took 117 seconds on
> the same system.
>
> Running within a "screen" environment, with a default 1000 line history,
> it was 1.85 seconds - it seems likely that the shorter buffer made it
> more efficient.
>
> None of that was using any special settings or commands - it's just the
> program you gave, compiled with gcc 9 out of the box, no flags.
>
> Piping the output into a file (6.6 million characters), to test the
> speed without rendering the text, was about 0.09 seconds.
>
> Timing for "cat" on this file, in a terminal window, was about 1 second.
> So was the time taken to run "time ./test | cat".
>
> Make of all that what you will.

On Monday, August 9, 2021 at 5:54:01 PM UTC+3, Malcolm McLean wrote:
> On Monday, 9 August 2021 at 15:08:44 UTC+1, David Brown wrote:
> > On 09/08/2021 14:55, Bart wrote:
> > > On 09/08/2021 11:59, Michael S wrote:
> > >> On Monday, August 9, 2021 at 12:54:51 PM UTC+3, Bart wrote:
> > >
> > >>> At 23Mcps, I don't know what tricks the terminal driver is doing to
> > >>> achieve that. Maybe it's writing into a virtual screen (a text-mode
> > >>> buffer not bit-mapped), and only updating the display intermittently. Or
> > >>> maybe its better at using whatever hardware acceleration exists.
> > >>>
> > >>
> > >> I'd guess, it's much simpler.
> > >> A Linux terminal maintains a big queue, which, in absence of special
> > >> commands from the user,
> > >> is polled by rendering thread on consumer end 50 or 60 times per second.
> > >> You can see a very similar behavior if you run your "slow" exe from
> > >> terminal (mintty.exe), supplied with msys2.
> > >>
> > >> I'd guess, something similar can be achieved with cmd.exe console by
> > >> using non-default console output mode
> > >> (see SetConsoleMode()) but I never tried it.
> > >
> > > Let's take this program:
> > >
> > > #include <stdio.h>
> > >
> > > int main(void) {
> > > for (int i=0; i<1000000; ++i) {
> > > printf("%d\n",i);
> > > }
> > > }
> > >
> > >
> > > On Windows, using normal-speed printf, it takes 88 seconds to print
> > > those 1 million numbers (about 80Kcps). But all of them get displayed.
> > > (The binary to text conversion, tested using sprintf, is 0.4 seconds of
> > > that.)
> > >
> > > How long does the program take on a normal Linux system? Does each of
> > > those one million numbers get displayed? Or is it only the last
> > > screenful at the time that polling for display update gets done.
> > >
> > > If not showing every number, and doing one million scroll operations,
> > > then I'd consider that cheating, and would render timings such as 7ms
> > > meaningless.
> > >
> > > (My program run with gcc and without setvbuf or other workarounds took 8
> > > minutes, or about 10Kcps, 8 times as slow as it could have been.
> > >
> > > This 8x accords with there being about 8 characters output per printf
> > > call, which include crlf (a detail which would make it marginally slower
> > > than Linux anyway).)
> > >
> > I've been mostly staying out of this conversation - I don't have a
> > Windows system available for any testing. However, I /can/ do some
> > timings on Linux.
> >
> > Testing in a terminal window on my desktop (Linux Mint with Mate, so
> > approximately Gnome 2), it took 2.1 seconds. All million numbers are
> > there, and I can scroll back through the window buffer to see them.
> > Running it multiple times did not affect the timing, though the buffer
> > for the terminal gets bigger as it still holds all the lines. (This is
> > not typical behaviour on Windows command-prompt windows.)
> >
> > Running on a Linux virtual console outside of X, it took 117 seconds on
> > the same system.
> >
> > Running within a "screen" environment, with a default 1000 line history,
> > it was 1.85 seconds - it seems likely that the shorter buffer made it
> > more efficient.
> >
> > None of that was using any special settings or commands - it's just the
> > program you gave, compiled with gcc 9 out of the box, no flags.
> >
> > Piping the output into a file (6.6 million characters), to test the
> > speed without rendering the text, was about 0.09 seconds.
> >
> > Timing for "cat" on this file, in a terminal window, was about 1 second.
> > So was the time taken to run "time ./test | cat".
> >
> > Make of all that what you will.
> >
> On a modern desktop system, parsing a printf format string, applying the
> arguments, and creating a sequence of characters to pass to stdout doesn't
> take much time.

Funny that you are saying that.
Waiting for printf to finish writing to file (on decent SSD, nontheless, so I/O does not appears
to be a major bottleneck) is what made my today's job uncomfortable.
printf of 180M floating point numbers takes more than 2 minutes which is quite disruptive
to a workflow.

> It's what happens after that stage that accounts for the
> dufferences, which can be a factor of hundreds of thousands. Scrolling
> a bit-mapped display on the CPU on every line write is going to be much
> much slower than discarding the characters.

Bart <bc@freeuk.com> writes:

> On 09/08/2021 01:46, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 08/08/2021 22:17, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> The 'problem' is with clang/gcc calling 'printf'. All compilers are
>>>>> told to use printf, yet only these two compilers end up being slow.
>>>> I thought you said the problem goes away when the output is redirected?
>>>> gcc and clang don't generate code that does not call printf when the
>>>> output is redirected.
>>>
>>> I thought I explained what might have been happening: gcc might end up
>>> calling a routine in msvcrt that works a character at a time, rather
>>> than a string at a time. And the former might be slower when sent to
>>> the console so you don't see a problem with file output.
>> gcc is a compiler. It generates code that calls printf or similar.
>
> Actually, it doesn't. As I said, it calls an inline version of printf
> in its stdio.h, which ends up calling __mingw_vfprintf.

"... or similar". I did not want to have to list all the possible
printf-like functions (some of which are going to be internal ones like
this) that it might call.

>> After that, what happens is nothing to do with gcc.
>
> You're still trying to play that card.

Curious spin. My spin: it's called using words correctly. There is no
doubt you have a terrible C implementation (well, two actually, since
you also report absurdly slow times for what you call "tcc"), but I
don't see any evidence that gcc (or tcc for that matter) is the problem.

If you wanted to fix it, you'd have to know what components are really
contributing to the times you see.

--
Ben.

On 09/08/2021 16:19, Michael S wrote:
> On Monday, August 9, 2021 at 5:08:44 PM UTC+3, David Brown wrote:
>> On 09/08/2021 14:55, Bart wrote:
>>> On 09/08/2021 11:59, Michael S wrote:

>>> How long does the program take on a normal Linux system? Does each of
>>> those one million numbers get displayed? Or is it only the last
>>> screenful at the time that polling for display update gets done.
>>>
>>> If not showing every number, and doing one million scroll operations,
>>> then I'd consider that cheating, and would render timings such as 7ms
>>> meaningless.

>> I've been mostly staying out of this conversation - I don't have a
>> Windows system available for any testing. However, I /can/ do some
>> timings on Linux.
>>
>> Testing in a terminal window on my desktop (Linux Mint with Mate, so
>> approximately Gnome 2), it took 2.1 seconds. All million numbers are
>> there, and I can scroll back through the window buffer to see them.
>
> Yes, they are there, in the buffer. But absolute majority of them they quite certainly never were seen on display.
> It's just physically impossible, considering that display's vertical refresh
> rate is measured in dozens per second.

I don't know exactly how today's displays work. But in the past
certainly, you usually had some dedicated video memory, which is what
your application wrote into via OS calls.

There was a separate circuit which scanned that video memory once per
frame to update the physical display (CRT, whatever).

So it was quite possible to update the video memory faster than the
display could be updated. So that it wouldn't show all the output even
if you filmed the display and played it back in slow motion.

What takes the time is rendering text into that video memory, and also
scrolling that window for each new line.

What's in question is whether the Linux drivers bother rendering every
single change, asynchronously from the display frame rate, or only do so
once per frame. So it may show 1 to 60 (for 60 rows) and the next frame
it might show rows 1000 to 1059 which are the last 60 rows in the /text/
buffer.

It's possible that Windows also does something of the sort, but that
other parts are slow (and slower than the frame rate) so that you end up
seeing all the output.

However the discussion is about how some compilers make the display even
slower than it is.

>
>> Running it multiple times did not affect the timing, though the buffer
>> for the terminal gets bigger as it still holds all the lines. (This is
>> not typical behaviour on Windows command-prompt windows.)
>>
>
> Much worse than "not typical".
> For both cmd.exe and powershell not just an "out-of-the-box" default is very short (although less short for powershell), but configurable maximum is also short - 9999 lines.

The scrolling buffer I use is the same height as the console window - 60
lines. (Otherwise various bugs manifest themselves.)

On 09/08/2021 16:47, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 09/08/2021 01:46, Ben Bacarisse wrote:

>>> After that, what happens is nothing to do with gcc.
>>
>> You're still trying to play that card.
>
> Curious spin. My spin: it's called using words correctly. There is no
> doubt you have a terrible C implementation (well, two actually, since
> you also report absurdly slow times for what you call "tcc"),

tcc and bcc can print stuff to the console as fast as anything else.

If those 1000000 numbers were written to a file, and then I got the OS
to display that file using TYPE, it will take 88 or whatever seconds
just like the C program.

If you're getting silly times like 7msec, then that's likely an illusion
as discussed in recent posts, since you're only seeing a snapshot of the
output once per frame.

> but I
> don't see any evidence that gcc (or tcc for that matter) is the problem.

The problem here is NOT that Windows has slow console printing. All
language/all apps will share that problem.

The problem is that gcc and clang are N times slower than that, where N
is the average length of the string that printf ends up outputting.

There are workarounds but, out-of-the-box, that is what those products
do on their Windows installations.

(Note that Clang has a more official Windows binary download site than
gcc, but it is just as slow. Maybe it is just trying to be compatible.)

On 8/9/2021 4:29 AM, Michael S wrote:
> On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote:
>> On 8/8/2021 6:30 PM, Michael S wrote:
>>
>>> Bart and DFS are unique people with unique capabilities. DFS
>>> more so,
>> What are you babbling about?
>
> Your shared love to strange tools that wouldn't in top#5 list of
> choice of professional and likely not in top#10.

tcc was begat from contest-winning obfuscated C code.

https://bellard.org/otcc/

Can gcc or any other 'professional' product beat that? I think not.

>>> but Bart's ability to hit roadbles that almost nobody else hit
>>> also shouldn't be underestimated.
>> There's no reason for anyone to get different results that what
>> Bart and I experienced.
>>
>> Running Win10 21H1. Wanted a better compiler than tcc (0.9.27), so
>> I installed the gcc from:
>>
>> https://github.com/brechtsanders/winlibs_mingw/releases/download/11.2.0-12.0.1-9.0.0-r1/winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64-9.0.0-r1.7z
>>
>> (gcc 11.2.0)
>
> That loooks like mingw-64. The same compiler/libraries that I tried
> first and that finished the task in 20 msec - 1000 times faster than
> you (or Bart) reported.

I ran mine in a Windows cmd shell.

> AFAIK, it's C RTL is based on Microsoft's DLL that was originally
> distributed with VS2013. Recently, they (MSYS2 maintainers) added a
> variant of library that is called ucrt-something, probably based on
> more up to date Microsoft's DLL. I didn't try it yet.
>
> I didn't see the slowness because I was running it from msys2
> command window, i.e. the same environment in which that it was tested
> by maintainers. When I take generated exe file and try to run it in
> regular windows command window (cmd.exe) or in powershell window
> then I see extreme slowness - order of 4.5 sec in cmd.exe and 6.5 sec
> in powereshell. When I changed the size of cmd window to
> "traditional" defaults of 80x25, it slowed down to 6 seconds.

You might look into ConEmu for Windows, a most excellent terminal
program. You can load up many different shells, including MSYS2 and WSL
Bash, very easily.

https://conemu.github.io/en/Tasks.html#add-default-tasks

>> $gcc -Wall source.c -o prog.exe
>>
>> created a huge executable that ran printf() very slowly.
>>
>
> Huge executive is due to presence of symbols. gcc -s (symbols
> stripped) is just big, not huge.

gcc: 85435
tcc: 15360

5.5x larger than the tcc version is huge.

> Slowness is due to interaction between startup code in mingw64
> library and windows command prompt environment, probably not
> provisioned by maintainers since they expect their console programs
> to be run under msys2.

OK.

> As said by several people here, under such combo stdout behaves as
> unbuffered. So, 160,000 system calls. By themselves, 160,000 system
> calls are not particularly slow, but Windows console subsystem seems
> obliged to redraw the whole window each time the character does not
> fit in window width. Or, may be, even more often, may be, once per
> character. So far I didn't figure out how to find exact details.
>
>>
>> Tried another one:
>>
>> https://github.com/skeeto/w64devkit/releases/tag/v1.8.0 (gcc
>> 11.1.0)
>>
>
> If you want to use msys2-maintained gcc compiler then I strongly
> recommend to stick to "official" msys2 distribution.
> https://www.msys2.org/

Haven't used it in a while, but I'll give it another try.

<snipped rest>

On 09/08/2021 09:29, Michael S wrote:
> On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote:
>> On 8/8/2021 6:30 PM, Michael S wrote:
>>
>>> Bart and DFS are unique people with unique capabilities. DFS more so,
>> What are you babbling about?
>
> Your shared love to strange tools that wouldn't in top#5 list of choice of professional and likely not in top#10.

You just don't get it.

When I drive to the shops I like to use my hatchback, I don't need a
40-ton truck, or a 747, which are how big and cumbersome those
professional tools appear to me. (And if younger I'd jump on my bike.)

Who cares about the top 10 anyway? Where was the top 10 when I needed a
tiny, fast HLL language for my 8-bit micros which actually ran ON those
same micros? I've used my own languages ever since.

And when I have to play with C, I prefer my own small C compiler; you
know, that one with the faster printf than gcc/tdm.

> That loooks like mingw-64. The same compiler/libraries that I tried first and that finished the task in 20 msec - 1000 times faster than you (or Bart) reported.

A figure which I think you helped to debunk. But the issue at hand is
what to about the gcc version that runs under the exact same environment
as tcc.

> AFAIK, it's C RTL is based on Microsoft's DLL that was originally distributed with VS2013.
> Recently, they (MSYS2 maintainers) added a variant of library that is called ucrt-something,
> probably based on more up to date Microsoft's DLL. I didn't try it yet.
>
> I didn't see the slowness because I was running it from msys2 command window, i.e. the same environment in which that it was tested by maintainers.
> When I take generated exe file and try to run it in regular windows command window (cmd.exe)
> or in powershell window then I see extreme slowness - order of 4.5 sec in cmd.exe and 6.5 sec in powereshell.
> When I changed the size of cmd window to "traditional" defaults of 80x25, it slowed down to 6 seconds.

OK, that's more helpful. Now run tcc in the same way, or just use any
means to write the equivalent text to a file, and use TYPE to display
it. If that's much faster than doing it from the gcc-compiled program,
then you've reproduced the problem.

We don't need it 1000 times faster, just as fast as TYPE.

>
>>
>> $gcc -Wall source.c -o prog.exe
>>
>> created a huge executable that ran printf() very slowly.
>>
>
> Huge executive is due to presence of symbols. gcc -s (symbols stripped) is just big, not huge.
>
> Slowness is due to interaction between startup code in mingw64 library and windows command prompt environment,
> probably not provisioned by maintainers since they expect their console programs to be run under msys2.
>
> As said by several people here, under such combo stdout behaves as unbuffered. So, 160,000 system calls.
> By themselves, 160,000 system calls are not particularly slow, but Windows console subsystem seems obliged
> to redraw the whole window each time the character does not fit in window width.

Huh? The timings I get strongly suggest that something that should be
done per-string, is getting done per-character. Nothing to do with
window width, which is anyway a long way the other side of the C runtime
library they both end up calling.

>> gcc Windows: slow 3.15s
>> tcc Windows: quick 0.24s
>> gcc Linux : incredibly quick (like 0.01, no time to blink)
>>
>
> 0.01 I'd call o.k. rather than "incredibly quick"

So what is the upper limit of characters per second that can be
genuinely displayed in a Linux terminal window?

Assuming a character is a bitmapped 12x16 font, on a 24-bit display,
then writing one character cell (forget antialiasing and such) involves
writing 600 bytes to video memory. The 23Mcps figure of Ben's (I think
7ms to do 160K characters), would involve writing 13GB/s to video
memory. And that's without handling scrolling.

Bart <bc@freeuk.com> writes:
[...]
> And when I have to play with C, I prefer my own small C compiler; you
> know, that one with the faster printf than gcc/tdm.

Really? Your *compiler* implements printf? Not the runtime library?

Yes, the distinction matters.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 10/08/2021 00:45, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> And when I have to play with C, I prefer my own small C compiler; you
>> know, that one with the faster printf than gcc/tdm.
>
> Really? Your *compiler* implements printf? Not the runtime library?
>
> Yes, the distinction matters.
>
> [...]
>

Not to most normal people, where a language and its implementation is
just expected to provide print facilities.

The same goes for C. And no the distinction doesn't really matter unless
you come from the Unix world, which apparently 'owns' C and gets to
decide all this stuff.

The 'faster' printf I'm refering to is the one inside msvcrt.dll, which
my gcc/tdm and clang/llvm don't appear capable of using without some
arm-twisting.

(Would it be that remarkable to implement a function like 'printf'?
That's the sort of thing I used to do all the time. But since it's
available in msvcrt.dll, there's no point in repeating stuff I've done
innumerable times.)

Bart <bc@freeuk.com> writes:
> On 10/08/2021 00:45, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> And when I have to play with C, I prefer my own small C compiler; you
>>> know, that one with the faster printf than gcc/tdm.
>> Really? Your *compiler* implements printf? Not the runtime
>> library?
>> Yes, the distinction matters.
>> [...]
>
> Not to most normal people, where a language and its implementation is
> just expected to provide print facilities.
>
> The same goes for C. And no the distinction doesn't really matter
> unless you come from the Unix world, which apparently 'owns' C and
> gets to decide all this stuff.
>
> The 'faster' printf I'm refering to is the one inside msvcrt.dll,
> which my gcc/tdm and clang/llvm don't appear capable of using without
> some arm-twisting.
>
> (Would it be that remarkable to implement a function like 'printf'?
> That's the sort of thing I used to do all the time. But since it's
> available in msvcrt.dll, there's no point in repeating stuff I've done
> innumerable times.)

You continue to pretend not to understand the distinction between a
compiler and an implementation in a thread that demonstrates just how
important that distinction is.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 8/9/2021 4:45 PM, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> And when I have to play with C, I prefer my own small C compiler; you
>> know, that one with the faster printf than gcc/tdm.
>
> Really? Your *compiler* implements printf? Not the runtime library?
>
> Yes, the distinction matters.
>

While `printf` is certainly a library feature from the formal point of
view, it is not unusual to see it implemented as an intrinsic at
compiler level in modern implementations. GCC will happily replace

printf("Hello World\n");

with

puts("Hello World");

at compile-time.

--
Best regards,
Andrey Tarasevich