Tuesday, January 12, 2021

Digest for comp.lang.c++@googlegroups.com - 14 updates in 7 topics

Melzzzzz <Melzzzzz@zzzzz.com>: Jan 12 10:05PM

> }
 
> I know I could make drawCurrentGameSituation(); public, but I feel it really should be private,
> isnt it?
 
And then?
 
 
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Bonita Montero <Bonita.Montero@gmail.com>: Jan 12 08:52PM +0100

I know this isn't a Windows-group.
But as the Win32-groups are dead I ask here.
There's an API called WakeByAddressSingle/ WakeByAddressSingle /
WakeByAddressAll. It is like a binary semaphore (Win32 event),
but it has a superior performance.
Look at this code:
 
#include <Windows.h>
#include <iostream>
#include <thread>
#include <vector>
#include <chrono>
#include <cstdint>
 
#pragma warning(disable: 6387)
 
using namespace std;
using namespace chrono;
 
int main()
{
using hrc_tp = time_point<high_resolution_clock>;
auto thrAddr = []( uint64_t count, void **waitOnThis, void **notifyThat )
{
void *cmp = nullptr;
for( ; count; --count )
{
while( *waitOnThis == cmp )
WaitOnAddress( waitOnThis, &cmp, sizeof(void *), INFINITE );
*waitOnThis = cmp;
*notifyThat = (void *)-1;
WakeByAddressSingle( notifyThat );
}
};
uint64_t const ROUNDS = 1'000'000;
void *waitA = (void *)-1,
*waitB = nullptr;
hrc_tp start = high_resolution_clock::now();
thread thrA( thrAddr, ROUNDS + 1, &waitA, &waitB ),
thrB( thrAddr, ROUNDS, &waitB, &waitA );
thrA.join();
thrB.join();
int64_t ns = duration_cast<nanoseconds>( high_resolution_clock::now() -
start ).count();
cout << "WaitOnAddress: " << (double)ns / ROUNDS << endl;
auto thrEvent = []( uint64_t count, HANDLE hEvtThis, HANDLE hEvtThat )
{
for( ; count; --count )
WaitForSingleObject( hEvtThis, INFINITE ),
SetEvent( hEvtThat );
};
HANDLE hEvtA = CreateEvent( nullptr, FALSE, TRUE, nullptr ),
hEvtB = CreateEvent( nullptr, FALSE, FALSE, nullptr );
start = high_resolution_clock::now();
thrA = thread( thrEvent, ROUNDS + 1, hEvtA, hEvtB );
thrB = thread( thrEvent, ROUNDS, hEvtB, hEvtA );
thrA.join();
thrB.join();
ns = duration_cast<nanoseconds>( high_resolution_clock::now() - start
).count();
cout << "WaitForSingleObject: " << (double)ns / ROUNDS << endl;
}
 
This outputs the following on my machine:
WaitOnAddress: 248.879
WaitForSingleObject: 10318.6
20 times the synchronization-performance like a kernel-event (binary
seamphore), this is really amazing. But does anyone know how this
works internally ? The following article is too vague to me:
https://devblogs.microsoft.com/oldnewthing/20160826-00/?p=94185
Bonita Montero <Bonita.Montero@gmail.com>: Jan 12 08:53PM +0100

> WaitOnAddress: 248.879
> WaitForSingleObject: 10318.6
> 20 times the synchronization-performance ...
 
No, 40 times.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 12 09:30PM +0100

Better use that, it doesn't require additional linker-settings:
 
#include <Windows.h>
#include <iostream>
#include <thread>
#include <vector>
#include <chrono>
#include <cstdint>
 
#pragma warning(disable: 6387)
 
using namespace std;
using namespace chrono;
 
int main()
{
using WOA_ADDR = BOOL (WINAPI *)( volatile VOID *, PVOID, SIZE_T, DWORD );
using WBAS_ADDR = void (WINAPI *)( PVOID );
HMODULE hmodSynch = LoadLibraryA( "API-MS-Win-Core-Synch-l1-2-0.dll" );
WOA_ADDR woa = (WOA_ADDR)GetProcAddress( hmodSynch,
"WaitOnAddress" );
WBAS_ADDR wbas = (WBAS_ADDR)GetProcAddress( hmodSynch,
"WakeByAddressSingle" );
using hrc_tp = time_point<high_resolution_clock>;
auto thrAddr = [&]( uint64_t count, void **waitOnThis, void **notifyThat )
{
void *cmp = nullptr;
for( ; count; --count )
{
while( *waitOnThis == cmp )
woa( waitOnThis, &cmp, sizeof(void *), INFINITE );
*waitOnThis = cmp;
*notifyThat = (void *)-1;
wbas( notifyThat );
}
};
uint64_t const ROUNDS = 1'000'000;
void *waitA = (void *)-1,
*waitB = nullptr;
hrc_tp start = high_resolution_clock::now();
thread thrA( thrAddr, ROUNDS + 1, &waitA, &waitB ),
thrB( thrAddr, ROUNDS, &waitB, &waitA );
thrA.join();
thrB.join();
int64_t ns = duration_cast<nanoseconds>( high_resolution_clock::now() -
start ).count();
cout << "WaitOnAddress: " << (double)ns / ROUNDS << endl;
auto thrEvent = []( uint64_t count, HANDLE hEvtThis, HANDLE hEvtThat )
{
for( ; count; --count )
WaitForSingleObject( hEvtThis, INFINITE ),
SetEvent( hEvtThat );
};
HANDLE hEvtA = CreateEvent( nullptr, FALSE, TRUE, nullptr ),
hEvtB = CreateEvent( nullptr, FALSE, FALSE, nullptr );
start = high_resolution_clock::now();
thrA = thread( thrEvent, ROUNDS + 1, hEvtA, hEvtB );
thrB = thread( thrEvent, ROUNDS, hEvtB, hEvtA );
thrA.join();
thrB.join();
ns = duration_cast<nanoseconds>( high_resolution_clock::now() - start
).count();
cout << "WaitForSingleObject: " << (double)ns / ROUNDS << endl;
}
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 12 01:01PM -0800

On 1/12/2021 11:52 AM, Bonita Montero wrote:
> WakeByAddressAll. It is like a binary semaphore (Win32 event),
> but it has a superior performance.
> Look at this code:
[...]
> seamphore), this is really amazing. But does anyone know how this
> works internally ? The following article is too vague to me:
> https://devblogs.microsoft.com/oldnewthing/20160826-00/?p=94185
 
Afaict, WaitOnAddress is akin to a futex. Its amazing to me that Windows
has this at all. It can be used to skip kernel calls. WaitOnAddress
should not be a direct kernel call on its fast path. However, when it
needs to wait, a slow path, it will use an underlying kernel object.
Most likely a large array of kernel objects. One way is hashing the
pointer address into a table of said wait objects. I have some older
code that does this. Iirc, called it multimutex.
 
For instance, a simple case, one can use a futex to add waiting ability
to a spinlock. Keep in mind that it can fail spuriously. So, a futex is
generally integrated into an existing spinlock using a loop.
 
I am not 100% sure, but WaitOnAddress sure seems like a futex.
Popping Mad <rainbow@colition.gov>: Jan 12 03:58PM -0500

On 12/18/16 10:54 AM, Öö Tiib wrote:
>> its job.
> Reading comprehension problem detected. Nah, just drop programming.
> There are easier jobs. Programming is not for you, sorry.
 
and you are still a dick.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 12 08:53PM

> favour doubles. simdjson may be an exception, it now claims it can
> convert without loosing precision, but users still report issues.
> But this is a wheel I wouldn't care to reinvent.
 
Sounds sensible.
 
> from pre-configured allocators, which is also reflected in the
> rapidjson issues. Floating point algorithms are hard to get right,
> and fast allocators are hard to make robust.
 
What is it about JSON which makes parsing speed so essential, anyway?
You'd think the actual I/O, plus the business logic, would dwarf the
parsing work for most use cases.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 12 12:50PM -0800

On 1/10/2021 3:35 PM, Chris M. Thomasson wrote:
 
> Well, check this crap out, on MSVC 2017... It seems to work fine. Can
> you compile it?
> _______________________________
[code snip]
 
> raw_mem = 01080000
> So far so good... raw_mem fits CT_PAGE_ALIGNMENT
> So far so good... &t->c fits CT_L2_ALIGNMENT
 
Notice the CT_PAGE_ALIGNMENT. Now, this allows one to do a lot of fun
and interesting things. Like stealing bits from the actual pointer
value. We can stuff meta data in a pointer, basically bit stealing. This
data can be used to create exotic lock-free algorithms. Even wait-free!
One can use it for a state machine. Or use it to round down to
CT_PAGE_ALIGNMENT, works well with memory allocators. Many different
things! Of course we would want to make sure that struct test is padded
to a CT_PAGE_ALIGNMENT. I did not do that here. But its rather trivial
to modify my example code.
"astro.del.cielo" <vedi@lasignature.com>: Jan 12 06:54PM +0100

Hi all!
 
I'm looking working code to get email subject to write to log file.
Write log is simple.
I need help with email subject
There is some worlinkg example?
I use Code Block with MinGW
 
Thanks!
 
--
a.d.c.
olcott <NoOne@NoWhere.com>: Jan 11 05:46PM -0600

On 1/11/2021 5:10 PM, Richard Damon wrote:
> of classical mathematics/Computer Science is based on anything other
> than what the machine, whose representation is provided as the input,
> would actually do?
 
Because H_Hat() meets the "Infinite Recursion detection" criteria it can
be verified that H_Hat() would actually never halt unless its simulation
is stopped.
 
Anyone understanding the meaning of the following words comprehends that
they are necessarily true:
 
Infinite Recursion detection AXIOM
(a) Within an execution trace
(b) The same function is called
(c) From the same machine address
(d) With the same data // Richard Damon credit
(e) A second time
(f) Without any control flow instructions inbetween
 
You already had a chance to find an error and you did find a gap. That
gap is now closed.
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Jan 11 07:26PM -0600

On 1/11/2021 2:17 PM, Kaz Kylheku wrote:
 
>> Does the simulation of the input have to be stopped to prevent its
>> otherwise infinite execution?
 
> That is exactly the same question,
 
Make sure that you pay attention to these key details
Make sure that you pay attention to these key details
Make sure that you pay attention to these key details
 
Ignoring these details instead of critiquing them is dishonest
Ignoring these details instead of critiquing them is dishonest
Ignoring these details instead of critiquing them is dishonest
 
This question has pathological self-reference:
Does the input halt on its input?
 
and answers yes when:
(a) The simulation of the input has to be stopped to prevent its
otherwise infinite execution.
 
and also answers yes when:
(b) The simulation of the input terminates without having to be stopped.
 
Can you see that the original question conflates these two distinct sets
together into one set?
(a) Non-halting set
(b) Halting set
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Jan 11 08:41PM -0600

On 1/11/2021 6:36 PM, Kaz Kylheku wrote:
 
> At every recursion level, it runs a simulation and that simulation
> consists of a loop wrapped around DebugStep. That loop necessarily
> contains of test and branch instructions.
 
When a judge decides whether or not a defendant is guilty the judge is a
separate and distinct entity from the defendant.
 
In this same way the halt decider and the simulator are separate and
distinct entities from the program under test.
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Jan 12 09:53AM -0600

On 1/10/2021 9:09 AM, Ben Bacarisse wrote:
 
> Yes, except that the question "Does the simulation of the input have to
> be stopped to prevent its otherwise infinite execution" is, itself, the
> classical halting problem.
 
This is one of the very rare times that you have ever agreed with me on
a material fact.
 
The original halting problem undecidability proof question:
Does the input halt on its input?
 
conflates together non-halting inputs with halting inputs
 
and answers yes when:
(a) The simulation of the input has to be stopped to prevent its
otherwise infinite execution.
 
and also answers yes when:
(b) The simulation of the input terminates without having to be stopped.
 
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Jan 12 11:50AM -0600

On 1/12/2021 11:15 AM, Kaz Kylheku wrote:
 
> I would myself never use "axiom" other than as the formal term in logic,
> in any context whatsoever. If I intended to say "self-evident", I would
> use "self-evident".
 
I don't think that the is any other commonly understood term that means:
[can very verified as completely true entirely based on its meaning]
besides axiom.
 
 
> You are utterly lying. I wrote the above several days ago. Hours after
> that, I posted a self-follow-up in which I noted that it was mistaken,
> and corrected it. Here is a snippet from the follow-up:
 
I am not lying, although I admit that (especially in your case)** I may
have been mistaken. I generally totally ignore at least half of the
replies so that I can focus more time on the software development aspect
of this.
 
** You are one of the most honest reviewers.
 
> terminates. The simulated ones are aborted before reaching termination, because
> the most ancestral simulation level clips the number of recursion levels
> available to the nestings.
 
Summing this up in simpler terms the Halt decider stops simulating its
input at the very first point in the execution trace where it can
correctly decide that its input would not otherwise stop executing.
 
> You've already admitted that a H_Hat(H_Hat) in fact terminates, though
> you refuse to actually provide an execution trace which confirms it
> (probably due to understandable embarassement or whatever).
 
I have provided the full execution trace of all of the user code if the
invocation of:
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
 
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt =", Input_Would_Halt);
}
 
The key aspect of this that I have been showing for the longest time is
the sequence of the execution trace that proves that H_Hat() meets the
Infinite Recursion detection criteria:
 
Output_Debug_Trace() [0001112e] size(124) capacity(65536)
[0000087e](01) 55 push ebp
[0000087f](02) 8bec mov ebp,esp
[00000881](01) 51 push ecx
[00000882](05) 684e080000 push 0000084e
[00000887](05) 684e080000 push 0000084e
[0000088c](05) e8ddfdffff call 0000066e ; call Halts(H_Hat,H_Hat)
[0000084e](01) 55 push ebp
[0000084f](02) 8bec mov ebp,esp
[00000851](01) 51 push ecx
[00000852](03) 8b4508 mov eax,[ebp+08]
[00000855](01) 50 push eax
[00000856](03) 8b4d08 mov ecx,[ebp+08]
[00000859](01) 51 push ecx
[0000085a](05) e80ffeffff call 0000066e ; call Halts(H_Hat,H_Hat)
[0000084e](01) 55 push ebp
[0000084f](02) 8bec mov ebp,esp
[00000851](01) 51 push ecx
[00000852](03) 8b4508 mov eax,[ebp+08]
[00000855](01) 50 push eax
[00000856](03) 8b4d08 mov ecx,[ebp+08]
[00000859](01) 51 push ecx
[0000085a](05) e80ffeffff call 0000066e ; call Halts(H_Hat,H_Hat)
 
Infinite Recursion detection AXIOM
(a) Within an execution trace
(b) The same function is called
(c) From the same machine address
(d) With the same data // Richard Damon credit
(e) A second time
(f) Without any control flow instructions inbetween
 
It can be verified entirely on the basis of its meaning that all of the
above is necessarily true. That all of the above is necessarily true is
complete proof that Halts() does decide H_Hat() correctly.
 
Any disagreement that all of the above is necessarily true without
pointing out any specific error in any of the above will be construed as
dishonesty. What I mean by dishonesty is the intentional divergence away
from an honest dialogue.
 
--
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)