Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> 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.

Yes, a compiler can take advantage of standard guarantees about how
standard library functions behave. But it's practical to do so only in
some very narrow special cases. There still has to be a complete
implementation of printf, including interpreting the format string, and
that's provided by the runtime library.

In principle a compiler can do anything that implements the required
behavior, but as far as I know no compilers do that for printf other
than in a few narrow cases.

--
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 Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote:
> 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.

Assuming infinitely fast CPU, the upper limit is a speed of writing characters (not bitmaps!) to main system RAM by app (C RTL) and then reading them back by renderer. So, on high-end desktop with dual-channel DDR4-3200, ~25,000 Mcps.
Ben's results are lower by 3 orders of magnitude. There is plenty of room for improvements ;-)
Of those billions, only 80x25*60 = 120 Kcps should be processed to bitmaps and transferred to graphics hardware.

On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote:
> 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.)

I prefer my own feet.

>
> 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.

Back in late 70s or early 80s "official" development systems were running on minis that
were costing 5-years salary of decent developer. So, tools hosted on something more affordable
made a lot of sense, esp. for devs that didn't work for big organization. And obviously the "target"
is by definition the most affordable, because you have to have it anyway.
Times change. Today a decent development workstation costs less than 1-week salary of crap programmer.

>
> 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.

On Tuesday, 10 August 2021 at 01:33:47 UTC+1, Bart wrote:
> On 10/08/2021 00:45, Keith Thompson wrote:
> > Bart <b...@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.)
>
I've got a modern Apple system. I had to install an old version of Xcode because
the code base used an old version of boost (always the boost). That broke the
commandline version of clang. It couldn't link in the standard runtime library,
because of some weird incompatibility and passing flags didn't help.

Whilst it was tempting to fiddle with the installation, someone else had written
conan scripts to build the code base. I was afraid that I might break this system,
then I wouldn't be able to fix it.

So yes, a simple "Hello world" program no longer worked. It's a genuine problem
with C's way of doing things. The boost problem was eventually fixed and with
everything up to date, the link problem disappeared.

On 10/08/2021 01:52, Keith Thompson wrote:
> 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.
>

I think the [sub-]thread demonstrates exactly the opposite!

The fact is that, outside of Unix (and outside of compilers that
originated in Unix or Unix-like systems, or that try and emulate those)
a compiler is a whole package.

And outside of C, that is generally the case too.

Actually, try and do something different, like compiling this program:

extern int printf(intptr_t);

then gcc/tdm will complain that it it does match what it expects for the
BUILT-IN function 'printf'.

I am just NOT INTERESTED in the 'distinction'.

On 10/08/2021 09:55, Michael S wrote:
> On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote:

>> 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.
>
> Assuming infinitely fast CPU, the upper limit is a speed of writing characters (not bitmaps!) to main system RAM by app (C RTL) and then reading them back by renderer. So, on high-end desktop with dual-channel DDR4-3200, ~25,000 Mcps.
> Ben's results are lower by 3 orders of magnitude. There is plenty of room for improvements ;-)
> Of those billions, only 80x25*60 = 120 Kcps should be processed to bitmaps and transferred to graphics hardware.

I really meant the upper limit on a real machoine. Otherwise why not
assume an infinitely fast renderer too?

I've just tried my 1-1000000 program on Linux (don't ask me which one),
running on an RPi4 (arm64 but using 32-bit code, I think on a par with
my Windows PC).

My 1-1000000 loop was pretty quick, but not instant, at something over 6
seconds (my Windows PC took 88 seconds), with 0 lines of scrollback.

Writing the text from a file, using 'cat', was under half that
(presumably writing one long string instead of 1000000 short ones, but
this made little difference on Windows).

However, that test ought to show approx 1000000 different things on the
screen (ie. terminal window): for each iteration, a new screen, with a
different number on the first row, ought to appear.

But 6.4 seconds times 60Hz refresh rate means only about 400 different
screenfuls are displayed. This also applies to Windows, which will show
5000 different screenfuls over 88 seconds.

At least with gcc/tdm on Windows, you get 40,000 screenshots for your money!

On 10/08/2021 11:03, Malcolm McLean wrote:
> On Tuesday, 10 August 2021 at 01:33:47 UTC+1, Bart wrote:
>> On 10/08/2021 00:45, Keith Thompson wrote:
>>> Bart <b...@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.)
>>
> I've got a modern Apple system. I had to install an old version of Xcode because
> the code base used an old version of boost (always the boost). That broke the
> commandline version of clang. It couldn't link in the standard runtime library,
> because of some weird incompatibility and passing flags didn't help.
>
> Whilst it was tempting to fiddle with the installation, someone else had written
> conan scripts to build the code base. I was afraid that I might break this system,
> then I wouldn't be able to fix it.
>
> So yes, a simple "Hello world" program no longer worked. It's a genuine problem
> with C's way of doing things. The boost problem was eventually fixed and with
> everything up to date, the link problem disappeared.
>

Any language should and usually does provide arrangements for doing i/o.
Whether that is done by built-in features, or libraries written in user
code, is that not important, provided it is self-contained.

(Note that C provides library functions called as though they are
ordinary functions, but it was necessary to add variadic arguments to
make them work as needed. A little untidy.)

In my case, and for console/file destinations, my own runtime (not for
C) eventually ends up calling printf or fprintf from the C library, with
one of these formats to print a single string or single character:

"%s" "%.*s" "*.c"

since it handles all the to-string convertions. (Except for floats where
it uses one of e, f or g with sprintf; it's too much fiddly work
otherwise; I've done it enough times.)

That C library is msvcrt.dll which is a component of Windows (or, when I
tinkered with Linux, it was libc.so.6 or some such library).

So there is no intermediate dependency between my implementation, and
the OS, that someone could tinker with.

According to Keith, every C implementation consists of assorted
components like this:

* Possibly, a discrete preprocessor
* Compiler
* Standard headers
* Assembler
* Linker
* Standard library
* Extensions

which everyone who ever installs an implementation is expected to obtain
from different sources and mix and match to create a custom C system.

Which doesn't really happen. Certainly I've never done it. (Apparently
Unix systems are different and most of these components 'belong' to the
OS, not to a language.)

In the case of my C compiler, everything necessary is bundled into one
executable, except for the standard library, which comes with the OS.

On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote:
> 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.

I checked again.
Shorter lines that do not cause screen width overflow (Your original test, modified
by changing format string to "%-16s\n") are printed faster than ultra-long lines in original test.
The difference is not big, around 25%, but consistent.

> >> 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:
[...]
> According to Keith, every C implementation consists of assorted
> components like this:
>
> * Possibly, a discrete preprocessor
> * Compiler
> * Standard headers
> * Assembler
> * Linker
> * Standard library
> * Extensions
>
> which everyone who ever installs an implementation is expected to
> obtain from different sources and mix and match to create a custom C
> system.

That is a lie. I did not say that.

[...]

--
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 */

Bart <bc@freeuk.com> writes:
> On 10/08/2021 01:52, Keith Thompson wrote:
[...]
>> 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.
>
> I think the [sub-]thread demonstrates exactly the opposite!
>
> The fact is that, outside of Unix (and outside of compilers that
> originated in Unix or Unix-like systems, or that try and emulate
> those) a compiler is a whole package.

You use TDM-GCC. Yes, it's a "whole package" by the time you download
it, but it was assembled from independent components.

> And outside of C, that is generally the case too.
>
> Actually, try and do something different, like compiling this program:
>
> extern int printf(intptr_t);
>
> then gcc/tdm will complain that it it does match what it expects for
> the BUILT-IN function 'printf'.

Yes, because it knows what the standard guarantees for the printf
function, not because it knows anything about a particular library
implementation.

> I am just NOT INTERESTED in the 'distinction'.

You're interested enough to argue about it every time someone mentions
it.

--
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 19:22, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 10/08/2021 01:52, Keith Thompson wrote:
> [...]
>>> 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.
>>
>> I think the [sub-]thread demonstrates exactly the opposite!
>>
>> The fact is that, outside of Unix (and outside of compilers that
>> originated in Unix or Unix-like systems, or that try and emulate
>> those) a compiler is a whole package.
>
> You use TDM-GCC. Yes, it's a "whole package" by the time you download
> it, but it was assembled from independent components.

How many different ones are there (I mean as downloadable, assembled,
complete products for other people to use) for plain Windows, and how do
they differ?

gcc itself probably consists of lots of different components too,
written by 100s of people; where does it end?

>> And outside of C, that is generally the case too.
>>
>> Actually, try and do something different, like compiling this program:
>>
>> extern int printf(intptr_t);
>>
>> then gcc/tdm will complain that it it does match what it expects for
>> the BUILT-IN function 'printf'.
>
> Yes, because it knows what the standard guarantees for the printf
> function, not because it knows anything about a particular library
> implementation.
>
>> I am just NOT INTERESTED in the 'distinction'.
>
> You're interested enough to argue about it every time someone mentions
> it.
>

Every time someone moans about my casually saying 'gcc' when I mean the
entire bundle for plain Windows.

(I've even had to start saying 'plain Windows' now because nobody here
seems capable of using it without doing it through Cygwin or MSYS2 or WSL.)

On 10/08/2021 19:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> According to Keith, every C implementation consists of assorted
>> components like this:
>>
>> * Possibly, a discrete preprocessor
>> * Compiler
>> * Standard headers
>> * Assembler
>> * Linker
>> * Standard library
>> * Extensions
>>
>> which everyone who ever installs an implementation is expected to
>> obtain from different sources and mix and match to create a custom C
>> system.
>
> That is a lie. I did not say that.

You said something like that 5 minutes later:

KT:
> You use TDM-GCC. Yes, it's a "whole package" by the time you download
> it, but it was assembled from independent components.
>

Here's another post:

On 31/07/2021 20:58, Keith Thompson wrote:
> "cc" is as driver program that might invoke several different programs,
> including a preprocessor, a compiler, an assembler, and a linker. It
> was perfectly reasonable for K&R

And another:

On 31/07/2021 05:14, Keith Thompson wrote:
> You very commonly gloss over the distinction between an*implementation*
> and a*compiler*. An implementation consists of several components; the
> compiler is just one of them.

Even if someone doesn't create their own bundle, you imply that they
need to be aware of exactly what it comprises.

(As though I would have any clue as to what is what: I have two gcc
installations; tdm/gcc is 4900 files/215 directories/560MB; the other is
DFS's mingw64, 4850 files/195 directories/850MB.

Clang is part of an LLVM download which is 370 files/34
directories/1730MB, but I believe it still requires MSVC or MSBUILD
tools (I get those confused) for certain parts. I think that MS product
is 12300 files/1330 directories/2550MB.

My own product is 1 file/1 directory/1MB (0 directories really as you
can stick the exe where you want); this one I do have a clue about!)

Bart <bc@freeuk.com> writes:
> On 10/08/2021 19:22, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 10/08/2021 01:52, Keith Thompson wrote:
>> [...]
>>>> 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.
>>>
>>> I think the [sub-]thread demonstrates exactly the opposite!
>>>
>>> The fact is that, outside of Unix (and outside of compilers that
>>> originated in Unix or Unix-like systems, or that try and emulate
>>> those) a compiler is a whole package.
>> You use TDM-GCC. Yes, it's a "whole package" by the time you
>> download
>> it, but it was assembled from independent components.
>
> How many different ones are there (I mean as downloadable, assembled,
> complete products for other people to use) for plain Windows, and how
> do they differ?
>
> gcc itself probably consists of lots of different components too,
> written by 100s of people; where does it end?

Explaining this to you is obviously a waste of time.

[...]

>>> And outside of C, that is generally the case too.
>>>
>>> Actually, try and do something different, like compiling this program:
>>>
>>> extern int printf(intptr_t);
>>>
>>> then gcc/tdm will complain that it it does match what it expects for
>>> the BUILT-IN function 'printf'.
>> Yes, because it knows what the standard guarantees for the printf
>> function, not because it knows anything about a particular library
>> implementation.
>>
>>> I am just NOT INTERESTED in the 'distinction'.
>> You're interested enough to argue about it every time someone
>> mentions
>> it.
>
> Every time someone moans about my casually saying 'gcc' when I mean
> the entire bundle for plain Windows.

Yes, because you complain about 'gcc" not implementing printf correctly.
Again, I'm not going to explain again why that's misleading.

> (I've even had to start saying 'plain Windows' now because nobody here
> seems capable of using it without doing it through Cygwin or MSYS2 or
> WSL.)

I usually use Cygwin myself. Of course poeple are going to use examples
they're familiar with. I am obviously capable of using "plain Windows",
since I discussed doing so just recently.

--
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 */

Bart <bc@freeuk.com> writes:
> On 10/08/2021 19:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> According to Keith, every C implementation consists of assorted
>>> components like this:
>>>
>>> * Possibly, a discrete preprocessor
>>> * Compiler
>>> * Standard headers
>>> * Assembler
>>> * Linker
>>> * Standard library
>>> * Extensions
>>>
>>> which everyone who ever installs an implementation is expected to
>>> obtain from different sources and mix and match to create a custom C
>>> system.
>> That is a lie. I did not say that.
>
> You said something like that 5 minutes later:
>
> KT:
>> You use TDM-GCC. Yes, it's a "whole package" by the time you download
>> it, but it was assembled from independent components.

I did not say or imply that "everyone who ever installs an
implementation" is required to assemble the components. TDM-GCC is
assembled by the maintainers of TDM-GCC. The end user installs it as a
single package.

> Here's another post:
>
> On 31/07/2021 20:58, Keith Thompson wrote:
>> "cc" is as driver program that might invoke several different programs,
>> including a preprocessor, a compiler, an assembler, and a linker. It
>> was perfectly reasonable for K&R

Yes. I said nothing about the end user mixing and matching those
programs.

> And another:
>
> On 31/07/2021 05:14, Keith Thompson wrote:
>> You very commonly gloss over the distinction between an*implementation*
>> and a*compiler*. An implementation consists of several components; the
>> compiler is just one of them.
>
> Even if someone doesn't create their own bundle, you imply that they
> need to be aware of exactly what it comprises.

You lied when you claimed that I said that the end user must obtain the
components from different sources and mix and match them. I never said
or implied that. The mixing and matching is usually done by package
maintainers. And yes, sometimes the components of a given
implementation are developed together and perhaps not intended to be
used with other components.

It can be very useful to understand that an implementation is made up of
components, and which components make up the implementation you're
using. For example, such an understanding can prevent someone from
complaining that gcc doesn't implement printf correctly.

> (As though I would have any clue as to what is what: I have two gcc
> installations; tdm/gcc is 4900 files/215 directories/560MB; the other
> is DFS's mingw64, 4850 files/195 directories/850MB.
>
> Clang is part of an LLVM download which is 370 files/34
> directories/1730MB, but I believe it still requires MSVC or MSBUILD
> tools (I get those confused) for certain parts. I think that MS
> product is 12300 files/1330 directories/2550MB.
>
> My own product is 1 file/1 directory/1MB (0 directories really as you
> can stick the exe where you want); this one I do have a clue about!)

I accept that you have a clue about all this. I think you understand it
perfectly well. The mystery is why you pretend not to and get angry
when someone points it out.

If your own product combines all the elements of a C implementation into
a siungle executable file, that's fine. It's an unusual approach, but I
suppose there's no particular reason not to do it that way.

I presume from context that this single executable file includes the
code that implements printf rather than generating calls to an external
library. If not, it's not a complete C implementation (which would also
be just fine).

--
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/8/2021 12:56 PM, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@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. The
>> compiler probably has little to do with it. What C library is being
>> used? How is the output handled? On my laptop, compiled with gcc
>> 10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>> measure:
>>
>> $ time ./o >/dev/null
>>
>> real 0m0.007s
>> user 0m0.004s
>> sys 0m0.004s
>
> An aggressive optimizer (speed vs space) could optimize it
> into a single puts of a 160,000 character string.

=================================================================

//option 1: one puts per line (suggested by bart)
int i = 0;
char buff[longword+3];
char line[tcols];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
puts(line);
*buff = '\0';
*line = '\0';
}

=================================================================

//option 2: one big string, one puts (per Lurndal)
int i = 0;
char buff[longword+3];
char line[(longword + 3) * matchcnt];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
*buff = '\0';
strcat(line,"\n");
} puts(line);
=================================================================

726 words across 5 columns
option 1: 0.06s
option 2: 0.05s

A significant speed increase.

DFS <nospam@dfs.com> writes:
>On 8/8/2021 12:56 PM, Scott Lurndal wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@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. The
>>> compiler probably has little to do with it. What C library is being
>>> used? How is the output handled? On my laptop, compiled with gcc
>>> 10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>>> measure:
>>>
>>> $ time ./o >/dev/null
>>>
>>> real 0m0.007s
>>> user 0m0.004s
>>> sys 0m0.004s
>>
>> An aggressive optimizer (speed vs space) could optimize it
>> into a single puts of a 160,000 character string.
>
>=================================================================
>
>//option 1: one puts per line (suggested by bart)
>int i = 0;
>char buff[longword+3];
>char line[tcols];
>*line = '\0';
>while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
> }
> puts(line);
> *buff = '\0';
> *line = '\0';
>}
>
>=================================================================
>
>//option 2: one big string, one puts (per Lurndal)
>int i = 0;
>char buff[longword+3];
>char line[(longword + 3) * matchcnt];
>*line = '\0';
>while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
> }
> *buff = '\0';
> strcat(line,"\n");
>}
>puts(line);
>
>=================================================================
>
>
>726 words across 5 columns
>option 1: 0.06s
>option 2: 0.05s
>
>A significant speed increase.

I was suggesting that the compiler could have just
stored a 160k string in RO storage and called puts
with a pointer to it. There is no need to construct
it at runtime.

The entire program would reduce to a single call
to puts with a compiler generated constant string.

On 10/08/2021 22:00, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> My own product is 1 file/1 directory/1MB (0 directories really as you
>> can stick the exe where you want); this one I do have a clue about!)
>
> I accept that you have a clue about all this. I think you understand it
> perfectly well. The mystery is why you pretend not to and get angry
> when someone points it out.
>
> If your own product combines all the elements of a C implementation into
> a siungle executable file, that's fine. It's an unusual approach, but I
> suppose there's no particular reason not to do it that way.
>
> I presume from context that this single executable file includes the
> code that implements printf rather than generating calls to an external
> library. If not, it's not a complete C implementation (which would also
> be just fine).

When I first encountered the C library, I considered it as part of
Windows, since it was described in the same documentation set, and it
has always been shipped with that OS.

I don't therefore see any reason to spend a year or two reimplementating
the 1400 functions in msvcrt.dll, when msvcrt.dll does the job perfectly
well and will always be available.

Especially when the same library is a dynamic import for most EXE and
DLL files, including gcc.exe itself:

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

Executable file gcc.exe
PE Sig:PE
Coff header: (34404,11,0,1283584,0,240,558)
Machine: 8664
.....

Import Directory
.....

Entry: 13c028
Lookup RVA: 13c1f8
Time Date Stamp: 0
Fwd Chain: 0
Name RVA: 13d7bc
Name: msvcrt.dll <<<----------
Import Addr RVA: 13c788
Import:13cf38 38 __C_specific_handler
Import:13cf50 40 ___lc_codepage_func
Import:13cf66 43 ___mb_cur_max_func
Import:13cf7c 52 __getmainargs
.....

Note that my msvcrt.dll is about 600KB. If absolutely necessary it's
possible to bundle it into bcc.exe, and UPX [compress] the resulting
1.7MB file into a compact 0.5MB executable.

On 8/10/2021 2:41 PM, Scott Lurndal wrote:
> DFS <nospam@dfs.com> writes:
>> On 8/8/2021 12:56 PM, Scott Lurndal wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Bart <bc@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. The
>>>> compiler probably has little to do with it. What C library is being
>>>> used? How is the output handled? On my laptop, compiled with gcc
>>>> 10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>>>> measure:
>>>>
>>>> $ time ./o >/dev/null
>>>>
>>>> real 0m0.007s
>>>> user 0m0.004s
>>>> sys 0m0.004s
>>>
>>> An aggressive optimizer (speed vs space) could optimize it
>>> into a single puts of a 160,000 character string.
>>
>> =================================================================
>>
>> //option 1: one puts per line (suggested by bart)
>> int i = 0;
>> char buff[longword+3];
>> char line[tcols];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
>> }
>> puts(line);
>> *buff = '\0';
>> *line = '\0';
>> }
>>
>> =================================================================
>>
>> //option 2: one big string, one puts (per Lurndal)
>> int i = 0;
>> char buff[longword+3];
>> char line[(longword + 3) * matchcnt];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
>> }
>> *buff = '\0';
>> strcat(line,"\n");
>> }
>> puts(line);
>>
>> =================================================================
>>
>>
>> 726 words across 5 columns
>> option 1: 0.06s
>> option 2: 0.05s
>>
>> A significant speed increase.
>
> I was suggesting that the compiler could have just
> stored a 160k string in RO storage and called puts
> with a pointer to it. There is no need to construct
> it at runtime.
>
> The entire program would reduce to a single call
> to puts with a compiler generated constant string.

Gotcha.

I just noticed something in my program. Using option 2 above, the
version compiled by tcc crashes when the value in line 3 is large
(1027424). The version compiled by gcc doesn't crash.

Is that a stack overflow issue?

On 10/08/2021 23:08, DFS wrote:
> On 8/10/2021 2:41 PM, Scott Lurndal wrote:

>> I was suggesting that the compiler could have just
>> stored a 160k string in RO storage and called puts
>> with a pointer to it.   There is no need to construct
>> it at runtime.
>>
>> The entire program would reduce to a single call
>> to puts with a compiler generated constant string.
>
> Gotcha.
>
> I just noticed something in my program.  Using option 2 above, the
> version compiled by tcc crashes when the value in line 3 is large
> (1027424).  The version compiled by gcc doesn't crash.
>
> Is that a stack overflow issue?
>

Yes, you're using VLAs, (maybe in option 1 too if longword and tcols are
not compile-time constants).

Typical stack size is a few MB. It seems the default stack size of tcc
is smaller than of gcc**. tcc crashes with this:

int n=2000000;
char str[n];
memset(str,0,n);

but gcc doesn't, until you change n to 4000000. If I dump the two
executables, then the gcc one contains this:

Stack reserve: 2097152
Stack commit: 4096

tcc's has:

Stack reserve: 1048576
Stack commit: 4096

There are probably ways of increasing the stack size, but better not to
use VLAs for arrays of this size. (Use static arrays or allocate on the
heap.)

(**For the pedantics here, this is not *the* gcc, but my tdm/gcc
version. However the mingw64 version does the same.)

Bart <bc@freeuk.com> writes:
> On 10/08/2021 22:00, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> My own product is 1 file/1 directory/1MB (0 directories really as you
>>> can stick the exe where you want); this one I do have a clue about!)
>> I accept that you have a clue about all this. I think you
>> understand it
>> perfectly well. The mystery is why you pretend not to and get angry
>> when someone points it out.
>> If your own product combines all the elements of a C implementation
>> into
>> a siungle executable file, that's fine. It's an unusual approach, but I
>> suppose there's no particular reason not to do it that way.
>> I presume from context that this single executable file includes the
>> code that implements printf rather than generating calls to an external
>> library. If not, it's not a complete C implementation (which would also
>> be just fine).
>
> When I first encountered the C library, I considered it as part of
> Windows, since it was described in the same documentation set, and it
> has always been shipped with that OS.
>
> I don't therefore see any reason to spend a year or two
> reimplementating the 1400 functions in msvcrt.dll, when msvcrt.dll
> does the job perfectly well and will always be available.

Nobody said you should. Your statements led me to infer, apparently
incorrectly, that you were claiming that your single executable was a
complete implementation.

[...]

--
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/10/2021 6:22 PM, Bart wrote:
> On 10/08/2021 23:08, DFS wrote:
>> On 8/10/2021 2:41 PM, Scott Lurndal wrote:
>
>>> I was suggesting that the compiler could have just
>>> stored a 160k string in RO storage and called puts
>>> with a pointer to it.   There is no need to construct
>>> it at runtime.
>>>
>>> The entire program would reduce to a single call
>>> to puts with a compiler generated constant string.
>>
>> Gotcha.
>>
>> I just noticed something in my program.  Using option 2 above, the
>> version compiled by tcc crashes when the value in line 3 is large
>> (1027424).  The version compiled by gcc doesn't crash.
>>
>> Is that a stack overflow issue?
>>
>
> Yes, you're using VLAs, (maybe in option 1 too if longword and tcols are
> not compile-time constants).

They're not. Longword is the longest word (1 to 31) in a result set,
and tcols is the width of your terminal at the time you do the search.

Here's the app: https://imgur.com/a/cQdvAeM

> Typical stack size is a few MB. It seems the default stack size of tcc
> is smaller than of gcc**. tcc crashes with this:
>
>     int n=2000000;
>     char str[n];
>     memset(str,0,n);
>
> but gcc doesn't, until you change n to 4000000. If I dump the two
> executables, then the gcc one contains this:
>
>   Stack reserve:    2097152
>   Stack commit:     4096
>
> tcc's has:
>
>   Stack reserve:    1048576
>   Stack commit:     4096
>
> There are probably ways of increasing the stack size, but better not to
> use VLAs for arrays of this size. (Use static arrays or allocate on the
> heap.)

Thanks. I created a static array[10_000_000] outside the function, and
it handled large results sets just fine. But another issue popped up,
using option 2, which concatenates words one by one into that static
array, then does one puts() at the end.

Turns out it's VERY slow for large result sets.

Option 1 Option 2
substring catt: 91 matches found 0.04s 0.038s
substring cat : 3710 matches found 0.20s 0.16s
substring ca : 22793 matches found 1.39s 2.25s
substring c : 128689 matches found 7.75s 57.91s
substring e : 252896 matches found 15.29s 216.58s

Option 1 starts printing immediately, one line at a time. Option 2 sits
there constructing that long string for quite a while. Too long I
think. What might I be doing wrong?

Note: the timing includes time to print to screen. Just finding the
word matches is 0.03s using either option.

=================================================================

//option 1: one puts per line (suggested by bart)
int i = 0;
char buff[longword+3];
char line[tcols];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
puts(line);
*buff = '\0';
*line = '\0';
}

=================================================================

//option 2: one big string, one puts (per Lurndal)
static char line[10000000]; //declared outside the func

int i = 0;
char buff[longword+3];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
*buff = '\0';
strcat(line,"\n");
} puts(line);

=================================================================

DFS <nospam@dfs.com> wrote:
>
> Thanks. I created a static array[10_000_000] outside the function, and
> it handled large results sets just fine. But another issue popped up,
> using option 2, which concatenates words one by one into that static
> array, then does one puts() at the end.
>
> Turns out it's VERY slow for large result sets.
>
> Option 1 Option 2
> substring catt: 91 matches found 0.04s 0.038s
> substring cat : 3710 matches found 0.20s 0.16s
> substring ca : 22793 matches found 1.39s 2.25s
> substring c : 128689 matches found 7.75s 57.91s
> substring e : 252896 matches found 15.29s 216.58s
>
> Option 1 starts printing immediately, one line at a time. Option 2 sits
> there constructing that long string for quite a while. Too long I
> think. What might I be doing wrong?
>
> Note: the timing includes time to print to screen. Just finding the
> word matches is 0.03s using either option.
>
>
> =================================================================
>
> //option 1: one puts per line (suggested by bart)
> int i = 0;
> char buff[longword+3];
> char line[tcols];
> *line = '\0';
> while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
> }
> puts(line);
> *buff = '\0';
> *line = '\0';
> }
>
> =================================================================
>
> //option 2: one big string, one puts (per Lurndal)
> static char line[10000000]; //declared outside the func
>
> int i = 0;
> char buff[longword+3];
> *line = '\0';
> while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
^^^^^^^^^^^^^^^^^^
> }
> *buff = '\0';
> strcat(line,"\n");
> }
> puts(line);
>
> =================================================================

The 'strcat' in a loop is classic antipattern: it causes quadratic
complexity to to repeated scanning for end of 'line'. Use something
like

char * cp = line;
.....
strcat(cp, buff);
cp += strlen(buff);
....

--
Waldek Hebisch

On 11/08/2021 01:15, DFS wrote:
> On 8/10/2021 6:22 PM, Bart wrote:
>> On 10/08/2021 23:08, DFS wrote:
>>> On 8/10/2021 2:41 PM, Scott Lurndal wrote:
>>
>>>> I was suggesting that the compiler could have just
>>>> stored a 160k string in RO storage and called puts
>>>> with a pointer to it.   There is no need to construct
>>>> it at runtime.
>>>>
>>>> The entire program would reduce to a single call
>>>> to puts with a compiler generated constant string.
>>>
>>> Gotcha.
>>>
>>> I just noticed something in my program.  Using option 2 above, the
>>> version compiled by tcc crashes when the value in line 3 is large
>>> (1027424).  The version compiled by gcc doesn't crash.
>>>
>>> Is that a stack overflow issue?
>>>
>>
>> Yes, you're using VLAs, (maybe in option 1 too if longword and tcols
>> are not compile-time constants).
>
> They're not.  Longword is the longest word (1 to 31) in a result set,
> and tcols is the width of your terminal at the time you do the search.
>
> Here's the app: https://imgur.com/a/cQdvAeM
>
>
>
>> Typical stack size is a few MB. It seems the default stack size of tcc
>> is smaller than of gcc**. tcc crashes with this:
>>
>>      int n=2000000;
>>      char str[n];
>>      memset(str,0,n);
>>
>> but gcc doesn't, until you change n to 4000000. If I dump the two
>> executables, then the gcc one contains this:
>>
>>    Stack reserve:    2097152
>>    Stack commit:     4096
>>
>> tcc's has:
>>
>>    Stack reserve:    1048576
>>    Stack commit:     4096
>>
>> There are probably ways of increasing the stack size, but better not
>> to use VLAs for arrays of this size. (Use static arrays or allocate on
>> the heap.)
>
>
> Thanks.  I created a static array[10_000_000] outside the function, and
> it handled large results sets just fine.  But another issue popped up,
> using option 2, which concatenates words one by one into that static
> array, then does one puts() at the end.
>
> Turns out it's VERY slow for large result sets.

Because each strcat involves scanning the entire string so far to find
its end.

However, this would have been the case using the VLA too, or was it fast
in that case?

Also, the idea of printing just one giant string to the screen is rather
extreme. Longer strings /are/ printed more quickly compared with very
short ones. But dozens are characters long will be sufficient; they
don't need to be millions of characters!

If you do need to construct a string of millions of characters, you
might try keeping track of the current length as antispam suggested.

Or use a resizable buffer as I normally do it, but this gets complicated.

Or write the text to a temporary file (fprintf), then just display the
file (either load it into memory, or simply use system("type filename").

antispam@math.uni.wroc.pl writes:

> DFS <nospam@dfs.com> wrote:
<cut>
>> =================================================================
>>
>> //option 1: one puts per line (suggested by bart)
>> int i = 0;
>> char buff[longword+3];
>> char line[tcols];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
>> }
>> puts(line);
>> *buff = '\0';
>> *line = '\0';
>> }
>>
>> =================================================================
>>
>> //option 2: one big string, one puts (per Lurndal)
>> static char line[10000000]; //declared outside the func
>>
>> int i = 0;
>> char buff[longword+3];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
> ^^^^^^^^^^^^^^^^^^
>> }
>> *buff = '\0';
>> strcat(line,"\n");
>> }
>> puts(line);
>>
>> =================================================================
>
> The 'strcat' in a loop is classic antipattern: it causes quadratic
> complexity to to repeated scanning for end of 'line'. Use something
> like
>
> char * cp = line;
> .....
> strcat(cp, buff);
> cp += strlen(buff);
> ....

.... or get the length first and use memcpy. But my favourite is

cp += snprintf(cp, "%s", whatever);

--
Ben.

On Wednesday, August 11, 2021 at 1:23:55 PM UTC+3, Ben Bacarisse wrote:
> anti...@math.uni.wroc.pl writes:
>
> > DFS <nos...@dfs.com> wrote:
> <cut>
> >> =================================================================
> >>
> >> //option 1: one puts per line (suggested by bart)
> >> int i = 0;
> >> char buff[longword+3];
> >> char line[tcols];
> >> *line = '\0';
> >> while(i < matchcnt) {
> >> for(int j = 1;j<=maxcols;j++) {
> >> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> >> strcat(line,buff);
> >> }
> >> puts(line);
> >> *buff = '\0';
> >> *line = '\0';
> >> }
> >>
> >> =================================================================
> >>
> >> //option 2: one big string, one puts (per Lurndal)
> >> static char line[10000000]; //declared outside the func
> >>
> >> int i = 0;
> >> char buff[longword+3];
> >> *line = '\0';
> >> while(i < matchcnt) {
> >> for(int j = 1;j<=maxcols;j++) {
> >> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> >> strcat(line,buff);
> > ^^^^^^^^^^^^^^^^^^
> >> }
> >> *buff = '\0';
> >> strcat(line,"\n");
> >> }
> >> puts(line);
> >>
> >> =================================================================
> >
> > The 'strcat' in a loop is classic antipattern: it causes quadratic
> > complexity to to repeated scanning for end of 'line'. Use something
> > like
> >
> > char * cp = line;
> > .....
> > strcat(cp, buff);
> > cp += strlen(buff);
> > ....
> ... or get the length first and use memcpy. But my favourite is
>
> cp += snprintf(cp, "%s", whatever);
>
> --
> Ben.

Don't you mean sprintf() ?
snprintf() requires one more parameter (size of the target buffer) and does *not* return the number of actually written characters when buffer is too small.