On 1/7/2024 9:48 PM, Bonita Montero wrote:
> Am 07.01.2024 um 21:46 schrieb Chris M. Thomasson:
>
>> I know that they had a problem and the provided workaround from Intel
>> really did help out. ...
>
> Absolutely not, not with four way associativity.
>

Whatever you say; Sigh. I am done with this.

On 1/8/2024 12:18 PM, Chris M. Thomasson wrote:
> On 1/7/2024 9:48 PM, Bonita Montero wrote:
>> Am 07.01.2024 um 21:46 schrieb Chris M. Thomasson:
>>
>>> I know that they had a problem and the provided workaround from Intel
>>> really did help out. ...
>>
>> Absolutely not, not with four way associativity.
>>
>
> Whatever you say; Sigh. I am done with this.

Intel just needs to call Bonita whenever they have an issue.

On 2024-01-08, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 07.01.2024 um 21:46 schrieb Chris M. Thomasson:
>
>> I know that they had a problem and the provided workaround from Intel
>> really did help out. ...
>
> Absolutely not, not with four way associativity.

You are referring to that as if it were some rescuing magic.

Four way associativity is quite poor. It's only a step above two-way,
which is a step above the bottom of the barrel: direct mapping.

The cache entries are tiny on the P4: 32 bytes. An entire set is just
128 bytes. Code that works intensely with a 128 byte block occupies
the entire set of four cache blocks. If anything else touches memory
that maps to the same set, an evacuation has to take place, and
then when that code is resumed, it will take a hit.

If two hyperthreads run the same function which works intensively
with a 128 byte area of the stack, and the distance between the
stacks is a multiple of 8K, they will interfere through the same
cache set. The cache set is 128 bytes; each thread wants to keep
its own 128 bytes in it.

The situation seems far from improbable to me.

We don't need more than four hyper-threads in order to blow the
four-way set associative cache. We just need more than one
in the above scenario.

Needing more that four would be the case for threads that are hammering
away on a 32 byte block. (And so since there are only two hyperthreads
on the P4, that wouldn't be a problem.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Am 09.01.2024 um 02:14 schrieb red floyd:
> On 1/8/2024 12:18 PM, Chris M. Thomasson wrote:
>> On 1/7/2024 9:48 PM, Bonita Montero wrote:
>>> Am 07.01.2024 um 21:46 schrieb Chris M. Thomasson:
>>>
>>>> I know that they had a problem and the provided workaround from
>>>> Intel really did help out. ...
>>>
>>> Absolutely not, not with four way associativity.
>>>
>>
>> Whatever you say; Sigh. I am done with this.
>
> Intel just needs to call Bonita whenever they have an issue.

Intel made a lot of mistakes with Pentium 4 and Itanium.
This is rather a minor "mistake".

Am 09.01.2024 um 03:02 schrieb Kaz Kylheku:

> Four way associativity is quite poor. It's only a step above two-way,
> which is a step above the bottom of the barrel: direct mapping.

That's your opinion. In 2000 this was o.k.

> The cache entries are tiny on the P4: 32 bytes.

No, the L1 line size is 64 bytes.

> An entire set is just 128 bytes.

No, four lines each 64 bytes.

On 1/8/2024 5:14 PM, red floyd wrote:
> On 1/8/2024 12:18 PM, Chris M. Thomasson wrote:
>> On 1/7/2024 9:48 PM, Bonita Montero wrote:
>>> Am 07.01.2024 um 21:46 schrieb Chris M. Thomasson:
>>>
>>>> I know that they had a problem and the provided workaround from
>>>> Intel really did help out. ...
>>>
>>> Absolutely not, not with four way associativity.
>>>
>>
>> Whatever you say; Sigh. I am done with this.
>
> Intel just needs to call Bonita whenever they have an issue.
>

Okay. You just made me laugh so hard I started to cough a bit! Wow.
Cleaned out the pipes, so to speak. Thanks. ROFL! Cough...

:^D

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 24/12/2023 08:36, Tim Rentsch wrote:
>
>> Depending on how the code is written, no modulo operations need
>> to be done, because they will be optimized away and done at
>> compile time. If we look at multiplying two numbers represented
>> by bits in bytes i and j, the two numbers are
>>
>> i*30 + a
>> j*30 + b
>>
>> for some a and b in { 1, 7, 11, 13 17, 19, 23, 29 }.
>>
>> The values we're interested in are the index of the product and
>> the residue of the product, namely
>>
>> (i*30+a) * (j*30+b) / 30 (for the index)
>> (i*30+a) * (j*30+b) % 30 (for the residue)
>>
>> Any term with a *30 in the numerator doesn't contribute to
>> the residue, and also can be combined with the by-30 divide
>> for computing the index. Thus these expressions can be
>> rewritten as
>>
>> i*30*j + i*b + j*a + (a*b/30) (for the index)
>> a*b%30 (for the residue)
>>
>> When a and b have values that are known at compile time,
>> neither the divide nor the remainder result in run-time
>> operations being done; all of that heavy lifting is
>> optimized away and done at compile time. Of course there
>> are some multiplies, but they are cheaper than divides, and
>> also can be done in parallel. (The multiplication a*b also
>> can be done at compile time.)
>>
>> The residue needs to be turned into a bit mask to do the
>> logical operation on the byte of bits, but here again that
>> computation can be optimized away and done at compile time.
>>
>> Does that all make sense?
>
> Right now, no. But that's me. I'll flag it to read again when I've
> had a better night's sleep.

I'm posting to nudge you into looking at this again, if
you haven't already.

I have now had a chance to get your source and run some
comparisons. A program along the lines I outlined can run much
faster than the code you posted (as well as needing less memory).
A good target is to find all primes less than 1e11, which needs
less than 4gB of ram.

I retired last year, and I haven't really written any code since. This
has turned out to be quite a fun little thing of a type I haven't had
time for for YEARS. And oddly I still don't seem to have enough time for
it... It's the garden, and the kid's gardens, and my mum's garden, and
all those holidays :)

But some optimisations. You'll remember in Bonita's first version the
bitmap was initialised to 0xaaaa, because it's a waste of time doing the
sieve for 2.

I pointed out that we don't need to even store the even numbers.

But there's more.

If you look at the bitmap when you've sieved for 2 you see

12 34 56 78
11 10 10 10...
which is a repeat of 2 after an initialisation word. That's the aaaa.

You can do the same with 3

123 456 789
111 110 110 110

except this time the repeat is 3. And annoyingly that doesn't map well
down onto a byte-based architecture. You end up with an initial word,
then a 3-word repeat. (If your word was 24 or 36 bytes it would only be
1 word, but I haven't seen that since the 1970s)

In hex, with lowest byte first, that is
fd b6 6d db b6 6d db

(That BTW is the same if you only store the odd numbers - a 3-word repeat.)

So rather than start off with your bitmap all set to 1s you can set it
to this repeating pattern. That replaces all the ANDs for all the values
of three with a memory fill with far fewer accesses.

You can do the same with 5:

12345 6789a bcdef
11111 11110 11110 11110

You can then AND your pattern for 3 with the one for 5, and get one with
a repeat length of 15, and set that into your bitmap. You've now
replaced about a fifth of all your AND operations with a flood fill.

This can carry on - for a while. Only a short while. You _can_ make a
sequence for lots of primes. But it gets quite long, quite quickly. For
up to 23, and not storing the evens, it's over 1E8 words long!

I was implementing a version of that when something else occurred to me.
You can sacrifice speed for store size if you're prepared to do an
integer divide for every prime lookup.

Group our numbers into 6s like this

012345
6789ab
cdefgh (YKWIM)
ijklmn

Mask out the ones divisible by 2 or 3 and you see

0123-5
-7---b
-d---h
-i---n

Except for the first "page" the pattern is identical. Your algorithm can be:
Divide your candidate by 6.
If the result is zero look up in the page zero table 0123-5
If it is non-zero index into a translation table like this
010002
If the translation is zero the number is not prime.
If it is not zero it is the index of the bit for this page which tells
me if the number is prime. And there need only be 2 bits for 6 numbers.

(6 is the product of the first primes 2 and 3)

It's still worth masking out the even numbers - they don't need the
divide, a simple AND detects them - and I suspect it's worth using a
much larger number than 6. 3*5*11*13 is 15,015, which seems as though it
might be a convenient size. And only about a third of the number aren't
known to be primes (5760 to be exact)

I might play with that idea some time.

But a note for the group of course - optimising this to the max has
nothing to do whatever with C++. The only C++ optimising I've found
myself doing is using raw pointers, not vector's operator[]. (certainly
not the at function). And also I found myself using emplace_back a lot.
It's a PITA because you can only emplace back a single item, and it is slow.

Andy

On Sun, 2023-12-10 at 10:46 +0100, Bonita Montero wrote:
> I've parallelized my sieve of Erastosthenes to all cores. The
> parallel
> threads do al the punching of the non-prime multiplex beyond sqrt(
> max
> ). I found that the algorithm is limited by the memory bandwith since
> the bit-range between sqrt( max ) and max is to large to fit inside
> the cache. So I partitioned the each thread to a number of bit-ranges
> that fits inside the L2-cache. With that I got a speedup of factor 28
> when calculating about the first 210 million primes, i.e. all primes
> <= 2 ^ 32.
> On my Zen4 16 core PC under Windows with clang-cl 16.0.5 producing
> the
> primes without any file output is only 0.28s. On my Linux-PC, a Zen2
> 64
> core CPU producing the same number of primes is about 0.09s.
> The file output is done with my own buffering. With that writing the
> mentioned prime number range results in a 2.2GB file which is written
> in about two seconds with a PCIe 4.0 SSD.
> The first parameter is the highest prime candidate to be generated,
> it can be prefixed with 0x for hex values. The second number is the
> name of the output file; it can be "" to suppress file output. The
> third parameter is the number of punching threads; if it is left the
> number of threads defaults to the number of threads reported by the
> runtime.
>
> #include <iostream>
> #include <cstdlib>
> #include <charconv>
> #include <cstring>
> #include <vector>
> #include <algorithm>
> #include <cmath>
> #include <bit>
> #include <fstream>
> #include <string_view>
> #include <thread>
> #include <mutex>
> #include <condition_variable>
> #include <utility>
> #include <semaphore>
> #include <atomic>
> #include <new>
> #include <span>
> #if defined(_MSC_VER)
> #include <intrin.h>
> #elif defined(__GNUC__) || defined(__clang__)
> #include <cpuid.h>
> #endif
>
> #if defined(_MSC_VER)
> #pragma warning(disable: 26495)
> #endif
>
> using namespace std;
>
> #if defined(__cpp_lib_hardware_interference_size)
> constexpr ptrdiff_t CL_SIZE = hardware_destructive_interference_size;
> #else
> constexpr ptrdiff_t CL_SIZE = 64;
> #endif
>
> size_t getL2Size();
>
> int main( int argc, char **argv )
> {
> if( argc < 2 )
> return EXIT_FAILURE;
> auto parse = []( char const *str, bool hex, auto &value )
> {
> from_chars_result fcr = from_chars( str, str +
> strlen( str ), value,
> !hex ? 10 : 16 );
> return fcr.ec == errc() && !*fcr.ptr;
> };
> char const *sizeStr = argv[1];
> bool hex = sizeStr[0] == '0' && (sizeStr[1] == 'x' ||
> sizeStr[1] == 'X');
> sizeStr += 2 * hex;
> size_t end;
> if( !parse( sizeStr, hex, end ) )
> return EXIT_FAILURE;
> if( (ptrdiff_t)end++ < 0 )
> throw bad_alloc();
> unsigned hc;
> if( argc < 4 || !parse( argv[3], false, hc ) )
> hc = jthread::hardware_concurrency();
> if( !hc )
> return EXIT_FAILURE;
> using word_t = size_t;
> constexpr size_t
> BITS = sizeof(word_t) * 8,
> CL_BITS = CL_SIZE * 8;
> union alignas(CL_SIZE) ndi_words_cl { word_t words[CL_SIZE /
> sizeof(word_t)]; ndi_words_cl() {} };
> size_t nCls = (end + CL_BITS - 1) / CL_BITS;
> vector<ndi_words_cl> sieveCachelines( (end + CL_BITS - 1) /
> CL_BITS );
> size_t nWords = (end + BITS - 1) / BITS;
> span<word_t> sieve( &sieveCachelines[0].words[0], nWords );
> auto fill = sieve.begin();
> *fill++ = (word_t)0xAAAAAAAAAAAAAAACu;
> if( fill != sieve.end() )
> for_each( fill, sieve.end(), []( word_t &w  ) { w =
> (word_t)0xAAAAAAAAAAAAAAAAu; } );
> size_t sqrt = (ptrdiff_t)ceil( ::sqrt( (ptrdiff_t)end ) );
> auto punch = [&]( auto, size_t start, size_t end, size_t
> prime )
> {
> if( start >= end )
> return;
> size_t multiple = start;
> if( prime >= BITS ) [[likely]]
> do
> sieve[multiple / BITS] &= rotl(
> (word_t)-2, multiple % BITS );
> while( (multiple += prime) < end );
> else
> {
> auto pSieve = sieve.begin() + multiple /
> BITS;
> do
> {
> word_t
> word = *pSieve,
> mask = rotl( (word_t)-2,
> multiple % BITS ),
> oldMask;
> do
> word &= mask,
> oldMask = mask,
> mask = rotl( mask, prime %
> BITS ),
> multiple += prime;
> while( mask < oldMask );
> *pSieve++ = word;
> } while( multiple < end );
> }
> };
> for( size_t prime = 3; prime < sqrt; ++prime )
> {
> for( auto pSieve = sieve.begin() + prime / BITS; ; )
> {
> if( word_t w = *pSieve >> prime % BITS; w )
> [[likely]]
> {
> prime += countr_zero( w );
> break;
> }
> prime = prime + BITS & -(ptrdiff_t)BITS;
> if( prime >= sqrt )
> break;
> }
> if( prime >= sqrt ) [[unlikely]]
> break;
> punch( false_type(), prime * prime, sqrt, prime );
> }
> auto scan = [&]( size_t start, size_t end, auto fn )
> {
> for( size_t prime = start; prime < end; )
> {
> word_t word = sieve[prime / BITS] >> prime %
> BITS;
> bool hasBits = word;
> for( unsigned gap; word; word >>= gap, word
> >>= 1 )
> {
> gap = countr_zero( word );
> if( (prime += gap) >= end )
> [[unlikely]]
> return;
> fn( prime );
> if( ++prime >= end ) [[unlikely]]
> return;
> }
> prime = (prime + BITS - hasBits) & -
> (ptrdiff_t)BITS;
> }
> };
> size_t bitsPerPartition = (end - sqrt) / hc;
> using range_t = pair<size_t, size_t>;
> vector<pair<size_t, size_t>> ranges;
> ranges.reserve( hc );
> for( size_t t = hc, rEnd = end, rStart; t--; rEnd = rStart )
> {
> rStart = sqrt + t * bitsPerPartition;
> size_t rClStart = rStart & -(CL_SIZE * 8);
> rStart = rClStart >= sqrt ? rClStart : sqrt;
> if( rStart >= rEnd )
> continue;
> ranges.emplace_back( rStart, rEnd );
> }
> vector<jthread> threads;
> threads.reserve( ranges.size() - 1 );
> static auto dbl = []( ptrdiff_t x ) { return (double)x; };
> double maxPartitionBits = dbl( getL2Size() ) * 8 / 3;
> for( range_t const &range : ranges )
> {
> auto rangePuncher = [&]( size_t rStart, size_t rEnd
> )
> {
> double nBits = dbl( rEnd - rStart );
> ptrdiff_t nPartitions = (ptrdiff_t)ceil(
> nBits / maxPartitionBits );
> double bitsPerPartition = nBits / dbl(
> nPartitions );
> for( ptrdiff_t p = nPartitions, pEnd = rEnd,
> pStart; p--; pEnd = pStart )
> {
> pStart = rStart +
> (ptrdiff_t)((double)p * bitsPerPartition);
> pStart &= -(CL_SIZE * 8);
> scan( 3, sqrt,
> [&]( size_t prime )
> {
> punch( true_type(),
> (pStart + prime - 1) / prime * prime, pEnd,
> prime );
> } );
> }
> };
> if( &range != &ranges.back() )
> threads.emplace_back( rangePuncher,
> range.first, range.second );
> else
> rangePuncher( range.first, range.second );
> }
> threads.resize( 0 );
> if( argc >= 3 && !*argv[2] )
> return EXIT_SUCCESS;
> ofstream ofs;
> ofs.exceptions( ofstream::failbit | ofstream::badbit );
> ofs.open( argc >= 3 ? argv[2] : "primes.txt",
> ofstream::binary |
> ofstream::trunc );
> constexpr size_t
> BUF_SIZE = 0x100000,
> AHEAD = 32;
> union ndi_char { char c; ndi_char() {} };
> vector<ndi_char> printBuf( BUF_SIZE + AHEAD - 1 );
> auto
> bufBegin = printBuf.begin(),
> bufEnd = bufBegin,
> bufFlush = bufBegin + BUF_SIZE;
> auto print = [&]() { ofs << string_view( &bufBegin->c,
> &to_address(
> bufEnd )->c ); };
> scan( 2, end,
> [&]( size_t prime )
> {
> auto [ptr, ec] = to_chars( &bufEnd->c,
> &bufEnd[AHEAD - 1].c, prime );
> if( ec != errc() ) [[unlikely]]
> throw system_error( (int)ec,
> generic_category(), "converson failed" );
> bufEnd = ptr - &bufBegin->c + bufBegin; //
> pointer to iterator - NOP
> bufEnd++->c = '\n';
> if( bufEnd >= bufFlush ) [[unlikely]]
> print(), bufEnd = bufBegin;
> } );
> print();
> }
>
> size_t getL2Size()
> {
> int regs[4];
> auto cpuId = [&]( unsigned code )
> {
> #if defined(_MSC_VER)
> __cpuid( regs, code );
> #elif defined(__GNUC__) || defined(__clang__)
> __cpuid(code, regs[0], regs[1], regs[2], regs[3]);
> #endif
> return regs[0];
> };
> if( (unsigned)cpuId( 0x80000000u ) < 0x80000006u )
> return 512ull * 1024;
> cpuId( 0x80000006u );
> return ((unsigned)regs[2] >> 16) * 1024;
> }

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.

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>
#endif

#if defined(_MSC_VER)
#pragma warning(disable: 26495) // uninitialized member
#endif

using namespace std;

#if defined(__cpp_lib_hardware_interference_size)
constexpr ptrdiff_t CL_SIZE = hardware_destructive_interference_size;
#else
constexpr ptrdiff_t CL_SIZE = 64;
#endif

size_t getL2Size();
bool smt();

int main( int argc, char **argv )
{ try
{
if( argc < 2 )
return EXIT_FAILURE;
auto parse = []( char const *str, auto &value )
{
bool hex = str[0] == '0' && tolower( str[1] ) == 'x';
str += 2 * hex;
auto [ptr, ec] = from_chars( str, str + strlen( str ), value, !hex ?
10 : 16 );
return ec == errc() && !*ptr;
};
size_t end;
if( !parse( argv[1], end ) )
return EXIT_FAILURE;
if( end < 2 )
return EXIT_FAILURE;
if( (ptrdiff_t)end++ < 0 )
throw bad_alloc();
unsigned
hc = jthread::hardware_concurrency(),
nThreads;
if( argc < 4 || !parse( argv[3], nThreads ) )
nThreads = hc;
if( !nThreads )
return EXIT_FAILURE;
using word_t = size_t;
constexpr size_t
BITS_PER_CL = CL_SIZE * 8,
BITS = sizeof(word_t) * 8;
size_t nBits = end / 2;
union alignas(CL_SIZE) ndi_words_cl { word_t words[CL_SIZE /
sizeof(word_t)]; ndi_words_cl() {} };
vector<ndi_words_cl> sieveCachelines( (nBits + BITS_PER_CL - 1) /
BITS_PER_CL );
span<word_t> sieve( &sieveCachelines[0].words[0], (nBits + BITS - 1) /
BITS );
assert(to_address( sieve.end() ) <= &to_address( sieveCachelines.end()
)->words[0]);
fill( sieve.begin(), sieve.end(), -1 );
auto punch = [&]( size_t start, size_t end, size_t prime, auto )
{
size_t
bit = start / 2,
bitEnd = end / 2;
if( bit >= bitEnd )
return;
if( prime >= BITS ) [[likely]]
do [[likely]]
sieve[bit / BITS] &= rotl( (word_t)-2, bit % BITS );
while( (bit += prime) < bitEnd );
else
{
auto pSieve = sieve.begin() + bit / BITS;
do [[likely]]
{
word_t
word = *pSieve,
mask = rotl( (word_t)-2, bit % BITS ),
oldMask;
do
word &= mask,
oldMask = mask,
mask = rotl( mask, prime % BITS ),
bit += prime;
while( mask < oldMask );
*pSieve++ = word;
} while( bit < bitEnd );
}
};
size_t sqrt = (ptrdiff_t)ceil( ::sqrt( (ptrdiff_t)end ) );
for( size_t bSqrt = sqrt / 2, bit = 1; bit < bSqrt; ++bit ) [[likely]]
{
auto pSieve = sieve.begin() + bit / BITS;
do [[likely]]
{
if( word_t w = *pSieve >> bit % BITS; w ) [[likely]]
{
bit += countr_zero( w );
break;
}
++pSieve;
bit = bit + BITS & -(ptrdiff_t)BITS;
} while( bit < bSqrt );
if( bit >= bSqrt ) [[unlikely]]
break;
size_t prime = 2 * bit + 1;
punch( prime * prime, sqrt, prime, false_type() );
}
auto scan = [&]( size_t start, size_t end, auto fn )
{
size_t
bit = start / 2,
bitEnd = end / 2;
if( bit >= bitEnd )
return;
auto pSieve = sieve.begin() + bit / BITS;
word_t word = *pSieve++ >> bit % BITS;
for( ; ; )
{
size_t nextWordBit = bit + BITS & -(ptrdiff_t)BITS;
for( unsigned gap; word; word >>= gap, word >>= 1 )
{
gap = countr_zero( word );
bit += gap;
if( bit >= bitEnd ) [[unlikely]]
return;
fn( bit++ * 2 + 1, true_type() );
}
bit = nextWordBit;
if( bit >= bitEnd ) [[unlikely]]
return;
word = *pSieve++;
}
};
static auto dbl = []( ptrdiff_t x ) { return (double)x; };
using range_t = pair<size_t, size_t>;
vector<range_t> ranges;
ranges.reserve( nThreads );
vector<jthread> threads;
threads.reserve( nThreads );
auto initiate = [&]( size_t start, auto fn )
{
ranges.resize( 0 );
double threadRange = dbl( end - start ) / nThreads;
for( size_t t = nThreads, trEnd = end, trStart; t--; trEnd = trStart
) [[likely]]
{
trStart = start + (ptrdiff_t)((ptrdiff_t)t * threadRange + 0.5);
size_t trClStart = trStart & -(2 * CL_SIZE * 8);
trStart = trClStart >= start ? trClStart : start;
if( trStart < trEnd )
ranges.emplace_back( trStart, trEnd );
}
for( range_t const &range : ranges )
if( &range != &ranges.back() )
threads.emplace_back( fn, range.first, range.second, true_type() );
else
fn( range.first, range.second, false_type() );
threads.resize( 0 );
};
double maxCacheRange = dbl( getL2Size() * 8 * 2 ) / 3 * (smt() &&
nThreads > hc / 2 ? 1 : 2);
initiate( sqrt,
[&]( size_t rStart, size_t rEnd, auto )
{
double thisThreadRange = dbl( rEnd - rStart );
ptrdiff_t nCachePartitions = (ptrdiff_t)ceil( thisThreadRange /
maxCacheRange );
double cacheRange = thisThreadRange / dbl( nCachePartitions );
for( size_t p = nCachePartitions, cacheEnd = rEnd, cacheStart; p--;
cacheEnd = cacheStart ) [[likely]]
{
cacheStart = rStart + (ptrdiff_t)((double)(ptrdiff_t)p * cacheRange
+ 0.5);
cacheStart &= -(2 * CL_SIZE * 8);
cacheStart = cacheStart >= sqrt ? cacheStart : sqrt;
scan( 3, sqrt,
[&]( size_t prime, auto )
{
size_t start = (cacheStart + prime - 1) / prime * prime;
start = start % 2 ? start : start + prime;
punch( start, cacheEnd, prime, true_type() );
} );
}
} );
if( bool count = false; argc >= 3 && (!*argv[2] || (count = strcmp(
argv[2], "*" ) == 0)) )
{
if( !count )
return EXIT_SUCCESS;
atomic<size_t> aNPrimes( 1 );
initiate( 3,
[&]( size_t rStart, size_t rEnd, auto )
{
size_t nPrimes = 0;
scan( rStart, rEnd, [&]( ... ) { ++nPrimes; } );
aNPrimes.fetch_add( nPrimes, memory_order::relaxed );
} );
cout << aNPrimes.load( memory_order::relaxed ) << " primes" << endl;
return EXIT_SUCCESS;
}
ofstream ofs;
ofs.exceptions( ofstream::failbit | ofstream::badbit );
ofs.open( argc >= 3 ? argv[2] : "primes.txt", ofstream::binary |
ofstream::trunc );
constexpr size_t
BUF_SIZE = 0x100000,
AHEAD = 32;
union ndi_char { char c; ndi_char() {} };
vector<ndi_char> rawPrintBuf( BUF_SIZE + AHEAD - 1 );
span printBuf( &to_address( rawPrintBuf.begin() )->c, &to_address(
rawPrintBuf.end() )->c );
auto
bufBegin = printBuf.begin(),
bufEnd = bufBegin,
bufFlush = bufBegin + BUF_SIZE;
auto print = [&]() { ofs << string_view( bufBegin, bufEnd ); };
auto printPrime = [&]( size_t prime, auto )
{
auto [ptr, ec] = to_chars( &*bufEnd, &bufEnd[AHEAD - 1], prime );
if( (bool)ec ) [[unlikely]]
throw system_error( (int)ec, generic_category(), "converson failed" );
bufEnd = ptr - &*bufBegin + bufBegin; // pointer to iterator - NOP
*bufEnd++ = '\n';
if( bufEnd >= bufFlush ) [[unlikely]]
print(), bufEnd = bufBegin;
};
printPrime( 2, false_type() );
scan( 3, end, printPrime );
print();
}
catch( exception const &exc )
{
cout << exc.what() << endl;
}
}

array<unsigned, 4> cpuId( unsigned code )
{ array<unsigned, 4> regs;
#if defined(_MSC_VER)
__cpuid( (int *)&regs[0], code );
#elif defined(__GNUC__) || defined(__clang__)
__cpuid(code, regs[0], regs[1], regs[2], regs[3]);
#endif
return regs;
}

bool smt()
{ if( cpuId( 0 )[0] < 1 )
return false;
return cpuId( 1 )[3] >> 28 & 1;
}

size_t getL2Size()
{ if( cpuId( 0x80000000u )[0] < 0x80000006u )
return 512ull * 1024;
return (cpuId( 0x80000006u )[2] >> 16) * 1024;
}

Vir Campestris <vir.campestris@invalid.invalid> writes:

> I retired last year, and I haven't really written any code since. This
> has turned out to be quite a fun little thing of a type I haven't had
> time for for YEARS. And oddly I still don't seem to have enough time
> for it... It's the garden, and the kid's gardens, and my mum's garden,
> and all those holidays :)
>
> But some optimisations. You'll remember in Bonita's first version the
> bitmap was initialised to 0xaaaa, because it's a waste of time doing
> the sieve for 2.
>
> I pointed out that we don't need to even store the even numbers.
>
> But there's more.
>
> If you look at the bitmap when you've sieved for 2 you see
>
> 12 34 56 78
> 11 10 10 10...
> which is a repeat of 2 after an initialisation word. That's the aaaa.
>
> You can do the same with 3
>
> 123 456 789
> 111 110 110 110
>
> except this time the repeat is 3. And annoyingly that doesn't map well
> down onto a byte-based architecture. You end up with an initial word,
> then a 3-word repeat. (If your word was 24 or 36 bytes it would only
> be 1 word, but I haven't seen that since the 1970s)
>
> In hex, with lowest byte first, that is
> fd b6 6d db b6 6d db
>
> (That BTW is the same if you only store the odd numbers - a 3-word repeat.)
>
> So rather than start off with your bitmap all set to 1s you can set it
> to this repeating pattern. That replaces all the ANDs for all the
> values of three with a memory fill with far fewer accesses.
>
> You can do the same with 5:
>
> 12345 6789a bcdef
> 11111 11110 11110 11110
>
> You can then AND your pattern for 3 with the one for 5, and get one
> with a repeat length of 15, and set that into your bitmap. You've now
> replaced about a fifth of all your AND operations with a flood fill.
>
> This can carry on - for a while. Only a short while. You _can_ make a
> sequence for lots of primes. But it gets quite long, quite
> quickly. For up to 23, and not storing the evens, it's over 1E8 words
> long!
>
> I was implementing a version of that when something else occurred to
> me. You can sacrifice speed for store size if you're prepared to do an
> integer divide for every prime lookup.

I explained before how numbers can be considered mod 30, of which
only the residues { 1, 7, 11, 13, 17, 19, 23, 29 } are candidates,
because all other residues are divisible by 2, 3, or 5. And very
conveniently, there are exactly 8 of these residues, so one byte
can be used to represent each block of 30 numbers (only 8 of which
might be prime). That cuts down on the space needed.

I also explained how the divides and remainders can be avoided,
by taking advantage of the structure of how the numbers being
considered are represented, and arranging that the difficult parts
be done at compile time.

I have an implementation (written in C) based on this approach that
determines all primes less than roughly 51.75 billion, taking just
under 56 seconds to complete. (No threading is used - code is all
single threaded.)

> [...]
>
> But a note for the group of course - optimising this to the max has
> nothing to do whatever with C++. The only C++ optimising I've found
> myself doing is using raw pointers, not vector's
> operator[]. (certainly not the at function). And also I found myself
> using emplace_back a lot. It's a PITA because you can only emplace
> back a single item, and it is slow.

My program is written in C and uses ordinary C arrays. I expect it
could be converted to C++ without too much difficulty.

Am 16.02.2024 um 17:06 schrieb Tim Rentsch:

> I have an implementation (written in C) based on this approach that
> determines all primes less than roughly 51.75 billion, taking just
> under 56 seconds to complete. (No threading is used - code is all
> single threaded.)

On my 16 core PC this takes 1.73 seconds and 43 seconds
overall CPU time without printing the numbers to a file.

C:\Users\Boni\Documents\Source\bitmapSieve>timep
"x64\Release-clang++\bitmapSieve.exe" 51750000000 ""
real 1.729s
user 43.094s
sys 0.094s
cylces 194.738.953.589

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 16.02.2024 um 17:06 schrieb Tim Rentsch:
>
>> I have an implementation (written in C) based on this approach that
>> determines all primes less than roughly 51.75 billion, taking just
>> under 56 seconds to complete. (No threading is used - code is all
>> single threaded.)
>
> On my 16 core PC this takes 1.73 seconds and 43 seconds
> overall CPU time without printing the numbers to a file.
>
> C:\Users\Boni\Documents\Source\bitmapSieve>timep
> "x64\Release-clang++\bitmapSieve.exe" 51750000000 ""
> real 1.729s
> user 43.094s
> sys 0.094s
> cylces 194.738.953.589

If you run the program as a single thread, what is the
elapsed time?

Also how long does the program take to determine all
primes up to 3 trillion? Here again I am interested
in the single-thread version.

Am 23.02.2024 um 14:51 schrieb Tim Rentsch:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 16.02.2024 um 17:06 schrieb Tim Rentsch:
>>
>>> I have an implementation (written in C) based on this approach that
>>> determines all primes less than roughly 51.75 billion, taking just
>>> under 56 seconds to complete. (No threading is used - code is all
>>> single threaded.)
>>
>> On my 16 core PC this takes 1.73 seconds and 43 seconds
>> overall CPU time without printing the numbers to a file.
>>
>> C:\Users\Boni\Documents\Source\bitmapSieve>timep
>> "x64\Release-clang++\bitmapSieve.exe" 51750000000 ""
>> real 1.729s
>> user 43.094s
>> sys 0.094s
>> cylces 194.738.953.589
>
> If you run the program as a single thread, what is the
> elapsed time?

C:\Users\Boni\Documents\Source\bitmapSieve>timep
"x64\Release-clang++\bitmapSieve.exe" 51750000000 "" 1
real 22.945s
user 22.672s
sys 0.234s
cylces 102.917.207.295

> Also how long does the program take to determine all
> primes up to 3 trillion? Here again I am interested
> in the single-thread version.

C:\Users\Boni\Documents\Source\bitmapSieve>timep
"x64\Release-clang++\bitmapSieve.exe" 3000000000 "" 1
real 1.234s
user 1.203s
sys 0.031s
cylces 5.523.677.002

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 23.02.2024 um 14:51 schrieb Tim Rentsch:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 16.02.2024 um 17:06 schrieb Tim Rentsch:
>>>
>>>> I have an implementation (written in C) based on this approach that
>>>> determines all primes less than roughly 51.75 billion, taking just
>>>> under 56 seconds to complete. (No threading is used - code is all
>>>> single threaded.)
>>>
>>> On my 16 core PC this takes 1.73 seconds and 43 seconds
>>> overall CPU time without printing the numbers to a file.
>>>
>>> C:\Users\Boni\Documents\Source\bitmapSieve>timep
>>> "x64\Release-clang++\bitmapSieve.exe" 51750000000 ""
>>> real 1.729s
>>> user 43.094s
>>> sys 0.094s
>>> cylces 194.738.953.589
>>
>> If you run the program as a single thread, what is the
>> elapsed time?
>
> C:\Users\Boni\Documents\Source\bitmapSieve>timep
> "x64\Release-clang++\bitmapSieve.exe" 51750000000 "" 1
> real 22.945s
> user 22.672s
> sys 0.234s
> cylces 102.917.207.295

Hmmm. Interesting that the multi-threaded version uses almost
most twice as much CPU as the single-threaded version. I might
have guessed more, but not twice as much.

>> Also how long does the program take to determine all
>> primes up to 3 trillion? Here again I am interested
>> in the single-thread version.
>
> C:\Users\Boni\Documents\Source\bitmapSieve>timep
> "x64\Release-clang++\bitmapSieve.exe" 3000000000 "" 1
> real 1.234s
> user 1.203s
> sys 0.031s
> cylces 5.523.677.002

What I asked for was 3 trillion with a T, not 3 billion with
a B. Not 3000000000 but 3000000000000.

Am 25.02.2024 um 09:48 schrieb Tim Rentsch:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 23.02.2024 um 14:51 schrieb Tim Rentsch:
>>
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> Am 16.02.2024 um 17:06 schrieb Tim Rentsch:
>>>>
>>>>> I have an implementation (written in C) based on this approach that
>>>>> determines all primes less than roughly 51.75 billion, taking just
>>>>> under 56 seconds to complete. (No threading is used - code is all
>>>>> single threaded.)
>>>>
>>>> On my 16 core PC this takes 1.73 seconds and 43 seconds
>>>> overall CPU time without printing the numbers to a file.
>>>>
>>>> C:\Users\Boni\Documents\Source\bitmapSieve>timep
>>>> "x64\Release-clang++\bitmapSieve.exe" 51750000000 ""
>>>> real 1.729s
>>>> user 43.094s
>>>> sys 0.094s
>>>> cylces 194.738.953.589
>>>
>>> If you run the program as a single thread, what is the
>>> elapsed time?
>>
>> C:\Users\Boni\Documents\Source\bitmapSieve>timep
>> "x64\Release-clang++\bitmapSieve.exe" 51750000000 "" 1
>> real 22.945s
>> user 22.672s
>> sys 0.234s
>> cylces 102.917.207.295
>
> Hmmm. Interesting that the multi-threaded version uses almost
> most twice as much CPU as the single-threaded version. I might
> have guessed more, but not twice as much.

It's because the threads are competing on the L2-cache.
Look at the difference betwen 16 cores without SMT and
16 cores with SMT:

C:\Users\Boni\Documents\Source\bitmapSieve>timep
"x64\Release-clang++\bitmapSieve.exe" 51750000000 "" 16
real 1.916s
user 24.063s
sys 0.109s
cylces 110.113.013.925

C:\Users\Boni\Documents\Source\bitmapSieve>timep
"x64\Release-clang++\bitmapSieve.exe" 51750000000 "" 32
real 1.796s
user 44.703s
sys 0.063s
cylces 203.299.498.170

>
>>> Also how long does the program take to determine all
>>> primes up to 3 trillion? Here again I am interested
>>> in the single-thread version.
>>
>> C:\Users\Boni\Documents\Source\bitmapSieve>timep
>> "x64\Release-clang++\bitmapSieve.exe" 3000000000 "" 1
>> real 1.234s
>> user 1.203s
>> sys 0.031s
>> cylces 5.523.677.002
>
> What I asked for was 3 trillion with a T, not 3 billion with
> a B. Not 3000000000 but 3000000000000.

That would in a bitmap of 375GiB, which won't fit into my memory.

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 25.02.2024 um 09:48 schrieb Tim Rentsch:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 23.02.2024 um 14:51 schrieb Tim Rentsch:
>>>
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> Am 16.02.2024 um 17:06 schrieb Tim Rentsch:

[...]

>>>> Also how long does the program take to determine all
>>>> primes up to 3 trillion? Here again I am interested
>>>> in the single-thread version.
>>>
>>> C:\Users\Boni\Documents\Source\bitmapSieve>timep
>>> "x64\Release-clang++\bitmapSieve.exe" 3000000000 "" 1
>>> real 1.234s
>>> user 1.203s
>>> sys 0.031s
>>> cylces 5.523.677.002
>>
>> What I asked for was 3 trillion with a T, not 3 billion with
>> a B. Not 3000000000 but 3000000000000.
>
> That would in a bitmap of 375GiB, which won't fit into my memory.

Sounds like you're using 1 bit per number, most of which are
wasted. If you use a different encoding the memory requirements
can be much smaller. How much memory do you have on the box?
If you have 64G you should be able to determine all primes
less than 1.5 trillion, using a simple encoding.

I've mentioned this encoding before but let me give it again.
If numbers are considered mod 30, there are only 8 residues
that are not divisible by 2, 3, or 5. The 8 residues are
1, 7, 11, 13, 17, 19, 23, and 29. So a single byte can
hold all the information needed for 30 numbers, which means

1500000000000 / 30 = 50000000000

which is to say 50 gigabytes should suffice.

Am 11.03.2024 um 18:10 schrieb Tim Rentsch:

> Sounds like you're using 1 bit per number, most of which are
> wasted. If you use a different encoding the memory requirements
> can be much smaller. How much memory do you have on the box?
> If you have 64G you should be able to determine all primes
> less than 1.5 trillion, using a simple encoding.

I'm omitting even numbers and I handle the number two as a
special case; that's the fastest solution.

> I've mentioned this encoding before but let me give it again.
> If numbers are considered mod 30, there are only 8 residues
> that are not divisible by 2, 3, or 5. The 8 residues are
> 1, 7, 11, 13, 17, 19, 23, and 29. So a single byte can
> hold all the information needed for 30 numbers, which means
>
> 1500000000000 / 30 = 50000000000
>
> which is to say 50 gigabytes should suffice.

Show me the code.

On Tue, 2024-03-12 at 10:15 +0100, Bonita Montero wrote:
> Am 11.03.2024 um 18:10 schrieb Tim Rentsch:
>
> > Sounds like you're using 1 bit per number, most of which are
> > wasted.  If you use a different encoding the memory requirements
> > can be much smaller.  How much memory do you have on the box?
> > If you have 64G you should be able to determine all primes
> > less than 1.5 trillion, using a simple encoding.
>
> I'm omitting even numbers and I handle the number two as a
> special case; that's the fastest solution.
>
> > I've mentioned this encoding before but let me give it again.
> > If numbers are considered mod 30, there are only 8 residues
> > that are not divisible by 2, 3, or 5.  The 8 residues are
> > 1, 7, 11, 13, 17, 19, 23, and 29.  So a single byte can
> > hold all the information needed for 30 numbers, which means
> >
> >     1500000000000 / 30 = 50000000000
> >
> > which is to say 50 gigabytes should suffice.
>
> Show me the code.
>

Every 30 natural numbers (or more) can be coded in one byte(8 bits):

//----------------------------------------
#include <Wy.stdlib.h>
#include <CSCall/VLInt.h>

// [Syn] PrimeTab is a table for prime numbers
//
class PrimeTab {
public:
typedef uint64_t NumType;

private:
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
//
static size_t bpos(NumType n) {
constexpr NumType Lcm=2*3*5;
const NumType grp= 8*(n/Lcm);
switch(n%30) {
case 1: return grp;
case 7: return grp+1;
case 11: return grp+2;
case 13: return grp+3;
case 17: return grp+4;
case 19: return grp+5;
case 23: return grp+6;
case 29: return grp+7;
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) {};
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) const {
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);
this->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;
};
};

Am 14.03.2024 um 05:44 schrieb wij:
> On Tue, 2024-03-12 at 10:15 +0100, Bonita Montero wrote:
>> Am 11.03.2024 um 18:10 schrieb Tim Rentsch:
>>
>>> Sounds like you're using 1 bit per number, most of which are
>>> wasted.  If you use a different encoding the memory requirements
>>> can be much smaller.  How much memory do you have on the box?
>>> If you have 64G you should be able to determine all primes
>>> less than 1.5 trillion, using a simple encoding.
>>
>> I'm omitting even numbers and I handle the number two as a
>> special case; that's the fastest solution.
>>
>>> I've mentioned this encoding before but let me give it again.
>>> If numbers are considered mod 30, there are only 8 residues
>>> that are not divisible by 2, 3, or 5.  The 8 residues are
>>> 1, 7, 11, 13, 17, 19, 23, and 29.  So a single byte can
>>> hold all the information needed for 30 numbers, which means
>>>
>>>     1500000000000 / 30 = 50000000000
>>>
>>> which is to say 50 gigabytes should suffice.
>>
>> Show me the code.
>>
>
> Every 30 natural numbers (or more) can be coded in one byte(8 bits):

Show me a working sieve with that that beats my code.

> //----------------------------------------
> #include <Wy.stdlib.h>
> #include <CSCall/VLInt.h>
>
> // [Syn] PrimeTab is a table for prime numbers
> //
> class PrimeTab {
> public:
> typedef uint64_t NumType;
>
> private:
> 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
> //
> static size_t bpos(NumType n) {
> constexpr NumType Lcm=2*3*5;
> const NumType grp= 8*(n/Lcm);
> switch(n%30) {
> case 1: return grp;
> case 7: return grp+1;
> case 11: return grp+2;
> case 13: return grp+3;
> case 17: return grp+4;
> case 19: return grp+5;
> case 23: return grp+6;
> case 29: return grp+7;
> 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) {};
> 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) const {
> 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);
> this->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;
> };
> };
>
>

On 12/26/2023 9:06 PM, Bonita Montero wrote:
> Am 26.12.2023 um 21:24 schrieb Chris M. Thomasson:
>
>> So, are you familiar with Intel's early hyper threading problem?
>> There was false sharing between the ...
>
> False sharing can only happen between different cores.

Sigh.

Am 23.03.2024 um 03:34 schrieb Chris M. Thomasson:
> On 12/26/2023 9:06 PM, Bonita Montero wrote:
>> Am 26.12.2023 um 21:24 schrieb Chris M. Thomasson:
>>
>>> So, are you familiar with Intel's early hyper threading problem?
>>> There was false sharing between the ...
>>
>> False sharing can only happen between different cores.
>
> Sigh.

Why ? Do you think false sharing can happen between the threads
of a single core ?

On 3/23/2024 9:54 AM, Bonita Montero wrote:
> Am 23.03.2024 um 03:34 schrieb Chris M. Thomasson:
>> On 12/26/2023 9:06 PM, Bonita Montero wrote:
>>> Am 26.12.2023 um 21:24 schrieb Chris M. Thomasson:
>>>
>>>> So, are you familiar with Intel's early hyper threading problem?
>>>> There was false sharing between the ...
>>>
>>> False sharing can only happen between different cores.
>>
>> Sigh.
>
> Why ? Do you think false sharing can happen between the threads
> of a single core ?
>

Sigh again...

Am 23.03.2024 um 22:04 schrieb Chris M. Thomasson:
> On 3/23/2024 9:54 AM, Bonita Montero wrote:
>> Am 23.03.2024 um 03:34 schrieb Chris M. Thomasson:
>>> On 12/26/2023 9:06 PM, Bonita Montero wrote:
>>>> Am 26.12.2023 um 21:24 schrieb Chris M. Thomasson:
>>>>
>>>>> So, are you familiar with Intel's early hyper threading problem?
>>>>> There was false sharing between the ...
>>>>
>>>> False sharing can only happen between different cores.
>>>
>>> Sigh.
>>
>> Why ? Do you think false sharing can happen between the threads
>> of a single core ?
>>
>
> Sigh again...

On a single core CPU with two thread's there's never false sharing.