| Ralf Goertz <me@myprovider.invalid>: Sep 23 04:21PM +0200 Am Fri, 23 Sep 2022 15:53:36 +0200 > > that (using n=12 instead of 10 as in the article). To my big > > surprise "-O6": > Anything higher than -O3 is the same as -O3 in gcc. Oh okay. I don't know where I got the idea that 6 was the maximum. > gcc -O3 uses a lot effort trying to get the last few fractions of a > percent out of the code - it is rarely used, as it is rarely worth the > effort. And sometimes it backfires. As it obviously does with my program. Then again it still surprises me. It's 17% slower! I guess the 99% consists of swapping elements in a std::array<int, 12>. At least the part I have written but also next_permutation() if I remember the algorithm in TAOCP correctly. > to more SIMD and advanced instructions, as well as a more accurate > model for scheduling, pipelining, and other processor-specific fine > tuning options. -march=native makes "-O2" a little bit slower and "-O3" a little bit faster but the former is still 11% faster. Thanks for your explanations. |
| Opus <ifonly@youknew.org>: Sep 23 06:32PM +0200 Le 21/09/2022 à 21:04, Lynn McGuire a écrit : > deprecated," he said on Twitter, expressing a personal opinion rather > than a fresh Microsoft policy." > Wow ! Bold. It's not bold. It's just stupid. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 23 12:35PM -0700 > in shortening "pointer" like that. > But not to be bested, Rust makes it better: 'Rc'. > Because why not. "Rc" stands for "Reference Counted Smart Pointer". It's not just a random 2-letter sequence. -- 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 */ |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 12:44PM -0700 On 9/23/2022 12:35 PM, Keith Thompson wrote: >> Because why not. > "Rc" stands for "Reference Counted Smart Pointer". It's not just a > random 2-letter sequence. Humm, Rc, I thought it might of been a "Reference Collected" attribute applied to an object's declaration. |
| red floyd <no.spam.here@its.invalid>: Sep 23 02:43PM -0700 On 9/23/2022 12:45 AM, Juha Nieminen wrote: > In general, the more condensed or the more sparse the code, the less > readable it is. The perfect middle should be the goal. Or, as Einstein once put it, "Things should be as simple as possible, but no simpler". |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 12:57PM -0700 I have conducted a lot of experiments in the past with garbage collected languages, and have come to a conclusion. Manual memory management techniques can be a good thing, even in a GC environment. Iirc, I wrote about it here before, many years ago. Being able to create objects all over the place willy-nilly, and never even have to think about destroying them... Is a "convenience" that a GC can help one out with... However, I found that using a simple object stack can help to take pressure off a GC. So instead of (pseudo-code)... "hey look at me, no free for GC is the everything": _____________________ for (;;) { foo = new foo(); // use foo } _____________________ ;^) Btw, don't worry, the GC will try to make sure the program above does not blow out memory... However, what about this very simple manual memory management technique, even in a pure GC setup: _____________________ for (;;) { foo = stack_try_pop(); if (! foo) { // Stack empty condition... foo = new foo(); } // use foo if (! stack_try_push(foo)) { // Stack full condition... // let the gc handle it } } _____________________ stack_try_push fails when its full. Since we are in GC, we just let the reference dangle. |
| scott@slp53.sl.home (Scott Lurndal): Sep 23 02:34PM >> They [memory barriers] /do/ work - they just do what they are supposed to do, not what you >> think they should do. >No, they have actually no effect. If that were the case, then there would be no need for memory barrier instructions, right? So why are they present in all architectures (x86, arm, mips, ppc, ia64?) Hint: because they actually _do_ have an effect, moreso in arm/mips/ppc than in x86, but they are actually required in x86 as well; I recall a linux kernel bug from a decade ago in the TCP stack related to skb management where a missing memory barrier caused all kinds of havoc even in the soi disant 'strongly-ordered' x86 memory model. |
| Muttley@dastardlyhq.com: Sep 23 02:47PM On Wed, 21 Sep 2022 18:27:30 +0200 >> You don't need to keep demonstrating that you've never done any programming >> outside of your ivory tower and certainly not in C, we already know. >If you do things like the above you're in the highest ivory tower ever. Uh huh, whatever you say genius. |
| Michael S <already5chosen@yahoo.com>: Sep 23 08:19AM -0700 On Friday, September 23, 2022 at 5:34:36 PM UTC+3, Scott Lurndal wrote: > So why are they present in all architectures (x86, arm, mips, ppc, ia64?) > Hint: because they actually _do_ have an effect, moreso in arm/mips/ppc > than in x86, Actually, less so on MIPS than on x86. On MIPS, I think, memory barriers needed only in code that mixes normal, ie. write-back cached, memory accesses (WB) with special I/O-type accesses like uncached (UC) and especially write-combined (WC). On x86 it's to the main reason for barriers, too, but there are subtle cases where MB is needed on pure WB areas as well. That's because x86 (and SPARC) default memory ordering is TCO rather than SC. However in practice on x86 WB areas people normally use implied barriers that are present in all RMW and CAS instructions with LOCK prefix. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 23 06:36PM +0200 Am 23.09.2022 um 16:34 schrieb Scott Lurndal: >> No, they have actually no effect. > If that were the case, then there would be no need for memory > barrier instructions, right? Read what I said in the context ! |
| Philipp Klaus Krause <pkk@spth.de>: Sep 23 07:50PM +0200 Am 22.09.22 um 08:03 schrieb Juha Nieminen: > is often not necessary, and would require traversing the string twice > in order to copy it. (Why traverse it twice? You can copy it while > traversing it for the first time!) How about using memccpy? It is in C23, don't know about C++. |
| Philipp Klaus Krause <pkk@spth.de>: Sep 23 07:52PM +0200 Am 21.09.22 um 15:24 schrieb David Brown: > There are no volatile versions > which could be used to ensure that something like an "memset" to wipe > memory would actually be run. Are you looking for C23 memset_explicit? |
| scott@slp53.sl.home (Scott Lurndal): Sep 23 05:57PM >On MIPS, I think, memory barriers needed only in code that mixes normal, >ie. write-back cached, memory accesses (WB) with special I/O-type accesses >like uncached (UC) and especially write-combined (WC). I was thinking specifically of kseg 0/1 aliases, which are uncached. >That's because x86 (and SPARC) default memory ordering is TCO rather than SC. >However in practice on x86 WB areas people normally use implied >barriers that are present in all RMW and CAS instructions with LOCK prefix. I missed Alpha in the list above, many of the alpha architects and engineers ended up at Cavium designing their version of MIPS processors. |
| 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