Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118533 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2024-03-23 17:53 +0100 |
| Last post | 2024-03-26 13:13 -0700 |
| Articles | 20 on this page of 21 — 4 participants |
Back to article view | Back to comp.lang.c++
Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-23 17:53 +0100
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-23 13:52 -0700
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-23 13:58 -0700
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-24 07:38 +0100
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-25 19:48 -0700
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-26 11:12 +0100
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-26 13:02 -0700
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-26 21:23 +0100
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-26 13:30 -0700
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-26 13:31 -0700
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-27 10:18 +0100
Re: Idea for spin-wait loops Michael S <already5chosen@yahoo.com> - 2024-03-27 17:09 +0200
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-27 12:58 -0700
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-24 07:37 +0100
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-24 12:33 -0700
Re: Idea for spin-wait loops scott@slp53.sl.home (Scott Lurndal) - 2024-03-24 20:43 +0000
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-25 07:23 +0100
Re: Idea for spin-wait loops Michael S <already5chosen@yahoo.com> - 2024-03-25 14:34 +0200
Re: Idea for spin-wait loops Michael S <already5chosen@yahoo.com> - 2024-03-25 19:11 +0200
Re: Idea for spin-wait loops Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-25 18:53 +0100
Re: Idea for spin-wait loops "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-26 13:13 -0700
Page 1 of 2 [1] 2 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-23 17:53 +0100 |
| Subject | Idea for spin-wait loops |
| Message-ID | <utn1eh$3oeks$1@raubtier-asyl.eternal-september.org> |
I've got a nice idea for a new processor-extrension for spin-wait -loops. The idea is that a thread of a processors enters a sleep state if a word in memory is equal to a certain register until the cacheline containing the word is modified or there's a timeout according to the timestamp-counter's value. This would eliminate active spinning and polling a value in memory. Polling would occur only if the cacheline would be modified by another thread.
[toc] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-23 13:52 -0700 |
| Message-ID | <utnff2$3rn1f$1@dont-email.me> |
| In reply to | #118533 |
On 3/23/2024 9:53 AM, Bonita Montero wrote: > I've got a nice idea for a new processor-extrension for spin-wait > -loops. The idea is that a thread of a processors enters a sleep > state if a word in memory is equal to a certain register until > the cacheline containing the word is modified or there's a timeout > according to the timestamp-counter's value. > This would eliminate active spinning and polling a value in memory. > Polling would occur only if the cacheline would be modified by > another thread. futex
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-23 13:58 -0700 |
| Message-ID | <utnfoq$3s1eu$1@dont-email.me> |
| In reply to | #118535 |
On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: > On 3/23/2024 9:53 AM, Bonita Montero wrote: >> I've got a nice idea for a new processor-extrension for spin-wait >> -loops. The idea is that a thread of a processors enters a sleep >> state if a word in memory is equal to a certain register until >> the cacheline containing the word is modified or there's a timeout >> according to the timestamp-counter's value. >> This would eliminate active spinning and polling a value in memory. >> Polling would occur only if the cacheline would be modified by >> another thread. > > futex MWAIT?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-24 07:38 +0100 |
| Message-ID | <utoho8$6p4u$2@raubtier-asyl.eternal-september.org> |
| In reply to | #118536 |
Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: > On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>> I've got a nice idea for a new processor-extrension for spin-wait >>> -loops. The idea is that a thread of a processors enters a sleep >>> state if a word in memory is equal to a certain register until >>> the cacheline containing the word is modified or there's a timeout >>> according to the timestamp-counter's value. >>> This would eliminate active spinning and polling a value in memory. >>> Polling would occur only if the cacheline would be modified by >>> another thread. >> >> futex > > MWAIT? MWAIT has no timeout.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-25 19:48 -0700 |
| Message-ID | <uttd1r$1ervd$1@dont-email.me> |
| In reply to | #118540 |
On 3/23/2024 11:38 PM, Bonita Montero wrote: > Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >> On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >>> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>>> I've got a nice idea for a new processor-extrension for spin-wait >>>> -loops. The idea is that a thread of a processors enters a sleep >>>> state if a word in memory is equal to a certain register until >>>> the cacheline containing the word is modified or there's a timeout >>>> according to the timestamp-counter's value. >>>> This would eliminate active spinning and polling a value in memory. >>>> Polling would occur only if the cacheline would be modified by >>>> another thread. >>> >>> futex >> >> MWAIT? > > MWAIT has no timeout. > Not sure how important it would be for MWAIT to have a timeout... You are referring to user space, right?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-26 11:12 +0100 |
| Message-ID | <utu71j$1obp8$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118552 |
Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: > On 3/23/2024 11:38 PM, Bonita Montero wrote: >> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >>> On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >>>> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>>>> I've got a nice idea for a new processor-extrension for spin-wait >>>>> -loops. The idea is that a thread of a processors enters a sleep >>>>> state if a word in memory is equal to a certain register until >>>>> the cacheline containing the word is modified or there's a timeout >>>>> according to the timestamp-counter's value. >>>>> This would eliminate active spinning and polling a value in memory. >>>>> Polling would occur only if the cacheline would be modified by >>>>> another thread. >>>> >>>> futex >>> >>> MWAIT? >> >> MWAIT has no timeout. >> > > Not sure how important it would be for MWAIT to have a timeout... You > are referring to user space, right? MWAIT could be used for limited spinning like glibc's pthread_mutex is capable. The advantage of a MWAIT with timout would be much less interconnect-traffic compared to polling.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-26 13:02 -0700 |
| Message-ID | <utv9l7$2anr0$2@dont-email.me> |
| In reply to | #118553 |
On 3/26/2024 3:12 AM, Bonita Montero wrote: > Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: >> On 3/23/2024 11:38 PM, Bonita Montero wrote: >>> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >>>> On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >>>>> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>>>>> I've got a nice idea for a new processor-extrension for spin-wait >>>>>> -loops. The idea is that a thread of a processors enters a sleep >>>>>> state if a word in memory is equal to a certain register until >>>>>> the cacheline containing the word is modified or there's a timeout >>>>>> according to the timestamp-counter's value. >>>>>> This would eliminate active spinning and polling a value in memory. >>>>>> Polling would occur only if the cacheline would be modified by >>>>>> another thread. >>>>> >>>>> futex >>>> >>>> MWAIT? >>> >>> MWAIT has no timeout. >>> >> >> Not sure how important it would be for MWAIT to have a timeout... You >> are referring to user space, right? > > MWAIT could be used for limited spinning like glibc's pthread_mutex > is capable. The advantage of a MWAIT with timout would be much less > interconnect-traffic compared to polling. > MWAIT is meant to get around polling?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-26 21:23 +0100 |
| Message-ID | <utvar6$2b6dl$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118557 |
Am 26.03.2024 um 21:02 schrieb Chris M. Thomasson: > On 3/26/2024 3:12 AM, Bonita Montero wrote: >> Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: >>> On 3/23/2024 11:38 PM, Bonita Montero wrote: >>>> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >>>>> On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >>>>>> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>>>>>> I've got a nice idea for a new processor-extrension for spin-wait >>>>>>> -loops. The idea is that a thread of a processors enters a sleep >>>>>>> state if a word in memory is equal to a certain register until >>>>>>> the cacheline containing the word is modified or there's a timeout >>>>>>> according to the timestamp-counter's value. >>>>>>> This would eliminate active spinning and polling a value in memory. >>>>>>> Polling would occur only if the cacheline would be modified by >>>>>>> another thread. >>>>>> >>>>>> futex >>>>> >>>>> MWAIT? >>>> >>>> MWAIT has no timeout. >>>> >>> >>> Not sure how important it would be for MWAIT to have a timeout... You >>> are referring to user space, right? >> >> MWAIT could be used for limited spinning like glibc's pthread_mutex >> is capable. The advantage of a MWAIT with timout would be much less >> interconnect-traffic compared to polling. >> > > MWAIT is meant to get around polling? MWAIT could replace polling / spinning on a mutex for a limited time if it would have a timeout.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-26 13:30 -0700 |
| Message-ID | <utvb9l$2anr0$6@dont-email.me> |
| In reply to | #118560 |
On 3/26/2024 1:23 PM, Bonita Montero wrote: > Am 26.03.2024 um 21:02 schrieb Chris M. Thomasson: >> On 3/26/2024 3:12 AM, Bonita Montero wrote: >>> Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: >>>> On 3/23/2024 11:38 PM, Bonita Montero wrote: >>>>> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >>>>>> On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >>>>>>> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>>>>>>> I've got a nice idea for a new processor-extrension for spin-wait >>>>>>>> -loops. The idea is that a thread of a processors enters a sleep >>>>>>>> state if a word in memory is equal to a certain register until >>>>>>>> the cacheline containing the word is modified or there's a timeout >>>>>>>> according to the timestamp-counter's value. >>>>>>>> This would eliminate active spinning and polling a value in memory. >>>>>>>> Polling would occur only if the cacheline would be modified by >>>>>>>> another thread. >>>>>>> >>>>>>> futex >>>>>> >>>>>> MWAIT? >>>>> >>>>> MWAIT has no timeout. >>>>> >>>> >>>> Not sure how important it would be for MWAIT to have a timeout... >>>> You are referring to user space, right? >>> >>> MWAIT could be used for limited spinning like glibc's pthread_mutex >>> is capable. The advantage of a MWAIT with timout would be much less >>> interconnect-traffic compared to polling. >>> >> >> MWAIT is meant to get around polling? > > MWAIT could replace polling / spinning on a mutex for a limited > time if it would have a timeout. > So, you timeout, check some other stuff, then wait again. Still sounds like polling?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-26 13:31 -0700 |
| Message-ID | <utvbas$2anr0$7@dont-email.me> |
| In reply to | #118561 |
On 3/26/2024 1:30 PM, Chris M. Thomasson wrote: > On 3/26/2024 1:23 PM, Bonita Montero wrote: >> Am 26.03.2024 um 21:02 schrieb Chris M. Thomasson: >>> On 3/26/2024 3:12 AM, Bonita Montero wrote: >>>> Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: >>>>> On 3/23/2024 11:38 PM, Bonita Montero wrote: >>>>>> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >>>>>>> On 3/23/2024 1:52 PM, Chris M. Thomasson wrote: >>>>>>>> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>>>>>>>> I've got a nice idea for a new processor-extrension for spin-wait >>>>>>>>> -loops. The idea is that a thread of a processors enters a sleep >>>>>>>>> state if a word in memory is equal to a certain register until >>>>>>>>> the cacheline containing the word is modified or there's a timeout >>>>>>>>> according to the timestamp-counter's value. >>>>>>>>> This would eliminate active spinning and polling a value in >>>>>>>>> memory. >>>>>>>>> Polling would occur only if the cacheline would be modified by >>>>>>>>> another thread. >>>>>>>> >>>>>>>> futex >>>>>>> >>>>>>> MWAIT? >>>>>> >>>>>> MWAIT has no timeout. >>>>>> >>>>> >>>>> Not sure how important it would be for MWAIT to have a timeout... >>>>> You are referring to user space, right? >>>> >>>> MWAIT could be used for limited spinning like glibc's pthread_mutex >>>> is capable. The advantage of a MWAIT with timout would be much less >>>> interconnect-traffic compared to polling. >>>> >>> >>> MWAIT is meant to get around polling? >> >> MWAIT could replace polling / spinning on a mutex for a limited >> time if it would have a timeout. >> > > So, you timeout, check some other stuff, then wait again. Still sounds > like polling? Sounds like you want a hardware based futex.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-27 10:18 +0100 |
| Message-ID | <uu0o9i$2oiqf$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118561 |
Am 26.03.2024 um 21:30 schrieb Chris M. Thomasson: > So, you timeout, check some other stuff, then wait again. > Still sounds like polling? The checks only would occur if the cacheline containing the word actually was modified.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-27 17:09 +0200 |
| Message-ID | <20240327180957.000049c7@yahoo.com> |
| In reply to | #118557 |
On Tue, 26 Mar 2024 13:02:47 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: > On 3/26/2024 3:12 AM, Bonita Montero wrote: > > Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: > >> On 3/23/2024 11:38 PM, Bonita Montero wrote: > >>> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: > >>>> > >>>> MWAIT? > >>> > >>> MWAIT has no timeout. > >>> > >> > >> Not sure how important it would be for MWAIT to have a timeout... > >> You are referring to user space, right? > > > > MWAIT could be used for limited spinning like glibc's pthread_mutex > > is capable. The advantage of a MWAIT with timout would be much less > > interconnect-traffic compared to polling. > > > > MWAIT is meant to get around polling? I don't know what you mean by 'get around'. The main point of original Monitor/MWAIT is to allow to one SMT thread to do polling on memory address in a way that consumes almost no core's execution resources thus allowing to the other SMT thread(s) of the same core to run faster. The sort of more intelligent PAUSE. In the absence of other SMT threads the main advantage of polling loop with Monitor/MWAIT vs simple tight polling loop (STPL) is reduced power consumption. As far as cache coherence traffic (CCT) is concerned, Monitor/MWAIT polling loop provides virtually no advantage relatively to STPL. Both are quite efficient from CCT perspective, at least as long as programmer does not do anything stupid. Later on Intel invented 'MWAIT for Power Management' that has slightly different objectives. But that is O.T.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-27 12:58 -0700 |
| Message-ID | <uu1tpq$31mt7$1@dont-email.me> |
| In reply to | #118578 |
On 3/27/2024 8:09 AM, Michael S wrote: > On Tue, 26 Mar 2024 13:02:47 -0700 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: > >> On 3/26/2024 3:12 AM, Bonita Montero wrote: >>> Am 26.03.2024 um 03:48 schrieb Chris M. Thomasson: >>>> On 3/23/2024 11:38 PM, Bonita Montero wrote: >>>>> Am 23.03.2024 um 21:58 schrieb Chris M. Thomasson: >>>>>> >>>>>> MWAIT? >>>>> >>>>> MWAIT has no timeout. >>>>> >>>> >>>> Not sure how important it would be for MWAIT to have a timeout... >>>> You are referring to user space, right? >>> >>> MWAIT could be used for limited spinning like glibc's pthread_mutex >>> is capable. The advantage of a MWAIT with timout would be much less >>> interconnect-traffic compared to polling. >>> >> >> MWAIT is meant to get around polling? > > I don't know what you mean by 'get around'. Turing a "hot" spin wait into a cooler one... ;^) > The main point of original Monitor/MWAIT is to allow to one SMT thread > to do polling on memory address in a way that consumes almost no core's > execution resources thus allowing to the other SMT thread(s) of the > same core to run faster. The sort of more intelligent PAUSE. > In the absence of other SMT threads the main advantage of polling > loop with Monitor/MWAIT vs simple tight polling loop (STPL) is reduced > power consumption. > As far as cache coherence traffic (CCT) is concerned, Monitor/MWAIT > polling loop provides virtually no advantage relatively to STPL. Both > are quite efficient from CCT perspective, at least as long as programmer > does not do anything stupid. > > Later on Intel invented 'MWAIT for Power Management' that has slightly > different objectives. But that is O.T. > Indeed.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-24 07:37 +0100 |
| Message-ID | <utohnb$6p4u$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118535 |
Am 23.03.2024 um 21:52 schrieb Chris M. Thomasson: > On 3/23/2024 9:53 AM, Bonita Montero wrote: >> I've got a nice idea for a new processor-extrension for spin-wait >> -loops. The idea is that a thread of a processors enters a sleep >> state if a word in memory is equal to a certain register until >> the cacheline containing the word is modified or there's a timeout >> according to the timestamp-counter's value. >> This would eliminate active spinning and polling a value in memory. >> Polling would occur only if the cacheline would be modified by >> another thread. > > futex Not all kinds of mutexes can be done with a futex.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-24 12:33 -0700 |
| Message-ID | <utpv6m$hvrl$1@dont-email.me> |
| In reply to | #118539 |
On 3/23/2024 11:37 PM, Bonita Montero wrote: > Am 23.03.2024 um 21:52 schrieb Chris M. Thomasson: >> On 3/23/2024 9:53 AM, Bonita Montero wrote: >>> I've got a nice idea for a new processor-extrension for spin-wait >>> -loops. The idea is that a thread of a processors enters a sleep >>> state if a word in memory is equal to a certain register until >>> the cacheline containing the word is modified or there's a timeout >>> according to the timestamp-counter's value. >>> This would eliminate active spinning and polling a value in memory. >>> Polling would occur only if the cacheline would be modified by >>> another thread. >> >> futex > > Not all kinds of mutexes can be done with a futex. > Have you ever heard of an asymmetric mutex?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-03-24 20:43 +0000 |
| Message-ID | <Zf0MN.450378$yEgf.411259@fx09.iad> |
| In reply to | #118535 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 3/23/2024 9:53 AM, Bonita Montero wrote: >> I've got a nice idea for a new processor-extrension for spin-wait >> -loops. The idea is that a thread of a processors enters a sleep >> state if a word in memory is equal to a certain register until A processor which is doesn't own (or have a shared copy) of the cacheline which would contain that word in memory will never know if it was modified, as it won't see the invalidate messages in a directory-based cache subsystem (leaving aside noncachable accesses to the word in memory, of course). This sounds like a solution to a problem that doesn't exist, and there would be no incentive for a processor designer to include the substantial additional complexity required to support your feature.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-25 07:23 +0100 |
| Message-ID | <utr58g$u29g$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118546 |
Am 24.03.2024 um 21:43 schrieb Scott Lurndal: > This sounds like a solution to a problem that doesn't exist, > and there would be no incentive for a processor designer > to include the substantial additional complexity required > to support your feature. MONITOR / MWAIT is nearly the same except for the timeout.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-25 14:34 +0200 |
| Message-ID | <20240325153450.000019cf@yahoo.com> |
| In reply to | #118546 |
On Sun, 24 Mar 2024 20:43:37 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > >On 3/23/2024 9:53 AM, Bonita Montero wrote: > >> I've got a nice idea for a new processor-extrension for spin-wait > >> -loops. The idea is that a thread of a processors enters a sleep > >> state if a word in memory is equal to a certain register until > > A processor which is doesn't own (or have a shared copy) of the > cacheline which would contain that word in memory will never know > if it was modified, as it won't see the invalidate messages in > a directory-based cache subsystem (leaving aside noncachable > accesses to the word in memory, of course). > It seems, I didn't understand the idea. Of course, the waiting thread/core has the word in question in its L1D cache when it enters the wait loop. Of course, it is awaken if/when the the word is evicted from the cache for unrelated reason, i.e. practically because of capacity conflict caused by activity of other threads that are running on the same core. There is nothing wrong with spurious awakenings as long as they are rare. > This sounds like a solution to a problem that doesn't exist, > and there would be no incentive for a processor designer > to include the substantial additional complexity required > to support your feature. The problem does exist and primitive proposed by Bonita is not new. It is a minor modification of Monitor/Mwait. For current Intel and AMD processors this sort of things is relatively unattractive because at 2 threads per core and with rather measurable throughput gains achieved by running 2 threads instead of one (for AMD up to 30%, for Intel a little less, but often measurable), each thread is a valuable resource, so you don't really want to keep it paused for too long time. And the whole point of Bonita's amendment of existing mechanism is that the software has more control on long waits. On IBM POWER and on few of Sun/Oracle chips they have up to 8 threads per core, so each thread is not that valuable. It means that longer uninterrupted wait has more sense and control of duration of the timeout is more desirable. But may be IBM's and Oracle's variants of MWAIT already have it?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-25 19:11 +0200 |
| Message-ID | <20240325201122.000031d6@yahoo.com> |
| In reply to | #118549 |
On Mon, 25 Mar 2024 14:34:50 +0200 Michael S <already5chosen@yahoo.com> wrote: > On Sun, 24 Mar 2024 20:43:37 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > > > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > > >On 3/23/2024 9:53 AM, Bonita Montero wrote: > > >> I've got a nice idea for a new processor-extrension for spin-wait > > >> -loops. The idea is that a thread of a processors enters a sleep > > >> state if a word in memory is equal to a certain register until > > >> > > > > A processor which is doesn't own (or have a shared copy) of the > > cacheline which would contain that word in memory will never know > > if it was modified, as it won't see the invalidate messages in > > a directory-based cache subsystem (leaving aside noncachable > > accesses to the word in memory, of course). > > > > It seems, I didn't understand the idea. I meant to say 'you' instead of 'I'.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-25 18:53 +0100 |
| Message-ID | <utsdnc$17sr6$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118549 |
Am 25.03.2024 um 13:34 schrieb Michael S: > The problem does exist and primitive proposed by Bonita is not new. > It is a minor modification of Monitor/Mwait. Functionally the modification is minor, but the effect would be major since the cache-interconnect traffic would be minimized.
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.lang.c++
csiph-web