| Deutsch English Français Italiano |
|
<v4pnq6$o4fs$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown <david.brown@hesbynett.no> Newsgroups: comp.lang.c Subject: Re: Baby X is bor nagain Date: Mon, 17 Jun 2024 18:21:26 +0200 Organization: A noiseless patient Spider Lines: 117 Message-ID: <v4pnq6$o4fs$1@dont-email.me> References: <v494f9$von8$1@dont-email.me> <v49seg$14cva$1@raubtier-asyl.eternal-september.org> <v49t6f$14i1o$1@dont-email.me> <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org> <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me> <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com> <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com> <v4okn9$flpo$2@dont-email.me> <v4p37r$k32n$1@dont-email.me> <v4pei3$m5th$2@dont-email.me> <v4plsk$nn9o$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 17 Jun 2024 18:21:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="6eee6dfb82180fb756db1a7758fc4b5a"; logging-data="791036"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ABGH6imn8FBV67YDc6yfMIy/SJTiCZS8=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:mwJnMkaxgMByvfWDMvlvk3flZvM= Content-Language: en-GB In-Reply-To: <v4plsk$nn9o$2@dont-email.me> Bytes: 7285 On 17/06/2024 17:48, Malcolm McLean wrote: > On 17/06/2024 14:43, David Brown wrote: >> On 17/06/2024 12:30, bart wrote: >>> On 17/06/2024 07:22, James Kuyper wrote: >>>> On 6/13/24 10:43, Michael S wrote: >>>>> On Thu, 13 Jun 2024 13:53:54 +0200 >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>> ... >>>>>> I know more than most C programmers about how certain C compilers >>>>>> work, and what works well with them, and what is relevant for them - >>>>>> though I certainly don't claim to know everything. Obviously Bart >>>>>> knows vastly more about how /his/ compiler works. He also tends to >>>>>> do testing with several small and odd C compilers, which can give >>>>>> interesting results even though they are of little practical >>>>>> relevance for real-world C development work. >>>>>> >>>>> >>>>> Since he do compilers himself, he has much better feeling [that you >>>>> or me] of what is hard and what is easy, what is small and what is >>>>> big, >>>>> what is fast and what is slow. That applies to all compilers except >>>>> those that are very unusual. "Major" compiler are not unusual at all. >>>> >>>> The problem is that Bart's compiler is VERY unusual. It's customized >>>> for >>>> his use, and he has lots of quirks in the way he thinks compilers >>>> should >>>> work, which are very different from those of most other programmers. >>> >>> >>>> In >>>> particular, compilation speed is very important to him, while execution >>>> speed is almost completely unimportant, which is pretty much the >>>> opposite of the way most programmers prioritize those things. >>> >>> Compilation speed is important to everyone. That's why so many tricks >>> are used to get around the lack of speed in a big compiler, or so >>> many extra resources are thrown at the problem. >> >> What "tricks" ? >> >>> >>> Runtime performance is important too, but at this level of language, >>> the difference between optimised and unoptimised code is narrow. >>> Unoptimised may be between 1x and 2x slower, typically. >> >> That depends on the language, type of code, and target platform. >> Typical C code on an x86_64 platform might be two or three times >> slower when using a poorly optimising compiler. After all, the >> designers of x86 cpus put a great deal of effort into making shitty >> code run fast. For high-performance code written with care and >> requiring fast results, the performance difference will be bigger. >> For C++, especially code that makes good use of abstractions, the >> difference can be very much bigger. For C code on an embedded ARM >> device or other microcontroller, it's not unusual to see a 5x speed >> improvement on optimised code. >> >> Speed is not the only good reason for picking C as the language for a >> task, but it is often a relevant factor. And if it is a factor, then >> you will usually prefer faster speeds. >> >>> >>> Perhaps slower on benchmarks, or code written in C++ style that >>> generates lots of redundances that relies on optimisation to make it >>> fast. >>> >>> But, during developement, you probably wouldn't use optimisation anyway. >>> >> >> I virtually always have optimisation enabled during development. I >> might, when trying to chase down a specific bug, reduce some specific >> optimisations, but I have never seen the point of crippling a >> development tool when doing development work - it makes no sense at all. >> > I never do. > Until I had to give up work, I was making real time tools for artists. > And if it didn't work in under just noticeable time on the debug build, > it wouldn't be working in under just noticeable time on the release > build, you could be pretty sure. So I never turned the release build on, > but of course the downstream deployment team built it as release for > delivery to customers. And that might mean that they could do 2000 paths > instead of 1000 before the tool slowed to the point that it became > unusable. So not a game changer. But not something to deprive a customer > of either. > Having a distinction in optimisation between "debug" and "release" builds is simply /wrong/. Release what you have debugged, debug what you intend to release. Sometimes it is helpful to fiddle with optimisation settings for specific debugging tasks - though usually it is better to do this for specific files or functions. And of course the more heavyweight debugging tools, such as sanitizers, are used during development and not in releases. Optimisation is important. Right out the gate, it means you can let your tools do a much better job of static analysis (though it is possible to treat static analysis as a separate tool from compilation), and you never want to leave bugs to testing if your tools can find them at static analysis stage. The more problems you find out early, the better. The other major point to optimisation is it means you can use better abstractions. You don't need to use outdated and unsafe function-like macros - you can use proper functions. You can split code up into smaller parts, make new variables as and when they are convenient, and in general write clearer and more maintainable code because you are leaving the donkey work of optimisation up to the compiler. Basically, if you are not using a good optimising compiler, and have optimisation enabled, then the chances are high that C is the wrong choice of language for the task. Using C without optimisation is like driving a car but refusing to go out of first gear. You would probably have been better off with a bicycle or driving a tank, according to the task at hand.