Tuesday, September 28, 2021

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 06:55AM +0200

Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson:
>> so it's release-consistency.
 
>> You always write nonsense.
 
> Decrementing a semaphore requires acquire semantics.
 
No, I could have modified data before, so I need, release-semantics.
You are such a n00b.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 06:57AM +0200

Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
 
>> I still need to port it to Relacy, but it seems like you need acq_rel
>> here.
 
> Think about it... Waiting for something, implies acquire semantics.
 
No, when I release a lock and could have modified data,
I need release-semantics.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 10:27PM -0700

On 9/27/2021 9:55 PM, Bonita Montero wrote:
 
>> Decrementing a semaphore requires acquire semantics.
 
> No, I could have modified data before, so I need, release-semantics.
> You are such a n00b.
 
For some reason when I saw the word "wait", I think of acquire. Are you
sure you know all about memory barriers? I have worked with them in the
past.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 10:28PM -0700

On 9/27/2021 9:57 PM, Bonita Montero wrote:
 
>> Think about it... Waiting for something, implies acquire semantics.
 
> No, when I release a lock and could have modified data,
> I need release-semantics.
 
So, how can one utilize dual_monitor::wait? Does it wait on something?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 10:46PM -0700

On 9/25/2021 8:48 PM, Bonita Montero wrote:
 
> No, once I incremented the waiter or visitor count I can't set it back
> because it might have been reduced by someone awakening me. So I've to
> spin or terminate the program.
 
Terminate? Humm... If there are conditions arising in the system in
which SetEvent fails, you go into infinite loop here, right? Try to
handle this scenario. Find out why it failed, GetLastError.
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 10:49PM -0700

On 9/27/2021 10:27 PM, Chris M. Thomasson wrote:
 
>>> Decrementing a semaphore requires acquire semantics.
 
>> No, I could have modified data before, so I need, release-semantics.
>> You are such a n00b.
 
Waiting on something is acquire by nature. Show me where its not?
Actually, show me where to place the acquire and release barriers in a
semaphore? Can you do it? Should be a piece of cake, right?
 
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 08:33AM +0200

Am 28.09.2021 um 07:27 schrieb Chris M. Thomasson:
>> You are such a n00b.
 
> For some reason when I saw the word "wait", I think of acquire. Are you
> sure you know all about memory barriers? ...
 
Everything necessary here.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 08:33AM +0200

Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson:
 
>> No, when I release a lock and could have modified data,
>> I need release-semantics.
 
> So, how can one utilize dual_monitor::wait? Does it wait on something?
 
Its like waiting on a condvar, which might have modified any data
before.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 08:34AM +0200

Am 28.09.2021 um 07:46 schrieb Chris M. Thomasson:
 
> Terminate? Humm... If there are conditions arising in the system in
> which SetEvent fails, you go into infinite loop here, right? Try to
> handle this scenario. Find out why it failed, GetLastError.
 
If the system hasn't any resources to satisfy a simple WaitForSingle...
spinning is quite o.k..
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 28 12:03AM -0700

On 9/27/2021 11:33 PM, Bonita Montero wrote:
 
>> So, how can one utilize dual_monitor::wait? Does it wait on something?
 
> Its like waiting on a condvar, which might have modified any data
> before.
 
I was thinking along those lines. However, waiting on a condvar involves
several steps. It also involves reacquiring the mutex...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 28 12:05AM -0700

On 9/27/2021 11:34 PM, Bonita Montero wrote:
>> handle this scenario. Find out why it failed, GetLastError.
 
> If the system hasn't any resources to satisfy a simple WaitForSingle...
> spinning is quite o.k..
 
spinning indeed. However, you have no backoff. You are spinning full speed!
 
 
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
 
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 28 12:06AM -0700

On 9/27/2021 11:33 PM, Bonita Montero wrote:
 
>> For some reason when I saw the word "wait", I think of acquire. Are
>> you sure you know all about memory barriers? ...
 
> Everything necessary here.
 
For sure?
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 12:05PM +0200

Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson:
>> before.
 
> I was thinking along those lines. However, waiting on a condvar involves
> several steps. It also involves reacquiring the mutex...
 
With what I do the reacquisition is done by the side that unlocks the
mutex. It simply keeps the locked-flag while unlocking and sets the
visitor-event.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 12:06PM +0200

Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
> while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
> Oh shit. When shit hits the fan, so does this! Try to not bleed the
> system when its in dire straights?
 
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
David Brown <david.brown@hesbynett.no>: Sep 28 04:05PM +0200

On 28/09/2021 12:06, Bonita Montero wrote:
>> system when its in dire straights?
 
> That doesnt't matter under such conditions.
> Am I talking to a complete moron here ?
 
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is
pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to
want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 06:46PM +0200

Am 28.09.2021 um 16:05 schrieb David Brown:
> want to discuss it with people to check the details. Since Bonita
> responds with nothing but insults and arrogance, I think it is safe to
> assume her code is flawed and leave her with it.
 
Chris doesn't understand my code. He even doesn't understand that before
any wait-operations you use atomic operations with release consistency
and after you use atomic operations with acquire-consistency. He is
totally confused.
And with the above code: once a visitor has incremented the visitor
-counter it can't decrement it because it might have decremented by
the code wanting to wake up a visitor. So under extreme conditions
where the system doesn't have the least resources to satisfy such a
simple operations spinning is quite o.k. until the conditions become
better. The system isn't usable anyway then.
It's simply frustrating to explain such simple things. Chris is simply
a n00b which lacks basic knowledge.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 28 02:02PM -0700

On 9/28/2021 9:46 AM, Bonita Montero wrote:
> any wait-operations you use atomic operations with release consistency
> and after you use atomic operations with acquire-consistency. He is
> totally confused.
 
Ummm... WOW. You are confused, Big time. I already asked you to show me
exactly where to place the memory barriers necessary to implement a
semaphore. Can you do it? I can. Show me... I am interested to see if
you can do it. From what you are writing, I don't think you can. Oh
well. Shit happens.
 
 
> better. The system isn't usable anyway then.
> It's simply frustrating to explain such simple things. Chris is simply
> a n00b which lacks basic knowledge.
 
lol. Humm... Perhaps I should just leave you with it. You refuse to run
it through a race detector... Why? I was going to port it over to
Relacy, but now... Argh. Screw it. You do it.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 28 02:42PM -0700

On 9/28/2021 7:05 AM, David Brown wrote:
> want to discuss it with people to check the details. Since Bonita
> responds with nothing but insults and arrogance, I think it is safe to
> assume her code is flawed and leave her with it.
 
Yeah. Damn. She does not seem to know a whole lot about memory barriers,
those tricky bastards! ;^) I was trying to help her. Then I get spit on.
I asked her a simple question: Where do the memory barriers go for a
semaphore. So far, no answer. She is confused. Calling me a newb is
strange because I have been working with these types of things for decades.
 
I would love to see Bonita program a SPARC in RMO mode. That would be
amusing... Actually Sun gave me a SunFire T2000 after winning the first
round in their CoolThreads contest. My project was called vZOOM. That
damn server sounded like several vacuum cleaners running when I was
working with it.
 
I wonder if she knows what a #LoadStore | #LoadLoad barrier is. That
MEMBAR instruction was fun on the SPARC. ;^)
 
So, I will just shut up, and let her do her thing.
 
Oh well.
Juha Nieminen <nospam@thanks.invalid>: Sep 28 04:49AM

>> the data. In fact, I'm talking about the exact opposite: *Avoiding*
>> constructing a string into memory with the data.
 
> Why? In my practice this is a major usage scenario.
 
Because if I want to write something eg. into a file, I don't want to
first to have to create a dynamically allocated string, just to write
the contents of that string to the file and then destroy that string.
I want to write directly to the file.
 
>> types without requiring those custom types to create strings from
>> their data, and being able to directly output the data?
 
> Why? What's wrong with creating strings?
 
Because it's useless and inefficient, fills caches with useless
garbage and causes memory fragmentation. In the worst cases it consumes
a lot of RAM for no good reason.
 
Consider what happens if what you want to write to the file is, for
example, three large strings, which you want to write to the file
concatenated. What possible benefit would there be in first creating
a new string that's a concatenation of those three strings, and then
write that string, when you could just as well simply write the three
strings directly to the file?
 
I would ask you the reverse: Why dou you want to create a string first,
if you could just write to the file directly?
 
>> Just substitute std::ostream with something more efficient.
 
> I just did. It's called to_string().
 
to_string() does not write to a file.
 
>> contents (in whichever way they choose)?
 
> Why? A lot of data transfer mechanisms use internal memory buffers,
> which often are dynamically allocated.
 
Because if I am, for example, writing a bunch of strings to a file,
I don't want to first concatenate those strings to a new string in
memory before writing it. I want to write the strings directly to
the file without that useless middle step, which is just a waste
of time and memory.
Juha Nieminen <nospam@thanks.invalid>: Sep 28 04:53AM


> Because of speed. I just showed elsethread that serializing a large
> object into an in-memory string can be up to 10x faster than writing it
> into a std::ostream piece-by-piece.
 
Suppose that the 'a' object above consists of 2 large strings, and you
want to write them to 'os' concatenated.
 
Are you seriously telling me that it's more efficient to first create a
new dynamically allocated string, write the two strings from 'a' there,
write that string to 'os' and then destroy that temporary string, than
it would be to just write the two strings directly to 'os' one after
another?
 
If that were the case, then it logically follows that if you do that again
with the resulting concatenated temporary string, by creating a second
temporary string with it, it would be even faster! And if you do it a
third time, it would be even faster still!
 
It seems extraordinarily silly to have the std::ostream object right
there to be used, and *still* construct a useless temporary string just
to write it there.
Bart <bc@freeuk.com>: Sep 28 10:16AM +0100

On 28/09/2021 05:53, Juha Nieminen wrote:
> write that string to 'os' and then destroy that temporary string, than
> it would be to just write the two strings directly to 'os' one after
> another?
 
 
Bizarrely, yes it could be faster!
 
Because, for most objects that are not already strings, assembling into
a local temporary string, then dumping the whole string at once, might
be faster than calling some external character-at-a-time routine.
 
So even if your specific example of large strings is slower, overall
with a mix of objects, there might be a net benefit.
 
If the strings are large enough that having duplicates will impact on
memory resources, then that might be a consideration. But it might never
happen.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 28 01:23PM +0300

28.09.2021 07:53 Juha Nieminen kirjutas:
>> into a std::ostream piece-by-piece.
 
> Suppose that the 'a' object above consists of 2 large strings, and you
> want to write them to 'os' concatenated.
 
This is another task. If you already have data formatted into strings,
then of course these can be written directly to a file. But for that you
don't need a C++ std::ostream interface, you can write directly into the
file descriptor, or C++ streambuf(). If there are only a handful of
strings, then you can of course write them to the stream as well, the
overhead is insignificant.
 
What I'm talking is about outstreaming millions of small items
one-by-one, like advocated by ostream<< enthusiasts: just define a
proper operator<< overload and write everything in the ostream,
recursively, each number separately.
 
It's this formatting interface of C++ iostreams which is slow. With
MSVC++ I just stepped though an operator<<(std::ofstream&, int), this
involved at least 2 virtual function calls, 4 locking/unlocking of
current locale, and consulting TLS about the number of uncaught
exceptions, not to speak about tens of non-virtual function calls (which
hopefully get optimized away) and twiddling with the stream state. This
is all 100% unnecessary overhead for formatting an int in C locale. It
won't matter for a single debug printout line, but it will matter when
exporting a 100,000 line table into a CSV file.
 
> write that string to 'os' and then destroy that temporary string, than
> it would be to just write the two strings directly to 'os' one after
> another?
 
No, of course not.
 
[Rest of strawman arguments snipped]
Ian Collins <ian-news@hotmail.com>: Sep 29 10:34AM +1300

On 28/09/2021 23:23, Paavo Helde wrote:
> is all 100% unnecessary overhead for formatting an int in C locale. It
> won't matter for a single debug printout line, but it will matter when
> exporting a 100,000 line table into a CSV file.
 
Ah, right so it's the overhead of locale based formatting that's the
real problem here. Presumably this would be the same for C printing
functions as well. I can see why std::to_chars would have an advantage
here.
 
I haven't seen such an high overhead on Unix/Linux, I wonder of the
Windows way of doing things is more burdensome? An example wit timings
would be useful!
 
--
Ian.
Paul N <gw7rib@aol.com>: Sep 28 06:15AM -0700

On Thursday, September 23, 2021 at 7:30:30 PM UTC+1, olcott wrote:
> them an opportunity to either correct my errors or failing that show
> that their software engineering skills are insufficient to analyze the
> problem as presented.
 
I think your problem here is that you are trying to see if a program runs forever simply by emulating its running. Obviously if the emulation stops then that shows that the program terminates. But if it has been running for a bit, you still don't know whether it will run forever or if it will stop at some later point.
 
Although the problem of whether a computer program halts or not looks trivial, bear in mind that the technique could be used for other problems as well. For instance, imagine a program that tested whether a^n + b^n = c^n (where ^ means "to the power of") with a and b non-zero and n at least three. Such a program could pick a maximum value for a, b, c and n, test all values up to this max, then increase the max by one and repeat, only stopping when the equation is met. To determine whether such a program halted would be equivalent to solving Fermat's Last Theorem.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 28 07:24AM +0200

Am 25.09.2021 um 16:23 schrieb Bonita Montero:
 
>> i am still on 2-17, didn't like 2-19. Let's try 2020 when I have time...
 
> I think sooner or later all C++IDEs will have the capabilility to debug
> inspect the state inside the promise of a coroutine.
 
This feature is trivial to update because the variables of
a cououtine are simply a normal compiler-generated struct.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)