Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: Waldek Hebisch Newsgroups: comp.lang.c Subject: Re: Top 10 most common hard skills listed on resumes... Date: Mon, 9 Sep 2024 22:04:54 -0000 (UTC) Organization: To protect and to server Message-ID: References: Injection-Date: Mon, 9 Sep 2024 22:04:54 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="2663043"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Bytes: 6056 Lines: 88 David Brown wrote: > On 09/09/2024 18:46, Waldek Hebisch wrote: >> David Brown wrote: >>> On 09/09/2024 05:04, Waldek Hebisch wrote: >>>> Bart wrote: >>>>> On 09/09/2024 01:29, Waldek Hebisch wrote: >>>>>> Bart wrote: >>>>> >>>>>> No. It is essential for efficiency to have 32-bit types. On 32-bit >>>>>> machines doing otherwise would add useless instructions to object >>>>>> code. More precisly, really stupid compiler will generate useless >>>>>> intructions even with my declarations, really smart one will >>>>>> notice that variables fit in 32-bits and optimize accordingly. >>>>>> But at least some gcc versions needed such declarations. Note >>>>>> also that my version makes clear that there there is >>>>>> symmetry (everything should be added using 64-bit precision), >>>>>> you depend on promotion rules which creates visual asymetry >>>>>> are requires reasoning to realize that meaning is symetric. >>>>> >>>>> Your posted code used 64-bit aritmetic. The xext and c 32-bit variables >>>>> were used in loops where they need to be widened to 64 bits anyway. The >>>>> new value of c is set from a 32-bit result. >>>> >>>> Well, at C level there is 64-bit type. The intent is that C compiler >>>> should notice that the result is 32-bit + carry flag. Ideally >>>> compiler should notice that c has only one bit and can keep it >>>> in carry flag. On i386 comparison needed for loop control would >>>> destroy carry flag, so there must be code using value of carry in >>>> register and code to save carry to register. But one addition >>>> of highs parts can be skipped. On 32-bit ARM compiler can use >>>> special machine istructions and actually generated code which >>>> is close to optimal. >>> >>> When you have a type that you want to be at least 32 bits (to cover the >>> range you need), and want it to be as efficient as possible on 32-bit >>> and 64-bit machines (and 16-bit and 8-bit, still found in >>> microcontrollers), use "int_fast32_t". On x86-64 it will be 64-bit, on >>> 32-bit systems it will be 32-bit. Use of the [u]int_fastNN_t types can >>> make code significantly more efficient on 64-bit systems while retaining >>> efficiency on 32-bit (or even smaller) targets. >> >> Well, I have constraints, some of which are outside of C code. >> To resolve contraints I normally use some configure machinery. >> If a standard type is exact match for my constraints, then I would >> use standard type, possibly adding some fallbacks for pre-standard >> systems. But if my constranits differ, I see no advantage in >> using more "fancy" standard types compared to old types. >> > > The "fancy" standard types in this case specify /exactly/ what you > apparently want - a type that can deal with at least 32 bits for range, > and is as efficient as possible on different targets. What other > constraints do you have here that make "int_fast32_t" unsuitable? This routine is part of small library. Good approximation is that I want a type (posibly depending on target) which will make this library fast. As I wrote in another message I plan to use 64-bit units of work on 64-bit targets. I have not plans to use the library in 8-bit or 16-bit targets, but if I needed them on such targets I probably would use 16-bit work unit. So, while 32-bit work unit represents current state, it not correct statement of intentions. Consequently, 'int_fast32_t' would be as misleading or more misleading than 'int' ('int' is reasonable indication that choice of types is not finished, 'int_fast32_t' suggest that it is proper choice for all targets). >> Concerning '', somewhat worring thing is that several types >> there seem to be optional (or maybe where optional in older versions >> of the standard). I am not sure if this can be real problem, >> but too many times I saw that on various issues developers say >> "this in not mandatory, so we will skip it". >> > > has been required since C99. It has not been optional in any > C standard in the last 25 years. That's a /long/ time - long enough for > most people to be able to say "it's standard". > > And almost every C90 compiler also includes as an extension. > > If you manage to find a compiler that is old enough not to have > , and you need to use it for actual code, it's probably worth > spending the 3 minutes it takes to write a suitable yourself > for that target. ATM I do not have standard text handy to check, but AFAIR several _types_ in were not required but optional. -- Waldek Hebisch