Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #87510 > unrolled thread

An argument *against* (the liberal use of) references

Back to article view | Back to comp.lang.c++

Contents

  An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-11-22 09:52 +0000
    Re: An argument *against* (the liberal use of) references "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-11-22 11:23 +0100
    Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-22 13:27 +0200
      Re: An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-11-23 06:52 +0000
        Re: An argument *against* (the liberal use of) references "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-11-23 13:51 +0100
          Re: An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-11-23 13:46 +0000
            Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-30 13:59 +0200
              Re: An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-12-01 06:45 +0000
                Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-01 09:19 +0200
                  Re: An argument *against* (the liberal use of) references Stuart Redmann <DerTopper@web.de> - 2022-12-01 14:06 +0100
                    Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-01 16:45 +0200
                      Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-01 16:02 +0000
                        Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-01 20:21 +0200
                          Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-01 19:09 +0000
                            Re: An argument *against* (the liberal use of) references Michael S <already5chosen@yahoo.com> - 2022-12-02 05:53 -0800
                              Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-02 14:36 +0000
                                Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 12:29 -0800
                                  Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-02 20:55 +0000
                                    Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 12:58 -0800
                                      Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-02 21:18 +0000
                                        Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 14:16 -0800
                                    Re: An argument *against* (the liberal use of) references Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2022-12-02 21:09 +0000
                                      Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 13:22 -0800
                                        Re: An argument *against* (the liberal use of) references Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2022-12-02 21:36 +0000
                                          Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 14:13 -0800
                              Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-02 18:33 +0200
                          Re: An argument *against* (the liberal use of) references Michael S <already5chosen@yahoo.com> - 2022-12-01 11:59 -0800
                            Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-01 23:53 +0200
                              Re: An argument *against* (the liberal use of) references Michael S <already5chosen@yahoo.com> - 2022-12-02 04:11 -0800
                    Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-01 12:21 -0800
                  Re: An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-12-06 11:36 +0000
                    Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-06 12:26 -0800
                      Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-06 20:39 +0000
                        Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-06 23:53 +0200
                          Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-06 13:59 -0800
                            Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-06 22:04 +0000
                              Re: An argument *against* (the liberal use of) references Öö Tiib <ootiib@hot.ee> - 2022-12-06 21:38 -0800
                                Re: An argument *against* (the liberal use of) references scott@slp53.sl.home (Scott Lurndal) - 2022-12-07 15:22 +0000
                                  Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-07 18:37 +0200
                          Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-06 14:01 -0800
                      Re: An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-12-07 09:05 +0000
                        Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-07 12:48 -0800
                          Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-07 12:50 -0800
                          Re: An argument *against* (the liberal use of) references Juha Nieminen <nospam@thanks.invalid> - 2022-12-08 07:52 +0000
                            Re: An argument *against* (the liberal use of) references Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-08 05:50 -0800
                              Re: An argument *against* (the liberal use of) references Michael S <already5chosen@yahoo.com> - 2022-12-08 13:30 -0800
                                Re: An argument *against* (the liberal use of) references Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-09 12:50 -0800
                                  Re: An argument *against* (the liberal use of) references David Brown <david.brown@hesbynett.no> - 2022-12-11 12:18 +0100
                          Re: An argument *against* (the liberal use of) references Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-08 13:38 +0200
                            Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-08 16:45 -0800
                    Re: An argument *against* (the liberal use of) references Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-12-09 04:35 -0800
    Re: An argument *against* (the liberal use of) references Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-22 15:36 +0100
    Re: An argument *against* (the liberal use of) references Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-11-22 15:21 +0000
    Re: An argument *against* (the liberal use of) references Richard Damon <Richard@Damon-Family.org> - 2022-11-22 10:48 -0500
      Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-22 13:18 -0800
    Re: An argument *against* (the liberal use of) references El Jo <giorgio.zoppi@gmail.com> - 2022-11-22 13:41 -0800
      Re: An argument *against* (the liberal use of) references "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-22 13:51 -0800
    Re: An argument *against* (the liberal use of) references Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-23 20:08 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#87718

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 12/6/2022 3:36 AM, Juha Nieminen wrote:
>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> When tracking down this bug, I monitored all refcounter changes for a
>>> particular single smartpointer during the program run (ca 10 min). There
>>> were 591848 increments and decrements, from which 1526 came from the
>>> problematic (parallelized) part. It looks like a pessimization to slow
>>> down 99.75% of accesses when only 0.25% would actually benefit from this.
> [...]
>> So unless your smart pointer is being copied and assigned around
>> millions of times per second in tight number-crunching loops, you can
>> safely ignore any lost clock cycles by making the reference counter
>> thread-safe.
> [...]
> A thread-safe reference counted pointer can heavily damage performance 
> in certain usage scenarios. Blasting the system with memory barriers and 
> atomic RMW ops all over the place.

If you really need to copy/assign smart pointers in tight number-crunching
inner loops, then perhaps *don't* copy/assign such smart pointers in such
loops (or use any smart pointers for that matter)?

In scenarios that don't require the last clock cycles squeezed out of
them, does a "memory barrier" or other optimization hindrances really
matter all that much? If code that takes 0.01% of the total runtime
gets 1% slower... how much will it slow down the overall program?
Do the math.

[toc] | [prev] | [next] | [standalone]

#87729

On 12/7/2022 1:05 AM, Juha Nieminen wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 12/6/2022 3:36 AM, Juha Nieminen wrote:
>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>> When tracking down this bug, I monitored all refcounter changes for a
>>>> particular single smartpointer during the program run (ca 10 min). There
>>>> were 591848 increments and decrements, from which 1526 came from the
>>>> problematic (parallelized) part. It looks like a pessimization to slow
>>>> down 99.75% of accesses when only 0.25% would actually benefit from this.
>> [...]
>>> So unless your smart pointer is being copied and assigned around
>>> millions of times per second in tight number-crunching loops, you can
>>> safely ignore any lost clock cycles by making the reference counter
>>> thread-safe.
>> [...]
>> A thread-safe reference counted pointer can heavily damage performance
>> in certain usage scenarios. Blasting the system with memory barriers and
>> atomic RMW ops all over the place.
> 
> If you really need to copy/assign smart pointers in tight number-crunching
> inner loops, then perhaps *don't* copy/assign such smart pointers in such
> loops (or use any smart pointers for that matter)?

It really rears its ugly head when iterating large linked lists of 
nodes... Read mostly, write rather rarely.


> In scenarios that don't require the last clock cycles squeezed out of
> them, does a "memory barrier" or other optimization hindrances really
> matter all that much? 

Big time. Have you ever studied up on RCU? That is one of the reasons it 
was created in the first place: to get rid of memory barriers on the 
read side of the algorithm.


> If code that takes 0.01% of the total runtime
> gets 1% slower... how much will it slow down the overall program?
> Do the math.

RCU beats them all, it is memory barrier free, well except for systems 
that _need_ a membar for data-dependent loads, ala dec alpha. Iirc, 
SPARC in RMO mode does not even need membars for such loads. Proxy 
collection does pretty damn good, but not as good as RCU...

The membars take a big toll, especially the god damn #StoreLoad barrier 
in SMR (aka, hazard pointers).

[toc] | [prev] | [next] | [standalone]

#87730

On 12/7/2022 12:48 PM, Chris M. Thomasson wrote:
> On 12/7/2022 1:05 AM, Juha Nieminen wrote:
>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 12/6/2022 3:36 AM, Juha Nieminen wrote:
>>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>>> When tracking down this bug, I monitored all refcounter changes for a
>>>>> particular single smartpointer during the program run (ca 10 min). 
>>>>> There
>>>>> were 591848 increments and decrements, from which 1526 came from the
>>>>> problematic (parallelized) part. It looks like a pessimization to slow
>>>>> down 99.75% of accesses when only 0.25% would actually benefit from 
>>>>> this.
>>> [...]
>>>> So unless your smart pointer is being copied and assigned around
>>>> millions of times per second in tight number-crunching loops, you can
>>>> safely ignore any lost clock cycles by making the reference counter
>>>> thread-safe.
>>> [...]
>>> A thread-safe reference counted pointer can heavily damage performance
>>> in certain usage scenarios. Blasting the system with memory barriers and
>>> atomic RMW ops all over the place.
>>
>> If you really need to copy/assign smart pointers in tight 
>> number-crunching
>> inner loops, then perhaps *don't* copy/assign such smart pointers in such
>> loops (or use any smart pointers for that matter)?
> 
> It really rears its ugly head when iterating large linked lists of 
> nodes... Read mostly, write rather rarely.
> 
> 
>> In scenarios that don't require the last clock cycles squeezed out of
>> them, does a "memory barrier" or other optimization hindrances really
>> matter all that much? 
> 
> Big time. Have you ever studied up on RCU? That is one of the reasons it 
> was created in the first place: to get rid of memory barriers on the 
> read side of the algorithm.
> 
> 
>> If code that takes 0.01% of the total runtime
>> gets 1% slower... how much will it slow down the overall program?
>> Do the math.
> 
> RCU beats them all, it is memory barrier free, well except for systems 
> that _need_ a membar for data-dependent loads, ala dec alpha. Iirc, 
> SPARC in RMO mode does not even need membars for such loads. Proxy 
> collection does pretty damn good, but not as good as RCU...
> 
> The membars take a big toll, especially the god damn #StoreLoad barrier 
> in SMR (aka, hazard pointers).

Fwiw, here is a paper on SMR (Safe Memory Reclamation):

https://www.liblfds.org/downloads/white%20papers/%5BSMR%5D%20-%20%5BMichael%5D%20-%20Hazard%20Pointers;%20Safe%20Memory%20Reclaimation%20for%20Lock-Free%20Objects.pdf

Joe Seigh cleverly combined SMR with RCU to get rid of the NASTY 
#StoreLoad membar in SMR.

[toc] | [prev] | [next] | [standalone]

#87747

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> If you really need to copy/assign smart pointers in tight number-crunching
>> inner loops, then perhaps *don't* copy/assign such smart pointers in such
>> loops (or use any smart pointers for that matter)?
> 
> It really rears its ugly head when iterating large linked lists of 
> nodes... Read mostly, write rather rarely.

I don't see how iterating a linked list requires copying or assigning
smart pointers. Unless you are using the smart pointers as the next/prev
pointers of each node themselves. In which case you run into a recursive
reference counting situation, which I don't see how that's very feasible.

>> In scenarios that don't require the last clock cycles squeezed out of
>> them, does a "memory barrier" or other optimization hindrances really
>> matter all that much? 
> 
> Big time. Have you ever studied up on RCU? That is one of the reasons it 
> was created in the first place: to get rid of memory barriers on the 
> read side of the algorithm.

In scenarios that don't require the last clock cycles squeezed out of
them it's extremely important to squeeze the last clock cycles out?

I don't often like to quote the way-too-often-wrongly-quoted and
way-too-often-completely-misunderstood "early optimization is the
root of all evil", but in this case that it applies.

(In its original context, when Donald Knuth wrote that, he was saying
that your optimization efforts should be concentrated on the 3% of the
code where it actually matters. Something that most people don't know
about the quote. But it does apply here perfectly.)

[toc] | [prev] | [next] | [standalone]

#87755

Juha Nieminen <nospam@thanks.invalid> writes:

[...]

> I don't often like to quote the way-too-often-wrongly-quoted and
> way-too-often-completely-misunderstood "early optimization is the
> root of all evil", [...]

Amusing that this comment wrongly quotes the original.

[toc] | [prev] | [next] | [standalone]

#87765

On Thursday, December 8, 2022 at 3:50:43 PM UTC+2, Tim Rentsch wrote:
> Juha Nieminen <nos...@thanks.invalid> writes: 
> 
> [...]
> > I don't often like to quote the way-too-often-wrongly-quoted and 
> > way-too-often-completely-misunderstood "early optimization is the
> > root of all evil", [...] 
> 
> Amusing that this comment wrongly quotes the original.

premature - ennenaikaista, ennenaikainen
early - aikaisin, aikainen
All words appear to have the same root 'aika'==time.
If I am going to believe google translate then 'ennenaikaista' means
literally 'before early time'. So, may be, for person that thinks
in Finnish it is natural to translate it back to English like 'early'.

It is not just Finnish.
It two languages that I speak most, common translation of 
'premature' is 'before time' and 'too early'.
Neither of the languages derives it from 'mature'.
Now, 'immature' is completely different story. This word is
translated rather close to original. But Knuth said 'premature'
rather than 'immature' and that provokes difficulties in translation.

[toc] | [prev] | [next] | [standalone]

#87786

Michael S <already5chosen@yahoo.com> writes:

> On Thursday, December 8, 2022 at 3:50:43 PM UTC+2, Tim Rentsch wrote:
>
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>> [...]
>>
>>> I don't often like to quote the way-too-often-wrongly-quoted and
>>> way-too-often-completely-misunderstood "early optimization is the
>>> root of all evil", [...]
>>
>> Amusing that this comment wrongly quotes the original.
>
> premature - ennenaikaista, ennenaikainen
> early - aikaisin, aikainen
> All words appear to have the same root 'aika'==time.
> If I am going to believe google translate then 'ennenaikaista' means
> literally 'before early time'.  So, may be, for person that thinks
> in Finnish it is natural to translate it back to English like 'early'.
>
> It is not just Finnish.
> It two languages that I speak most, common translation of
> 'premature' is 'before time' and 'too early'.
> Neither of the languages derives it from 'mature'.
> Now, 'immature' is completely different story.  This word is
> translated rather close to original.  But Knuth said 'premature'
> rather than 'immature' and that provokes difficulties in translation.

In English there is a significant difference between "early" and
"premature".  (It hadn't occurred to me that premature might be
derived from mature.)

The original source was written in English.  It was written
by Don Knuth, whose native language is English.  The posting
here was written in English.  Furthermore the comment here
is written as a quotation, and mentions that the saying is
wrongly quoted.  Once we are in the realm of quoting rather
than paraphrasing there is no room for latitude.

I am sympathetic to those whose native language is other than
English and post in English.  More than sympathetic, I admire
them for their language skills, an area where I am woefully much
less than fully competent.  Even so, it behooves any non-native
speaker to make an effort to use English correctly, and to want
to use English correctly, when writing in English.  And that
especially applies when citing or quoting from a source written
in English.

[toc] | [prev] | [next] | [standalone]

#87808

On 09/12/2022 21:50, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
> 
>> On Thursday, December 8, 2022 at 3:50:43 PM UTC+2, Tim Rentsch wrote:
>>
>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>
>>> [...]
>>>
>>>> I don't often like to quote the way-too-often-wrongly-quoted and
>>>> way-too-often-completely-misunderstood "early optimization is the
>>>> root of all evil", [...]
>>>
>>> Amusing that this comment wrongly quotes the original.
>>
>> premature - ennenaikaista, ennenaikainen
>> early - aikaisin, aikainen
>> All words appear to have the same root 'aika'==time.
>> If I am going to believe google translate then 'ennenaikaista' means
>> literally 'before early time'.  So, may be, for person that thinks
>> in Finnish it is natural to translate it back to English like 'early'.
>>
>> It is not just Finnish.
>> It two languages that I speak most, common translation of
>> 'premature' is 'before time' and 'too early'.
>> Neither of the languages derives it from 'mature'.
>> Now, 'immature' is completely different story.  This word is
>> translated rather close to original.  But Knuth said 'premature'
>> rather than 'immature' and that provokes difficulties in translation.
> 
> In English there is a significant difference between "early" and
> "premature".  (It hadn't occurred to me that premature might be
> derived from mature.)
> 

The etymology of "mature" is from a Latin word for "ripe" (such as "ripe 
fruit").  So it has implications of stages of ageing, unlike "early". 
"Premature" is therefore "before the fruit is ready to eat", and thus 
very different from merely being "early".  It's often a good idea to do 
things "early" - it is rarely a good idea to do them "prematurely".

If a language does not have a word corresponding directly to "premature" 
(or if the word carries too strong connotations of "premature baby"), 
then the equivalent of "too early" is going to be a far better 
alternative than merely "early" in Knuth's quotation.

[toc] | [prev] | [next] | [standalone]

#87751

07.12.2022 22:48 Chris M. Thomasson kirjutas:
> On 12/7/2022 1:05 AM, Juha Nieminen wrote:
> 
> 
>> If code that takes 0.01% of the total runtime
>> gets 1% slower... how much will it slow down the overall program?
>> Do the math.

My aim is to allow the program to scale safely to many-core machines. 
Even if some synchronization overhead is small today when running on 10 
cores in parallel, it does not mean it will remain small when run on a 
100-core or 1000-core machine, in some not so distant future.

> RCU beats them all, it is memory barrier free, well except for systems 
> that _need_ a membar for data-dependent loads, ala dec alpha. Iirc, 
> SPARC in RMO mode does not even need membars for such loads. Proxy 
> collection does pretty damn good, but not as good as RCU...
> 
> The membars take a big toll, especially the god damn #StoreLoad barrier 
> in SMR (aka, hazard pointers).

My current approach is to use single-threaded data structures as much as 
possible, so that the running threads would not disturb each other at 
all. But this creates other challenges like a need for deep copies, and 
a need to recalculate same things in different threads, on those copies.

It looks like if I want to use another approach with keeping more data 
in shared use I will indeed need to learn more about atomics and RCU.

[toc] | [prev] | [next] | [standalone]

#87768

On 12/8/2022 3:38 AM, Paavo Helde wrote:
> 07.12.2022 22:48 Chris M. Thomasson kirjutas:
>> On 12/7/2022 1:05 AM, Juha Nieminen wrote:
>>
>>
>>> If code that takes 0.01% of the total runtime
>>> gets 1% slower... how much will it slow down the overall program?
>>> Do the math.
> 
> My aim is to allow the program to scale safely to many-core machines. 
> Even if some synchronization overhead is small today when running on 10 
> cores in parallel, it does not mean it will remain small when run on a 
> 100-core or 1000-core machine, in some not so distant future.
> 
>> RCU beats them all, it is memory barrier free, well except for systems 
>> that _need_ a membar for data-dependent loads, ala dec alpha. Iirc, 
>> SPARC in RMO mode does not even need membars for such loads. Proxy 
>> collection does pretty damn good, but not as good as RCU...
>>
>> The membars take a big toll, especially the god damn #StoreLoad 
>> barrier in SMR (aka, hazard pointers).
> 
> My current approach is to use single-threaded data structures as much as 
> possible, so that the running threads would not disturb each other at 
> all. But this creates other challenges like a need for deep copies, and 
> a need to recalculate same things in different threads, on those copies.
> 
> It looks like if I want to use another approach with keeping more data 
> in shared use I will indeed need to learn more about atomics and RCU.
> 
> 

Exactly. Keep things separated out as much as possible, indeed. If you 
absolutely _must_ use shared data, think again... After thinking hard, 
if you still need to use shared data, then so be it. Damn. Now, there 
are many different way to use shared data, and some are a heck of a lot 
better than others. They all have their trade offs. RCU is geared toward 
"read-mostly" usage patterns. So, a database that experiences a shi%load 
of reads, and not so many writes per say, second, well, RCU just might 
be of use. Also, a proxy collector might work out for you. Basically, 
separate out reads and writes in your logic. If its read heavy, well, 
RCU might be able to help you out.

[toc] | [prev] | [next] | [standalone]

#87773

On Tuesday, 6 December 2022 at 11:36:42 UTC, Juha Nieminen wrote:
> Paavo Helde <ees...@osa.pri.ee> wrote: 
> > When tracking down this bug, I monitored all refcounter changes for a 
> > particular single smartpointer during the program run (ca 10 min). There 
> > were 591848 increments and decrements, from which 1526 came from the 
> > problematic (parallelized) part. It looks like a pessimization to slow 
> > down 99.75% of accesses when only 0.25% would actually benefit from this.
> There's place for micro-optimization and there's place to do the 
> Right Thing (TM) instead. 
> 
> In the vast, vast majority of situations micro-optimization will have 
> little to no effect on the program. It's only when you have number 
> crunching code that does something billions of times per second that 
> micro-optimization may start having some discernible effect. Those 
> situations tend to be very rare and far-in-between. And when you do 
> have such situations you can make faster versions of things for that 
> alone. 
>
However often you are writing low-level, general purpose routines. 

For instance I have a routine which calcuates the arc length of a Bezier.
There's no closed form for doing this,  so it is simple but intensive. It takes
a large number of points onthe curve and approximates by straight lines.

Now a lot of the time, the curves are entered by the user. It will take him three
or four seconds to draw a curve. So any optimisation is pointless.
However the routine could be called in the inner loop of some very intensive
higher level function, on a large number of candidate curves. So the function does
in fact have to be micro-optimised.

[toc] | [prev] | [next] | [standalone]

#87513

You've got problems that practical developers don't have.

[toc] | [prev] | [next] | [standalone]

#87514

On Tue, 22 Nov 2022 09:52:33 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
[snip]
> However, not many of them consider the *thread-safety* problem that taking
> a parameter by reference introduces. In single-threaded programs this is
> rather irrelevant, but multithreaded programming is becoming more and more
> common every day. Also, if you are writing a library to be used in programs
> out there, you have to consider its thread-safety even if the library itself
> doesn't use threads.
> 
> What is this thread-safety problem introduced by references (especially
> when we are writing a function that takes a parameter by reference)? The
> fact that in theory another thread could modify the object being referred
> to, at the same time that this function is trying to read it.
> 
> And there's nothing this function can do to defend against that. (Unless
> this function cooperates with the calling code to make it thread-safe, eg.
> by using a mutex offered by the calling code.) Even if the function is
> internally thread-safe, it can't help the fact that it's using an external
> resource without mutual exclusion (unless provided by the calling code).
> 
> How many times have you thought about the fact that taking a parameter
> by reference makes the function automatically not-thread-safe? I know
> I haven't. Like ever.

Ah, the frailty of human memory!  I drew it to your attention
some time ago.  Anyway, I agree with your conclusions above.

********************************************************************
Date: Sat, 25 Aug 2018 01:38:29 +0100
From: Chris Vine <chris@cvine--nospam--.freeserve.co.uk>
Newsgroups: comp.lang.c++
Subject: Re: Should you use constexpr by default?

On Thu, 23 Aug 2018 05:48:38 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
> Even beyond that, in the era of C++11 and newer, the constness of
> a member function should indicate that it's thread-safe to call it
> without a locking mechanism.

It absolutely doesn't mean that.  Locking of object (instance) data is
required in a const member function if it accesses those data at a time
when a non-const member function might concurrently mutate the data in
another thread.

You may have got this idea from a talk given by Herb Sutter in which he
asserted that "const means thread safe".  It doesn't.

A const member function can also mutate static data.
********************************************************************

[toc] | [prev] | [next] | [standalone]

#87515

On 11/22/22 4:52 AM, Juha Nieminen wrote:
> Recently I made a post about references, about how I think many C++
> programmers think of them in the wrong way (ie. they think of them
> as being effectively an alternative syntax for pointers, a "more
> limited pointer syntax", or "a safer pointer syntax", when in fact
> references shouldn't be semantically thought of as pointers at all,
> but as aliases for the objects they are referring to). In that thread
> some criticism was presented about the use of references, and arguments
> for their use.
> 
> For the sake of fairness and balance, here's an argument *against*
> (the liberal use of) references.
> 
> Most C++ programmers have been conditioned to always take larger objects
> (and even not so large objects) by const reference parameters in functions,
> because that's more efficient. (The heavier an object is to deep-copy,
> the more efficient a reference to it becomes, obviously.)
> 
> However, not many of them consider the *thread-safety* problem that taking
> a parameter by reference introduces. In single-threaded programs this is
> rather irrelevant, but multithreaded programming is becoming more and more
> common every day. Also, if you are writing a library to be used in programs
> out there, you have to consider its thread-safety even if the library itself
> doesn't use threads.
> 
> What is this thread-safety problem introduced by references (especially
> when we are writing a function that takes a parameter by reference)? The
> fact that in theory another thread could modify the object being referred
> to, at the same time that this function is trying to read it.
> 
> And there's nothing this function can do to defend against that. (Unless
> this function cooperates with the calling code to make it thread-safe, eg.
> by using a mutex offered by the calling code.) Even if the function is
> internally thread-safe, it can't help the fact that it's using an external
> resource without mutual exclusion (unless provided by the calling code).
> 
> How many times have you thought about the fact that taking a parameter
> by reference makes the function automatically not-thread-safe? I know
> I haven't. Like ever.
> 
> And, as has been pointed out, in the calling code itself it's not obvious
> that a function is taking a parameter by reference, and thus might need
> mutual exclusion.

Taking a parameter by referance makes you no less thread safe than 
taking a pointer as an parameter. In either case, the caller needs to 
make sure it has proper "ownership" of the object it is passing a 
reference or pointer to.

Yes, taking a parameter by (const) reference vs taking it by value 
increases the exposure to thread safety issues.

I will agree that the presence of refernce arguments perhaps makes it 
easier to miss some "sharing" that is happening, but ultimately, the C 
and C++ philosophy is the programmer needs to know what he is doing. 
They are NOT languages that coddle the programmer with extreme safety.

[toc] | [prev] | [next] | [standalone]

#87518

On 11/22/2022 7:48 AM, Richard Damon wrote:
> On 11/22/22 4:52 AM, Juha Nieminen wrote:
>> Recently I made a post about references, about how I think many C++
>> programmers think of them in the wrong way (ie. they think of them
>> as being effectively an alternative syntax for pointers, a "more
>> limited pointer syntax", or "a safer pointer syntax", when in fact
>> references shouldn't be semantically thought of as pointers at all,
>> but as aliases for the objects they are referring to). In that thread
>> some criticism was presented about the use of references, and arguments
>> for their use.
>>
>> For the sake of fairness and balance, here's an argument *against*
>> (the liberal use of) references.
>>
>> Most C++ programmers have been conditioned to always take larger objects
>> (and even not so large objects) by const reference parameters in 
>> functions,
>> because that's more efficient. (The heavier an object is to deep-copy,
>> the more efficient a reference to it becomes, obviously.)
>>
>> However, not many of them consider the *thread-safety* problem that 
>> taking
>> a parameter by reference introduces. In single-threaded programs this is
>> rather irrelevant, but multithreaded programming is becoming more and 
>> more
>> common every day. Also, if you are writing a library to be used in 
>> programs
>> out there, you have to consider its thread-safety even if the library 
>> itself
>> doesn't use threads.
>>
>> What is this thread-safety problem introduced by references (especially
>> when we are writing a function that takes a parameter by reference)? The
>> fact that in theory another thread could modify the object being referred
>> to, at the same time that this function is trying to read it.
>>
>> And there's nothing this function can do to defend against that. (Unless
>> this function cooperates with the calling code to make it thread-safe, 
>> eg.
>> by using a mutex offered by the calling code.) Even if the function is
>> internally thread-safe, it can't help the fact that it's using an 
>> external
>> resource without mutual exclusion (unless provided by the calling code).
>>
>> How many times have you thought about the fact that taking a parameter
>> by reference makes the function automatically not-thread-safe? I know
>> I haven't. Like ever.
>>
>> And, as has been pointed out, in the calling code itself it's not obvious
>> that a function is taking a parameter by reference, and thus might need
>> mutual exclusion.
> 
> Taking a parameter by referance makes you no less thread safe than 
> taking a pointer as an parameter. [...]

Agreed. Passing in a pointer vs a reference has no bearing on thread 
safety. Think of, <pseudo-code>:

int
fetch_add(
   int* const src,
   int addend
){
    return atomic_fetch_add(src, addend);
}


int
fetch_add(
   int& src,
   int addend
){
    return atomic_fetch_add(&src, addend);
}

where this low level atomic_fetch_add function takes a pointer to an int 
in src and an int as addend for its parameters. The way we pass in the 
fetch_add::src parameter is irrelevant wrt reference vs. pointer wrt 
thread safety. The atomic_fetch_add function takes care to make sure the 
fetch_add RMW operation is atomic. Nothing to do with references vs 
pointers...

[toc] | [prev] | [next] | [standalone]

#87519

Il giorno martedì 22 novembre 2022 alle 09:52:49 UTC Juha Nieminen ha scritto:
> Recently I made a post about references, about how I think many C++ 
> programmers think of them in the wrong way (ie. they think of them 
> as being effectively an alternative syntax for pointers, a "more 
> limited pointer syntax", or "a safer pointer syntax", when in fact 
> references shouldn't be semantically thought of as pointers at all, 
> but as aliases for the objects they are referring to). In that thread 
> some criticism was presented about the use of references, and arguments 
> for their use. 
> 
> For the sake of fairness and balance, here's an argument *against* 
> (the liberal use of) references. 

Looks like  a big post, but:
1. thread safety can only enforced by mutual-exclusion so I'd expect that before the function call, a mutex.
2. In 2021 we don't pass anymore by value big objects or by references, every we can we should transfer the ownership, 
if this is not the case we should pass the pointer to the object. We pass by references just small objects that we don't own.
Just 1c.
BR,

[toc] | [prev] | [next] | [standalone]

#87520

On 11/22/2022 1:41 PM, El Jo wrote:
> Il giorno martedì 22 novembre 2022 alle 09:52:49 UTC Juha Nieminen ha scritto:
>> Recently I made a post about references, about how I think many C++
>> programmers think of them in the wrong way (ie. they think of them
>> as being effectively an alternative syntax for pointers, a "more
>> limited pointer syntax", or "a safer pointer syntax", when in fact
>> references shouldn't be semantically thought of as pointers at all,
>> but as aliases for the objects they are referring to). In that thread
>> some criticism was presented about the use of references, and arguments
>> for their use.
>>
>> For the sake of fairness and balance, here's an argument *against*
>> (the liberal use of) references.
> 
> Looks like  a big post, but:
> 1. thread safety can only enforced by mutual-exclusion so I'd expect that before the function call, a mutex.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why do you say that? C++ has fairly decent atomic capabilities, that try 
to avoid a mutex if the underlying architecture supports lock-free 
atomic RMW's and loads/stores.



> 2. In 2021 we don't pass anymore by value big objects or by references, every we can we should transfer the ownership,
> if this is not the case we should pass the pointer to the object. We pass by references just small objects that we don't own.
> Just 1c.
> BR,

[toc] | [prev] | [next] | [standalone]

#87529

If you don't need an iterated or indexed access with a pointer
you'd better use a reference since you can't have any accidental
modifications on the reference. And references have the advantage
that you can pass temporaries to them. With operator overloading
you can't use pointers instead.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web