Bonita Montero <Bonita.Montero@gmail.com>: Feb 14 03:57PM +0100
Am 13.02.2024 um 19:08 schrieb Bonita Montero:
> There's nothing wrong with that. ...
Test this version which is the latest where I stopped further development:
#include <iostream>
#include <cstdlib>
#include <charconv>
#include <cstring>
#include <vector>
#include <algorithm>
#include <cmath>
#include <bit>
#include <fstream>
#include <string_view>
#include <thread>
#include <utility>
#include <new>
#include <span>
#include <array>
#include <cassert>
#include <sstream>
#if defined(_MSC_VER)
#include <intrin.h>
#elif defined(__GNUC__) || defined(__clang__)
#include <cpuid.h>
wij <wyniijj5@gmail.com>: Feb 14 12:15AM +0800
On Sun, 2023-12-10 at 10:46 +0100, Bonita Montero wrote:
> cpuId( 0x80000006u );
> return ((unsigned)regs[2] >> 16) * 1024;
> }
I just wrote a class PrimeTab to test prime numbers. It took 73s to
complete.
0.1s is too unbelievable. Something must be wrong.
------------- PrimeTab.h
#include <Wy.stdlib.h>
#include <CSCall/VLInt.h> // Very Large Integer
// [Syn] PrimeTab is a table for prime numbers
//
class PrimeTab {
typedef uint64_t NumType;
WY_ENSURE(sizeof(NumType)<=sizeof(size_t));
Wy::VLInt m_ptab;
NumType m_maxn;
// [Syn] Get the bit position storing info. for n
// 0= pos for n (n is composite) is not available
//
size_t bpos(NumType n) {
switch(n%6) {
case 1: return 2*(n/6);
case 5: return 2*(n/6)+1;
default: return 0;
}
};
public:
WY_DECL_REPLY;
PrimeTab() : m_ptab(), m_maxn(0) {};
PrimeTab(const PrimeTab& s) : m_ptab(s.m_ptab), m_maxn(s.m_maxn)
{};
PrimeTab(PrimeTab& s, Wy::ByMove_t) : m_ptab(s.m_ptab,Wy::ByMove),
m_maxn(s.m_maxn) {};
// [Syn] Create prime table for numbers<=maxn
//
explicit PrimeTab(NumType maxn) : m_ptab(), m_maxn(maxn) {
for(NumType n=2; n<=m_maxn; ++n) {
size_t p= bpos(n);
if(p==0) {
continue; // composite number
}
if(m_ptab.bit(p)) {
continue; // composite number
}
for(NumType m=n+n; m<=m_maxn; m+=n) {
Wy::Errno r=m_ptab.set_bit(bpos(m),true);
if(r!=Wy::Ok) {
WY_THROW( Reply(r) );
}
}
};
};
NumType max_num() const { return m_maxn; };
bool is_prime(NumType n) {
if(n>m_maxn) {
WY_THROW( Reply(EINVAL) );
}
if(n<=6) {
switch(n) {
case 1: // FALLTHROUGH
case 2: // FALLTHROUGH
case 3: // FALLTHROUGH
case 5: return true;
default: return false;
}
}
size_t p= bpos(n);
if(p==0) {
return false;
}
return !m_ptab.bit(p);
};
void swap(PrimeTab& ano) {
m_ptab.swap(ano.m_ptab);
Wy::swap(m_maxn, ano.m_maxn);
};
void reset() {
m_ptab.reset();
};
Wy::Errno reset(NumType maxn) try {
PrimeTab tmp(maxn);
Wy::swap(tmp);
return Wy::Ok;
}
catch(const Wy::Errno& e) {
WY_RETURN(e);
};
Wy::Errno reset(const PrimeTab& rhs) {
WY_RETURN(m_ptab.reset(rhs.m_ptab));
};
PrimeTab& operator=(const PrimeTab& rhs) {
Wy::Errno r=m_ptab.reset(rhs.m_ptab);
if(r!=Wy::Ok) {
WY_THROW( Reply(r) );
}
return *this;
};
};
-------------- chk_primetab.cpp
#include <Wy.stdio.h>
#include "PrimeTab.h"
using namespace Wy;
void ck1() {
size_t cnt;
PrimeTab ptab(1LL<<32);
cnt=0;
for(size_t n=0; n<ptab.max_num(); ++n) {
if(ptab.is_prime(n)) {
++cnt;
// cout << n << WY_ENDL;
}
}
cout << "cnt=" << cnt << WY_ENDL;
};
int main()
try {
cout << "Check PrimeTab.h ..." WY_ENDL;
ck1();
cout << "OK" WY_ENDL;
return 0;
}
catch(const Errno& e) {
cerr << wrd(e) << WY_ENDL;
return -1;
}
catch(...) {
cerr << "main caught(...)" WY_ENDL;
return -1;
};
-------------
[]$ g++ chk_primetab.cpp -lwy -O2
[]$ time ./a.out
Check PrimeTab.h ...
cnt=203280222
OK
real 1m13.716s
user 1m13.180s
sys 0m0.168s
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 13 07:08PM +0100
Am 13.02.2024 um 17:15 schrieb wij:
> I just wrote a class PrimeTab to test prime numbers. It took 73s to
> complete.
> 0.1s is too unbelievable. Something must be wrong.
There's nothing wrong with that. I'm storing the bits as a bitmap and
I'm using a segmented sieve and I partition the part beyond the square
root in chunks which are according to the logical number of CPUs and
these are further divided into chunks which fit into the L2-cache.
And the sequential lookup inside the bitmap below the square root
is done with countl_zero, which maps to a single CPU-instruction
on most computers.
The naive single-threeaded approach without cache-partititioning is
for sure magnitudes slower.
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 13 12:07PM +0100
If you initialize a function<>-object with a reference_wrapper it
is guaranteed that the function<>-object references an external
function-object without any memory allocation. libstdc++ and libc++
don't allocate any memory with such function<>-objects according
to the standard, but MSVC does allocate external memory.
#include <iostream>
#include <functional>
using namespace std;
void *operator new( size_t n )
{
cout << "alloc" << endl;
void *p = malloc( n );
if( !p )
throw bad_alloc();
return p;
}
void operator delete( void *p )
{
free( p );
}
int main()
{
function<void ()> fn;
string str( "hello word" );
auto lam = [str = str]() { cout << str << endl; };
fn = ref( lam );
fn();
}
|
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 10 08:53PM -0800
On 2/9/2024 9:11 PM, Bonita Montero wrote:
> header and re-enable them at the end, so that these headers
> won't disable those warnings for translation units of others
> using my code.
Yup. I think that would be the prudent thing to do. :^)
Okay.
|
Bonita Montero <Bonita.Montero@gmail.com>: Feb 10 06:11AM +0100
Am 09.02.2024 um 20:43 schrieb Chris M. Thomasson:
> I am saying that a user of your code might not want those
> warnings disabled at all. So, you should turn them back on.
In my own translation units I don't re-enable those warnings.
In headers I disable certain warnings at the beginning of the
header and re-enable them at the end, so that these headers
won't disable those warnings for translation units of others
using my code.
|
Bonita Montero <Bonita.Montero@gmail.com>: Feb 09 01:16PM +0100
Am 08.02.2024 um 22:28 schrieb Chris M. Thomasson:
> Keep in mind that your code disables those warnings. So, be sure to turn
> them back on for any and all user code!
Locking and unlocking mutexes is trivial and I don't need any addtional
aid for that. And MSVC runtime gives me a debug message if I try to
unlock a non-locked mutex; that's sufficient for me. And the shown
code is never trapped in that way.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 09 11:43AM -0800
On 2/9/2024 4:16 AM, Bonita Montero wrote:
> aid for that. And MSVC runtime gives me a debug message if I try to
> unlock a non-locked mutex; that's sufficient for me. And the shown
> code is never trapped in that way.
I am saying that a user of your code might not want those warnings
disabled at all. So, you should turn them back on.
|
Bonita Montero <Bonita.Montero@gmail.com>: Feb 08 01:07PM +0100
Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:
> __________________________________
> You just have to be very careful with this type of logic. These warnings
> elude to that.
Can't you read my code ?
That's still sth. completely different than what I did.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 08 12:02PM -0800
On 2/8/2024 4:07 AM, Bonita Montero wrote:
>> You just have to be very careful with this type of logic. These
>> warnings elude to that.
> Can't you read my code ?
Yes.
> That's still sth. completely different than what I did.
I just wanted to get MSVC to pop out those "false" warnings. Mission
accomplished.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 08 01:28PM -0800
On 2/8/2024 4:07 AM, Bonita Montero wrote:
>> warnings elude to that.
> Can't you read my code ?
> That's still sth. completely different than what I did.
Keep in mind that your code disables those warnings. So, be sure to turn
them back on for any and all user code!
|
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 07 12:47PM -0800
On 2/5/2024 11:10 PM, Chris M. Thomasson wrote:
> This is not giving me a warning, but an assertion. I am still wondering
> why Bonita has to suppress all of those warnings wrt this thread ala MSVC:
> https://groups.google.com/g/comp.lang.c++/c/pFsb3JI11-k
[...]
Okay, made some progress. Here is a little example of where the warnings
pop up. "Sketchy" use of std::unique_lock, well, imvvho that is:
___________________________________________
#include <iostream>
#include <functional>
#include <thread>
#include <mutex>
#include <cassert>
namespace ct
{
struct mutex_test
{
std::mutex m_mutex;
void
bar(std::unique_lock<std::mutex>& lock)
{
assert(lock);
lock.unlock();
}
void
foo()
{
std::unique_lock<std::mutex> lock(m_mutex);
// lock will be unlocked after this call!
bar(lock);
lock.lock(); // Yup...
}
};
}
int
main()
{
std::cout << "ct_threads... ;^)\n" << std::endl;
{
ct::mutex_test test;
test.foo();
}
return 0;
}
___________________________________________
Interesting wrt MSVC.
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 07 05:13PM +0100
Am 06.02.2024 um 20:55 schrieb Chris M. Thomasson:
>> Where the compiler warns me there are no errors,
>> these are false warnings.
> Well, that deserves a bug report?
I won't file it.
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 07 05:15PM +0100
Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:
> lock.unlock();
> //lock.unlock(); // this throws an exception.
> }
That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 07 12:38PM -0800
On 2/7/2024 8:15 AM, Bonita Montero wrote:
> That's sth. totally different. My function has the pre-condition
> that it inherits the lock of the calling function and sometimes
> it unlocks it.
Ahhh. I got them with:
__________________________________
namespace ct
{
struct mutex_test
{
std::mutex m_mutex;
void
bar(std::unique_lock<std::mutex>& lock)
{
assert(lock); // better be locked!
lock.unlock();
}
void
foo()
{
std::unique_lock<std::mutex> lock(m_mutex);
bar(lock); // beware. unlocks the damn thing!
lock.lock(); // okay...
}
};
}
__________________________________
Give the warnings:
__________________________________
Severity Code Description Project File Line Suppression State Details
Warning C26115 Failing to release lock 'this->m_mutex' in function
'ct::mutex_test::foo'. ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 26
Warning C26111 Caller failing to release lock 'this->m_mutex' before
calling function 'std::unique_lock<std::mutex>::lock'. ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 26
Warning C26110 Caller failing to hold lock 'lock' before calling
function 'std::unique_lock<std::mutex>::unlock'. ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 18
__________________________________
You just have to be very careful with this type of logic. These warnings
elude to that.
[...]
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 07 12:41PM -0800
On 2/7/2024 8:13 AM, Bonita Montero wrote:
>>> these are false warnings.
>> Well, that deserves a bug report?
> I won't file it.
Maybe you should. However, the warnings do flag some "sketchy" things
are going on.
| "ₛcₕₘₑᵣzfᵣₑᵢₑ ₛₜₑᵣbₑₕᵢₗfₑ" <w502fs8g@duck.com>: Feb 07 02:26AM
Anfragen: Sterbehilfe.yen631{@}dralias.[com] wie kann ich als deutscher
natrium pentobarbital kaufen schweiz.
Wenn Sie Pentobarbital (Nembutal) benötigen, aber einen diskreten Kauf
tätigen möchten, dann sind Sie bei uns genau richtig! Unsere
spezialisierten Dienstleistungen sind bestrebt, eine bequeme und
unkomplizierte Möglichkeit zur Bestellung von Pentobarbital-Nembutal in
pharmazeutischer Qualität zu bieten. Für sicheren Chat verwenden Sie die
Threema-ID: MX8ESP4F.
Unser Status als Top-Anbieter von Sterbehilfe medikamenten in Europa macht
uns stolz, da wir auf hochwertiges Apotheken-Pentobarbital angewiesen sind.
Dieser Erfolg spiegelt unser Engagement und unsere Kompetenz wider, unseren
geschätzten Kunden erstklassige Produkte zu liefern.
Es liegt uns am Herzen, Sie bei der Beschaffung von Pentobarbital in seinen
verschiedenen Formen, einschließlich Flüssigkeit, Pulver oder
Injektionsform, zu unterstützen. Bei der Suche nach vertrauenswürdigen
Lieferanten von Sterbehilfemedikamenten, die ihren Anforderungen gerecht
werden, stehen Käufer häufig vor Herausforderungen. Ihre Enttäuschung ist
oft darauf zurückzuführen, dass sie gefälschte Produkte erhalten.
Wenn Sie uns als Ihren Pentobarbital-Lieferanten auswählen, können Sie
sicher sein, dass wir höchste Qualität in pharmazeutischer Qualität
erhalten und garantieren, dass unsere Medikamente den höchsten Standards
entsprechen. Darüber hinaus sorgt unser Bemühen um einen sicheren Transport
dafür, dass Ihre Bestellung sicher an Sie geliefert wird. Wir sind uns der
Bedeutung von Diskretion bewusst und ergreifen Maßnahmen, um unseren
geschätzten Kunden ein schnelles und reibungsloses Einkaufserlebnis zu
bieten.
Wo kann man diskret eine tödliche Menge Pentobarbital für einen
schmerzfreien Tod erwerben? Anfragen: Sterbehilfe.yen631{@}dralias.[com]
oder Für sicheren Chat verwenden Sie die Threema-ID: MX8ESP4F
Bei verschiedenen Anwendungen werden Barbiturate allgemein als
Beruhigungsmittel für das Zentralnervensystem anerkannt. Sie werden häufig
als Beruhigungsmittel, Hypnotika, Antikonvulsiva in subhypnotischen Mengen
und sogar zur Sterbehilfe eingesetzt und bieten bedürftigen Menschen einen
ruhigen Abschluss.
Bitte Vorsicht walten lassen:
Sie bestätigen, dass Sie mindestens 27 Jahre alt sind. Durch Ihre
Einwilligung sind Sie sich voll und ganz darüber im Klaren, dass die auf
dieser Website zum Kauf angebotenen Artikel erhebliche Gefahren darstellen.
Sie verstehen die Bedeutung dieser Anerkennung und erklären sich damit
einverstanden, dass es in Ihrer Verantwortung liegt, diese Produkte
aufgrund ihrer gefährlichen Eigenschaften mit größter Sorgfalt und Respekt
zu behandeln.
Anfragen: Sterbehilfe.yen631{@}dralias.[com] wie kann ich als deutscher
natrium pentobarbital kaufen schweiz.
--
ᴷᵒⁿᵗᵃᵏᵗ: ˢᵗᵉʳᵇᵉʰⁱˡᶠᵉ.ʸᵉⁿ⁶³¹{@}ᵈʳᵃˡⁱᵃˢ.[ᶜᵒᵐ]
|
Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 07:12AM +0100
Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
> Can you create a little self-contained example that shows these warnings?
Make the pragmas commented and look what the IDE shows as warnings.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:34PM -0800
On 2/5/2024 10:12 PM, Bonita Montero wrote:
> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>> Can you create a little self-contained example that shows these warnings?
> Make the pragmas commented and look what the IDE shows as warnings.
What is in:
______________________
#include <cassert>
#include "thread_pool.h"
#include "invoke_on_destruct.h"
______________________
?
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:36PM -0800
On 2/5/2024 10:34 PM, Chris M. Thomasson wrote:
> #include "invoke_on_destruct.h"
> ______________________
> ?
You have some issues here. These warnings are not for kicks and giggles,
so to speak. If these warnings are wrong, you need to file a bug report
to the MSVC team.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:38PM -0800
On 2/5/2024 10:12 PM, Bonita Montero wrote:
> Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:
>> Can you create a little self-contained example that shows these warnings?
> Make the pragmas commented and look what the IDE shows as warnings.
Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 10:46PM -0800
On 2/5/2024 10:34 PM, Chris M. Thomasson wrote:
> #include <cassert>
> #include "thread_pool.h"
> #include "invoke_on_destruct.h"
^^^^^^^^^^^^^^^^^^^^^^
What is that for?
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 11:15AM +0100
Am 06.02.2024 um 07:34 schrieb Chris M. Thomasson:
> ______________________
> #include <cassert>
> #include "thread_pool.h"
The header I posted.
> #include "invoke_on_destruct.h"
Sth. like experimental::scope_exit, this is my code:
#pragma once
#include <utility>
template<typename Fn>
requires requires( Fn fn ) { { fn() }; }
struct invoke_on_destruct
{
private:
Fn m_fn;
bool m_enabled;
public:
invoke_on_destruct( Fn &&fn ) :
m_fn( std::forward<Fn>( fn ) ),
m_enabled( true )
{
}
~invoke_on_destruct()
{
if( m_enabled )
m_fn();
}
void operator ()()
{
if( m_enabled )
m_enabled = false,
m_fn();
}
void disable()
{
m_enabled = false;
}
invoke_on_destruct &enable()
{
m_enabled = true;
return *this;
}
};
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 11:17AM +0100
Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
> Think about getting a warning free compile. Think about what these
> warnings actually mean. If you find a bug, report it to the MSVC team.
Where the compiler warns me there are no errors,
these are false warnings.
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 06 02:01PM +0100
Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:
>> Make the pragmas commented and look what the IDE shows as warnings.
> Think about getting a warning free compile. Think about what these
> warnings actually mean. If you find a bug, report it to the MSVC team.
Try this ...
void fn( unique_lock<mutex> &lock )
{
assert(lock);
lock.unlock();
}
... and you'll get a warning.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 11:55AM -0800
On 2/6/2024 2:17 AM, Bonita Montero wrote:
>> warnings actually mean. If you find a bug, report it to the MSVC team.
> Where the compiler warns me there are no errors,
> these are false warnings.
Well, that deserves a bug report?
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 12:07PM -0800
On 2/6/2024 5:01 AM, Bonita Montero wrote:
> lock.unlock();
> }
> ... and you'll get a warning.
Fwiw, I get no warning with:
{
std::unique_lock<std::mutex> lock(m_mutex);
assert(lock);
lock.unlock();
//lock.unlock(); // this throws an exception.
}
The interesting part is the code for std::unique_lock:
~unique_lock() noexcept {
if (_Owns) {
_Pmtx->unlock();
}
}
I was wondering why std::unique_lock did not try to unlock it twice in
the dtor. Well, the code for std::~unique_lock that MSVC is using
answers my question. Its that _Owns variable. Humm...
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 11:10PM -0800
This is not giving me a warning, but an assertion. I am still wondering
why Bonita has to suppress all of those warnings wrt this thread ala MSVC:
https://groups.google.com/g/comp.lang.c++/c/pFsb3JI11-k
Here is some bugged code I just created, wrt MSVC version 17.8.5. No
warnings, but an assertion:
https://i.ibb.co/QQFyZQq/image.png
code:
____________________________________
#include <iostream>
#include <functional>
#include <thread>
#include <mutex>
namespace ct
{
struct mutex_test
{
std::mutex m_mutex;
void
works()
{
m_mutex.lock();
m_mutex.unlock();
}
void
foobar()
{
m_mutex.lock();
//m_mutex.unlock(); YIKES!
}
};
}
int
main()
{
std::cout << "ct_threads... ;^)\n" << std::endl;
{
ct::mutex_test test;
test.works();
test.foobar(); // humm... Kabboom!
}
return 0;
}
____________________________________
Btw, I am going to port my new XCHG based code from Relacy race detector
into actual C++ code where we all can play with it. Getting to a point
where I need to use it for a project.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 12:33AM -0800
On 2/5/2024 11:10 PM, Chris M. Thomasson wrote:
> This is not giving me a warning, but an assertion. I am still wondering
> why Bonita has to suppress all of those warnings wrt this thread ala MSVC:
> https://groups.google.com/g/comp.lang.c++/c/pFsb3JI11-k
[...]
Sometime tomorrow I can work on this. I need to compile the bugged test
code with the warning level bumped up.
|
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 04 08:20PM -0800
On 2/3/2024 10:41 PM, Bonita Montero wrote:
>> What happens if you turn off all of those very important warnings?
> What a question ...
> I get incorrect warnings while compiling.
https://youtu.be/hAMQIvEtcJM
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 05 09:01AM +0100
Am 04.02.2024 um 22:59 schrieb Chris M. Thomasson:
> Why are they incorrect, according to you? ...
No, according to what they should warn for.
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 11:09AM -0800
On 2/5/2024 12:01 AM, Bonita Montero wrote:
> Am 04.02.2024 um 22:59 schrieb Chris M. Thomasson:
>> Why are they incorrect, according to you? ...
> No, according to what they should warn for.
Can you create a little self-contained example that shows these warnings?
|
|
