| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 27 05:12PM -0500 "the sad state of debug performance in c++" by Vittorio Romeo https://vittorioromeo.info/index/blog/debug_performance_cpp.html "By now, it should (hopefully) be common knowledge that the term "zero cost abstraction" is a lie. To be fair, it's more of a misnomer – had the term been "abstraction likely to result in zero runtime overhead after optimizations" then it would have been much more honest, but I can see why that didn't fly…" "Most C++ developers tend to accept the fact that "zero cost abstractions" provide zero runtime overhead only with optimizations enabled, and that they have a negative impact on compilation speed. The same developers tend to believe that the benefits of such abstractions are so valuable that having your program perform poorly in debug mode (i.e. without optimizations enabled) and compile more slowly is worth it." "I used to be one of them." He is not wrong. Lynn |
| David Brown <david.brown@hesbynett.no>: Sep 27 06:07PM +0200 On 27/09/2022 16:17, Scott Lurndal wrote: > On intel/amd these generate lock prefixes, on other architectures > with atomic support (e.g. ARMv8 LDADD, et alia) those instructions > will be generated. For more demanding cases - sizes larger than the hardware supports directly, or read-write-modify on RISC - gcc uses a library that does much what Chris has shown here. The locks are simple busy-wait user-space spin locks on an atomic flag, which are very efficient on most systems (especially in the common case of no contention). Unfortunately, this solution is worse than useless in some cases, such as real-time systems and single-core systems. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 12:42PM -0700 On 9/27/2022 9:07 AM, David Brown wrote: > most systems (especially in the common case of no contention). > Unfortunately, this solution is worse than useless in some cases, such > as real-time systems and single-core systems. Yes. Using an address based hashed locking scheme works just in case the arch does not support the direct CPU instruction(s) (think CAS vs LL/SC) for an atomic RMW operation. However, the locking emulation is most definitely, not ideal. Not lock-free, indeed. When the arch supports it, the compiler should be using lock-free operations wrt: https://en.cppreference.com/w/cpp/atomic/atomic/is_lock_free Using a hashed locking scheme for the atomic fetch-add impl would return false wrt is_lock_free... Also, I forgot to add the rest of the fetch-add, wrt the god damn dangling comma. Notice the original pseudo code I posted upthread? ________________________ // A RMW operation int fetch_add_busted( int& origin, ) { int result = origin; origin = result + 1; return result; } ________________________ Here as well: ________________________ // A RMW operation int fetch_add( int& origin, ) { hash_lock(&origin); int result = origin; origin = result + 1; hash_unlock(&origin); return result; } ________________________ Humm... WTF? Let me correct them: ________________________ // A RMW operation int fetch_add_busted( int& origin, int addend ) { int result = origin; origin = result + addend; return result; } ________________________ Corrected here as well: ________________________ // A RMW operation int fetch_add( int& origin, int addend ) { hash_lock(&origin); int result = origin; origin = result + addend; hash_unlock(&origin); return result; } ________________________ Sorry about that non-sense David: Wrt the dangling comma. Forgot to introduce the addend for the fetch-add RMW operation. Shit happens. :^) |
| Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Sep 27 09:56AM -0600 > sooner or later you'll have almost everybody in your killfile > and see nothing. > I honestly cannot see the point. Typically only a few people ever respond to the people who have, by dint of extraordinary effort, managed to land in my killfile. Typically those few people who do respond to them aren't much loss either. The killfile propagation you are describing is not my experience. |
| David Brown <david.brown@hesbynett.no>: Sep 27 06:10PM +0200 On 27/09/2022 16:11, rbowman wrote: > programmers used it inappropriately so you wind up casting it away. I > think they saw it in one declaration and decided it was always needed. > Used correctly it's valuable Is it not better just to say that you are not fond of incorrect and badly written code? If you have code written by people who don't know how to use "const" properly, you should not let that stop you using it when it is useful. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 27 10:50AM -0700 > sooner or later you'll have almost everybody in your killfile > and see nothing. > I honestly cannot see the point. I'm going to assume that you actually want an explanation. That might be a bad assumption. My killfile is extremely useful. It filters out posts by a handful of users who would otherwise seriously damage the signal-to-noise ratio of my view of this newsgroup. It makes this newsgroup a much more pleasant place. Most other users here have enough sense to refrain from posting followups to noise. My killfile does not generally make threads disjointed, because typically none of the participants in a meaningful thread are in my killfile. You are one of the few users here who both posts relevent content *and* posts annoying responses to trolls. Most recently, you posted: > I thought you weren't reading any of my "nonsense". So why are you? > Just go away, asshole. because, apparently, you thought that *all* readers of this newsgroup needed to see you say that. We really really didn't. I'll note that the particular troll you were replying to posts under what appears to be a valid email address, so you could have contacted them directly. Honestly, I understand the urge to feed the trolls. I've done it myself. But I strongly suggest that you learn to let them have the last word -- or it will never end. Perhaps you now understand a bit better. Whether you do or not, my previous statement stands. Your positive contributions here do not outweigh the noise you produce with posts like your recent one. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Kaz Kylheku <864-117-4973@kylheku.com>: Sep 27 06:18PM ["Followup-To:" header set to comp.lang.c.] >> (and perhaps someone could tell me what it is?). > I understand that C++ wants member variables to be initialized in strict > order of declaration (which in the case of C++ in particular can make That's a pretty stupid thing to fuss about in a language in which the very *functions* have unspecified argument evaluation order. If you create an object using this kind of paradigm: obj *make_object(obj *arg1, obj *arg2, obj *arg3); make_object(complex_expr, another_complex_expr, third_complex_expr); the arguments expressions in your constructor call will be evaluated in many possible orders, including interleaved with each other. *THAT* is the fucking place where you want to introduce order: in an imperative, effect-full language, you want function arguments to be strictly evaluated. But no, we can't have that; let's obsess over order in the initializer syntax. C++ is a shizophrenic language designed by a disingenuous committee whose main aim is self-preservation and not the betterment of a programming language. |
| olcott <polcott2@gmail.com>: Sep 27 10:19AM -0500 On 9/27/2022 6:00 AM, Richard Damon wrote: >> H does correctly predict the actual behavior of 1 to ∞ simulated steps >> of P. > Nope, since we have shown that if H(P,P) returns 0, then P(P) will Halt. *That is false and you know it so you are a liar for the 500th time* *You know that you are not referring to the behavior of an input to H* Halt deciders only compute the mapping from their inputs to a accept or reject state on the basis of the actual behavior of this input. The correct simulation of 1 to ∞ steps of a machine description provides the actual behavior of of 1 to ∞ steps of the underlying machine. int Hx(ptr x, ptr y); void Px(ptr x) { int Halt_Status = Hx(x, x); if (Halt_Status) HERE: goto HERE; return; } There are zero Px elements of infinite set of Hx/Px pairs such that the correct simulation (of 1 to ∞ steps) or direct execution of Px by Hx reaches the final state of Px and halts. Some of the Hx elements correctly recognize a correct non-halting behavior pattern proving that its Px never halts. These Hx elements correctly abort their simulation and correctly return 0 for non-halting. *This Hx/Px pair is named H/P and is fully operational* Complete halt deciding system (Visual Studio Project) (a) x86utm operating system (b) complete x86 emulator adapted from libx86emu (c) Several halt deciders and their inputs contained within Halt7.c https://liarparadox.org/2022_09_07.zip The recursive simulation non-halting behavior pattern is slightly adapted from infinite recursion behavior pattern used to determine the halt status of void Infinite_Recursion(u32 N). Once the infinite recursion behavior pattern is understood to be correct then the recursive simulation behavior pattern is also understood to be correct. Both of these behavior patterns use the exact same non-halting criteria. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <polcott2@gmail.com>: Sep 27 10:49AM -0500 Halt deciders only compute the mapping from their inputs to an accept or reject state on the basis of the actual behavior of this input. The correct simulation of 1 to ∞ steps of a machine description provides the actual behavior of of 1 to ∞ steps of the underlying machine. int Hx(ptr x, ptr y); void Px(ptr x) { int Halt_Status = Hx(x, x); if (Halt_Status) HERE: goto HERE; return; } A simulating halt decider (SHD) continues to simulate its input until the behavior of this input matches a non-halting behavior pattern or the simulated input halts on its own. There are zero Px elements of infinite set of Hx/Px pairs such that the correct simulation (of 1 to ∞ steps) or direct execution of Px by Hx reaches the final state of Px and halts. Some of the Hx elements correctly recognize a correct non-halting behavior pattern proving that its Px never halts. These Hx elements correctly abort their simulation and correctly return 0 for non-halting. *This Hx/Px pair is named H/P and is fully operational* Complete halt deciding system (Visual Studio Project) (a) x86utm operating system (b) complete x86 emulator adapted from libx86emu (c) Several halt deciders and their inputs contained within Halt7.c https://liarparadox.org/2022_09_07.zip The recursive simulation non-halting behavior pattern is slightly adapted from infinite recursion behavior pattern used to determine the halt status of void Infinite_Recursion(u32 N). Once the infinite recursion behavior pattern is understood to be correct then the recursive simulation behavior pattern is also understood to be correct. Both of these behavior patterns use the exact same non-halting criteria. *Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment