Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: bart Newsgroups: comp.lang.c Subject: Re: Suggested method for returning a string from a C program? Date: Mon, 24 Mar 2025 16:02:57 +0000 Organization: A noiseless patient Spider Lines: 94 Message-ID: References: <20250319115550.0000676f@yahoo.com> <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com> <874izntt5t.fsf@nosuchdomain.example.com> <87ecyrs332.fsf@nosuchdomain.example.com> <20250320171505.221@kylheku.com> <8734f7rw7z.fsf@nosuchdomain.example.com> <87tt7mqk7w.fsf@nosuchdomain.example.com> <87cye9afl0.fsf@nosuchdomain.example.com> <871puoag2q.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 24 Mar 2025 17:02:57 +0100 (CET) Injection-Info: dont-email.me; posting-host="cd36ac246702b474a1548a794b73ffc4"; logging-data="1284798"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX197iCwjiwP7aeOtM9C4/u+f" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:1bSqZIayUIi9vDA012Njd7lB5Os= Content-Language: en-GB In-Reply-To: On 24/03/2025 15:00, Muttley@DastardlyHQ.org wrote: > On Mon, 24 Mar 2025 15:32:32 +0100 > David Brown wibbled: >> On 24/03/2025 15:07, bart wrote: >>> What was strange was that that one view was shared by pretty much >>> everyone in comp.lang.c. >> >> Do you know what the people in comp.lang.c have in common? >> >> We program in C. >> >> Do you know /why/ people program in C? >> >> There can be many reasons, but a very common one is that they want fast >> resulting binaries. Most serious programmers are familiar with more >> than one language, and pretty much all other languages are higher level, >> easier, and have higher developer productivity than C - but the >> resulting binaries are almost always slower. >> >> C programmers are typically not bothered about build times because a) >> their build times are rarely high (Scott's projects are C++), and b), >> they are willing to sacrifice high build times if it means more >> efficient run times. > > I'm not sure what kind of build time he's looking for either. On this Mac > ARM laptop I can compile a 7600 line utility I wrote in C in 0.8 seconds > real time, and that is using a makefile with 18 seperate source files and > a header and includes link time. So unless he's rebuilding the linux kernel > every day I don't see what the problem is. > > loki$ ls *.c *.h | wc -l > 19 > loki$ wc -l *.c *.h > : > : > 691 globals.h > 7602 total > loki$ time make > : > : > real 0m0.815s > user 0m0.516s > sys 0m0.252s So, your throughput is a whopping 9.5K lines/second? Here's a project I'm working at the minute (not in C): c:\bx>tim mm bb Compiling bb.m to bb.exe Time: 0.066 Build time is 1/15th of a second, for about 30K lines (so 450Klps). But I also want to compile this via C, to take advantage of gcc's superior optimiser. So first I transpile to C (that's also under 70ms): c:\bx>mc -c bb Compiling bb.m to bb.c Now I can invoke gcc: c:\bx>tim gcc -O3 -s bb.c -o dd Time: 12.316 The generated C file is 38Kloc, and takes 12 seconds. It takes nearly TWO HUNDRED TIMES longer to build. I can tolerate that from time to time, Using gcc-O0 takes only two seconds, but since it's generating slower code than mine, there is no point: Build time Run time bcc bb 70 ms 628 ms gcc -O0 2000 ms 1517 ms gcc -O3 12300 ms 579 ms (On this test, gcc-O3 was 8% faster, but in depends on the input to this interpreter project. On average it is 25% faster.)