Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: How to avoid an overflow during multiplication? Date: Sat, 29 Jan 2022 10:05:55 -0800 Organization: A noiseless patient Spider Lines: 98 Message-ID: <86a6femn7g.fsf@linuxsc.com> References: <86v8ydp57h.fsf@linuxsc.com> <9_BGJ.170561$X2_b.72894@fx09.ams4> <86mtjopoq5.fsf@linuxsc.com> <86v8y9m8ba.fsf@linuxsc.com> <713da016-3175-4d0b-79b6-698d675c2e04@alumni.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="8a9fc8cdb13989d258a574a29792b8b1"; logging-data="16668"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19epnhsEBL0LnXRhXWv0rOde1/8tAI0tXQ=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:IXbJKNwChxg7pb1d4RiN32hYyH0= sha1:4/D6r5c3Xz4zCwf2IM3kbSWLKqA= Xref: csiph.com comp.lang.c:164724 scott@slp53.sl.home (Scott Lurndal) writes: > Manfred writes: > >> On 1/25/2022 3:50 AM, James Kuyper wrote: >> >>> On 1/24/22 11:24, Scott Lurndal wrote: >>> >>>> Tim Rentsch writes: >>> >>> ... >>> >>>>> This is comp.lang.c. My question is about C code, not C++ code. >>>>> C++ is a completely different animal. >>> >>> That's false, but so is the following: >>> >>>> No, it's just C with added capabilities. >>> >>> The C++ standard devotes 8 pages (C.5) to describing differences between >>> the way C and C++ handle a variety of issues, and another pair of pages >>> (C.6) that describe how the version of the C standard library that is >>> supported as part of the C++ standard library differs from the one >>> described by the C standard. That's not a lot out of a standard that >>> runs 1826 pages, but it not entirely negligible, either. >>> >>> Note that those lists do not include the features that C++ has that C >>> doesn't - they're about differences in the way that features shared >>> between the two languages work. >> >> All true; it may also be worth recalling that this subthread is about >> justification of long functions, and that C++ was brought up in this >> comment: >> >>> ... In most cases, they were in bare-metal performance >>> critical code (operating systems, hypervisors) in C and C++. >>> >>> One in particular is the code to handle page table walks in >>> an ARM64 processor simulator. Another was handling the fork() >>> system call in a unix-derived MPP operating system. Both in C++. >> >> Now, it is one of the goals of C++ compared to C to be able to write >> more efficient and thus more compact code. I don't think C++ has failed >> in this respect - the criticism of those who favor C against C++ may be >> about complexity of the language, or lack of expressiveness in terms of >> clarity, but not being more verbose than C. >> >> In particular, with reference to the example posted elsethread, >> replacing long 'switch' blocks with more structured constructs is one >> typical refactoring when porting to C++. > > Can you do that form of refactoring (specifically for a text > formatting function such as the implementation of printf posted > earlier) without sacrificing performance? [further C++ remarks > omitted] Writing in plain C, it isn't difficult to restructure the posted printf-like code into multiple small or reasonably sized functions (no more than 40ish lines, say). The effort needed isn't trivial but it isn't really challenging either. I'm intrigued by the phrase "without sacrificing performance". I see no reason to suppose the performance of a restructured version should be worse than that of the original. (Of course this means on average; most likely some cases would be better and others would be worse, but overall not significantly different.) So I'm wondering why someone would think the performance of the original is going to be better than refactored/restructured alternatives. Looking at subr_prf.c (from the link posted elsethread) offers a clue. The structure of that code is very nearly identical to the code posted here. Looking at the copyright dates, it looks like the subr_prf code was written between about 30 and 35 years ago. At that time there were two significant differences relative to today: processor behavior was less advanced, and compiler technology was less sophisticated. Both of these trends make it more likely that some performance advantage, if there was any, of that earlier code would not accrue for more modern machines when using more modern tools. There are at least two other factors that weigh on the question. One is workload: it is quite possible that alternative A would give better performance than alternative B for one set of inputs, and vice versa for a different set of inputs, and so which alternative is better depends on what distribution of inputs is expected. Another is operating context: these days performance is highly multi-dimensional, being affected by all sorts of things beyond just what sequence of instructions is executed. Here again we might very well see a situation where alternative A is better in one operating environment whereas alternative B is better in a different operating environment. For both of these factors it would be very unusual to see one alternative give better results over all points in the space of plausible scenarios. So it may be the case that the posted code would do better than some proposed restructing, for its expected workload and intended operating environment, etc. Without more specifics, however, the proposition remains unconvincing.