Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: else ladders practice Date: Wed, 20 Nov 2024 14:21:35 +0000 Organization: A noiseless patient Spider Lines: 78 Message-ID: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 20 Nov 2024 15:21:35 +0100 (CET) Injection-Info: dont-email.me; posting-host="44c3c689fff86cf7feb39046d1b84d39"; logging-data="142958"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19qyLLCB12aY068457TL82C" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:DpMkFmtqMevsbRTE/741KTgDlig= Content-Language: en-GB In-Reply-To: Bytes: 4473 On 20/11/2024 13:42, Scott Lurndal wrote: > Bart writes: >> On 19/11/2024 23:41, Waldek Hebisch wrote: >>> Bart wrote: >> > >> >> It's funny how nobody seems to care about the speed of compilers (which >> can vary by 100:1), but for the generated programs, the 2:1 speedup you >> might get by optimising it is vital! > > I don't consider it funny at all, rather it is simply the way things > should be. One compiles once. Hmm, someone else who develops software, either without needing to compile code in order to test it, or they write a 1M-line app and it compiles and runs perfectly first time! Sounds like some more gaslighting going on: people develop huge applications, using slow, cumbersome compilers where max optimisations are permanently enabled, and yet they have instant edit-compile-run cycles or they apparently don't need to bother with a compiler at all! > One's customer runs the resulting > executable perhaps millions of times. Sure. That's when you run a production build. I can even do that myself on some programs (the ones where my C transpiler still works) and pass it through gcc-O3. Then it might run 30% faster. However, each of the 1000s of compilations before that point are pretty much instant. >> >> Here I might borrow one of your arguments and suggest such a speed-up is >> only necessary on a rare production build. > > And again, you've clearly never worked with any significantly > large project. Like for instance an operating system. No. And? That's like telling somebody who likes to devise their own bicycles that they've never worked on a really large conveyance, like a jumbo jet. Unfortunately a bike as big, heavy, expensive and cumbersome as an airliner is not really practical. Besides, in the 1980s the tools and apps I did write were probably larger than the OS. All I can remember is that the OS provided a file system and a text display to allow you to launch the application you really wanted. The funny is that it is with large projects that edit-compile-run turnaround times become more significant. I've heard horror-stories of such builds taking minutes or even hours. But everybody here seems to have found some magic workaround where compilation times even on -O3 don't matter at all. >>> machine, I think that available memory (64MB all, about 20MB available >>> to user programs) is too small to run gcc or clang. >> >> >> Only 20,000KB? My first compilers worked on 64KB systems, not all of >> which was available either. > > My first compilers worked on 4KW PDP-8. Not that I have any > interest in _ever_ working in such a constrained environment > ever again. There could be some lessons to be learned however. Since the amount of bloat now around is becoming ridiculous. >> >> None of my recent products will do so now, but they will still fit on a >> floppy disk. > > And, nobody cares. You obviously don't.