Thursday, January 7, 2021

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 07 11:49AM -0800

On 1/7/2021 9:22 AM, Bonita Montero wrote:
>>> ensured by having a /-8-alignment.
 
>> DAGS "False Sharing", then reconsider your last statement.
 
> Where do I have a false sharing problem ?
 
In atomicValue.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 07 08:51PM +0100

>>> DAGS "False Sharing", then reconsider your last statement.
 
>> Where do I have a false sharing problem ?
 
> In atomicValue.
 
No, there's no false sharing. While the threads are hammering on
atomicValue, no other thread is doing anything on the cacheline
holding atomicValue. And the values around atomiValues aren't
touched meanwhile.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 07 11:54AM -0800

On 1/7/2021 11:51 AM, Bonita Montero wrote:
> atomicValue, no other thread is doing anything on the cacheline
> holding atomicValue. And the values around atomiValues aren't
> touched meanwhile.
 
atomicValue needs to be completely isolated. Padded up to a cache line
and aligned on a boundary.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 07 09:30PM +0100

>> touched meanwhile.
 
> atomicValue needs to be completely isolated. Padded up to a cache line
> and aligned on a boundary.
 
No, only if the data surrounding it in the cacheline is
concurrently accessed by other threads; but it isn't.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 07 01:39PM -0800

On 1/7/2021 12:30 PM, Bonita Montero wrote:
>> and aligned on a boundary.
 
> No, only if the data surrounding it in the cacheline is
> concurrently accessed by other threads; but it isn't.
 
Its an odd way to design things. You know, all threads might not startup
at the same time... ready, start and count, ect... intrude on
atomicValue. Why not just isolate it, and be done with it? Keep in mind,
aligned and padded...
Ian Collins <ian-news@hotmail.com>: Jan 08 08:27AM +1300

On 07/01/2021 22:37, David Brown wrote:
 
> But if those assertions are still in the final code, configured to do
> something else (log an error, restart the system, or whatever), then you
> are not testing the actual code.
 
How so? You are testing the behaviour of the code when "impossible"
circumstances occur (when the expectation is an assert), not the
behaviour of the assertion mechanism. It is trivial to test the
behaviour of the assertion mechanism with a death test.
 
> Many failures in real systems have been caused by people putting in
> extra checks "just to be sure" without proper verification of how those
> checks work and what happens if they trigger.
 
Which is precisely why asserts should be unit tested. By their very
nature, real world testing can't cause an assert.
 
--
Ian
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 07 03:40PM -0500

On 1/7/21 1:37 PM, Paavo Helde wrote:
...
> Of course, disabling an assert may hide or obfuscate an existing bug,
> but I have never seen a bug *created* by disabling an assert. On the
 
Neither have I. But that's partly because I don't use asserts very much
- the results when the assert triggers is generally not what I want to
have happen. I prefer the resulting message to contain information about
the specific values that triggered the assert, and the context of the
assert.
However, I have seen a bug hidden by enabling the constructs I use
instead of an assert. The fact that the it depended upon the value of a
given variable meant that code had to be generated to retrieve the value
of that variable. As a result, how that variable was optimized changed
in a way that hid a problem with how that variable was used. It's been a
while, so I unfortunately don't remember the details. It's possibly the
case that, since the framework I use instead of asserts is heavier than
a typical assert, it is more likely to affect how the code is optimized.
scott@slp53.sl.home (Scott Lurndal): Jan 07 09:11PM

>have happen. I prefer the resulting message to contain information about
>the specific values that triggered the assert, and the context of the
>assert.
 
I've seen them. Anytime there's a side effect in the assert, the behavior
will change when -DNDEBUG is specified. These can be very obscure and
difficult to find.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 07 11:50AM -0800

On 1/7/2021 2:56 AM, Arnold Ziffel wrote:
 
>> Yeah... It is idiotic to converse with him. I have a problem. Damn. For
>> some reason, he has a fairly strong ability to get my goat, so to speak.
 
> What can't you just killfile him?
 
Yeah... Shit. Well, I have never actually killfiled somebody. Back in
the day, decades ago, I said PLONK! But, never actually did it.
olcott <NoOne@NoWhere.com>: Jan 07 01:05PM -0600

On 1/7/2021 5:57 AM, Ben Bacarisse wrote:
> a partial one) but every TM has the property that the function it
> computes is not the halting function. Nothing nonexistent is ever
> imagined, we simply learn something universal about TMs.
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
 
The diagonal argument only shows that neither true nor false is a
correct value that Halts() can return to H_Hat().
 
This shallow analysis utterly ignores the possibility that H_Hat() can
be correctly decided by aborting the simulation of H_Hat before Halts()
returns any value to H_Hat() on the basis that the H_Hat() invocation of
Halts() would otherwise be infinitely recursive if Halts() did not stop
simulating it.
 
On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.
 
 
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
}
 
What is decider?
 
The term decider doesn't really have a standard meaning.
In fact, it is lamentable that Sipser chose the terms decider
and recognizer, since they seem to confuse students.
 
Intuitively, a decider should be a Turing machine that given
an input, halts and either accepts or rejects, relaying its
answer in one of many equivalent ways, such as halting
at an ACCEPT or REJECT state, or leaving its answer on
the output tape.
 
answered Nov 25 '17 at 8:35 Yuval Filmus top 0.03% overall
Assistant Professor in the Henry and Marilyn
Taub Department of Computer Science at the
Technion – Israel Institute of Technology.
https://cs.stackexchange.com/questions/84433/what-is-decider
 
The above proves that your stupid idea that a decider must return a
value to its every invocation is just as dishonest as many of the
things that you say. A decider must eventually halt in an accept
or reject state, yet is never required to return any value to it
otherwise infinite invocation.
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
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)