- What cache-archtectures ... - 2 Updates
- Don't be fooled by cpp.sh - 4 Updates
- Resounding and redounding - 1 Update
- Probably UB but I am finding it hard to give a fuck (C++ swizzle) - 1 Update
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 20 09:20PM On 18/12/2019 15:07, Bonita Montero wrote: > .... could make std::hardware_destructive_interference_size > and std::hardware_constructive_interference_size different? Multi-level caches perhaps? Andy |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 20 02:04PM -0800 On 12/20/2019 1:20 PM, Vir Campestris wrote: >> .... could make std::hardware_destructive_interference_size >> and std::hardware_constructive_interference_size different? > Multi-level caches perhaps? Yeah. Was thinking that std::hardware_destructive_interference_size can be L1, and std::hardware_constructive_interference_size different can be L2. However, this is completely up to the implementation. Iirc, back on early hyperthreading 128-byte would be split into two 64-byte halves. Iirc, two adjacent 64-bit cache lines can interfere. https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf They recommend to pad and align things on 128-byte boundaries. The two 64-byte halves can contend. Section 3.7.3, Hardware Prefetching for Second-Level Cache. |
| boltar@nowhere.co.uk: Dec 20 09:25AM On Thu, 19 Dec 2019 20:26:55 +0000 >>> "boltar" suggests. >> I never said it was an issue, I said it was pointless and inefficient. >"pointless" : subjective! If something adds nothing except complexity its pointless. >"inefficient: compared to what? Compared to not using it. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 20 04:35AM -0800 > If something adds nothing except complexity its pointless. > >"inefficient: compared to what? > Compared to not using it. But how you "do not use" it?: 1) data in your program can not have optional, missing, lazily loaded properties. That is uselessly naive to hope about most real world data. Even if all data is really acquirable it may be expensive and pointless to do it always. 2) properties whose value may be missing has to be dynamically allocated so you can use nullptr as indication of it being missing. Really? Every int that may be unknown has to be made dynamically allocated? 3) such objects have to have internal "missing" state that is then checked in all interface methods of those. Types outside of your control like fundamentals or standard library types you need to manually wrap by add that "missing" state. Whole whopping wrapper class around int to add missing state to it? 4) You have external bools or flags somewhere that indicate if something is missing? Annoyingly error prone and confusing. 5) You use certain "magical" values of your objects to encode that it is missing? So LONG_MIN means long is missing and INT_MIN that int is missing and so on? How to make difference between missing and known to be empty sd::vector? Again annoyingly error-prone approach. 6) You use some kind of mix of above "tricks"? That tends to clearly make it even worse, more confusing and likely less efficient. Your own code is like bear trap against yourself and your teammates. Any other ways? I doubt it. Lot cheaper and cleaner is to use missing state of types that already naturally have it (like pointers and floating points) and for anything else that may be unknown or missing to use std::optional. |
| boltar@nowhere.co.uk: Dec 20 04:28PM On Fri, 20 Dec 2019 04:35:37 -0800 (PST) >> >"inefficient: compared to what? >> Compared to not using it. >But how you "do not use" it?: How did you manage to write code before? Its just yet more noise. >missing and so on? How to make difference between missing >and known to be empty sd::vector? Again annoyingly error-prone >approach. Or you could throw an exception if there's an error and you don't want to return that as a special value or instance flag. Or pass in an error parameter. >That tends to clearly make it even worse, more confusing and >likely less efficient. Your own code is like bear trap against >yourself and your teammates. How did we manage before 2017. Its a mystery. >already naturally have it (like pointers and floating points) >and for anything else that may be unknown or missing to use >std::optional. Yeah, lets just create pointless object instances all over the place just to indicate valid returns. Very efficient. I think you'd like Java. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 20 10:36AM -0800 > >> Compared to not using it. > >But how you "do not use" it?: > How did you manage to write code before? Its just yet more noise. Lack of answer noted. :D Pathetic snip of shameful strategies that you likely use also noted. I answer later in post. > Or you could throw an exception if there's an error and you don't want to > return that as a special value or instance flag. > Or pass in an error parameter. The case of using optional is when lack of value is *not* *an* *error*. Exceptions just waste resources and how you store it instead of value? Can't be you read nothing of what you snipped in humiliation. > >likely less efficient. Your own code is like bear trap against > >yourself and your teammates. > How did we manage before 2017. Its a mystery. Huh? Second time same question? :D Fishing for ideas since you snipped all the obviously embarrassing and inferior to optional strategies that you use? :D But masters are here for to teach. And I haven't hidden it. Lot of the code-bases are still in usage. Tagged unions or variants from various libraries until when I read about Barton-Nackman's fallible<T> and about 2005 I started to use mostly Boost.Optionals/Variants since these were well made and behaved nicely in tests. In fact I have migrated to std::variant/optional only in few code-bases. Why to bother when things already work? > >std::optional. > Yeah, lets just create pointless object instances all over the place just > to indicate valid returns. Very efficient. I think you'd like Java. These beat all the embarrassing strategies that you snipped in performance ... and you did fail to tell what is your alternative "superior" method ... so sorry ... foaming mouth is not argument. :D |
| woodbrian77@gmail.com: Dec 20 08:27AM -0800 Shalom Happy holidays .... Hanukkah ... Dec. 22 through Dec. 29 .... and Merry Christmas. Brian Ebenezer Enterprises - "America isn't great because America is powerful. America is powerful because America is great." Ben Shapiro at dailywire.com https://github.com/Ebenezer-group/onward |
| woodbrian77@gmail.com: Dec 20 08:22AM -0800 Please don't swear here. Brian Ebenezer Enterprises - Enjoying programming again. https://github.com/Ebenezer-group/onward |
| 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