Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com:
>> On Wed, 23 Aug 2023 16:47:46 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com:
>>>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk
>>>> partitions then it will do the equivalent of swapping if it needs to.
>>>
>>> The Oracle Data Warehousing Guide says that the performance
>>> advantage of raw partitions is between three and five percent.
>>> And you lose much comfort features like shnapshots. So no one
>>> actually uses raw partitions.
>>
>> Oh right. You're an Oracle expert too now? :)
>
>I have a OCP-DBA for Oracle 8i and I read that 20 years ago.
>I checked that in the current DWH-guide and they reverted
>that statement to five to ten percent.
>
>>> And this feature has nothing to do with how you dimension your
>>> buffer pool or your heaps.
>
>> Its a type of paging.
>
>Paging is synchronous, i.e. the thread which pages is stopped until
>the page is fetched.

Actually, sometimes the operating system will anticipate a future
page fault and preload the page. Particularly on POSIX systems
that support the madvise(2) or posix_madvise(2) system call(s).

On Wed, 23 Aug 2023 20:05:14 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.08.2023 um 19:49 schrieb Muttley@dastardlyhq.com:
>
>> You must be a very insecure person constantly
>> putting others down to make yourself feel better.
>
>No, I just feel uncomfortable if people produce such images.

What images?

>You're simply lying.

About what? Thats how you come across - an insecure loser who thinks he's
one of the best C++ programmers on the planet.

Am 24.08.2023 um 19:18 schrieb Muttley@dastardlyhq.com:
> On Wed, 23 Aug 2023 20:05:14 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 23.08.2023 um 19:49 schrieb Muttley@dastardlyhq.com:
>>
>>> You must be a very insecure person constantly
>>> putting others down to make yourself feel better.
>>
>> No, I just feel uncomfortable if people produce such images.
>
> What images?

You try to make other believe things which aren't true.

>> You're simply lying.
>
> About what? Thats how you come across - an insecure loser who thinks he's
> one of the best C++ programmers on the planet.
>

I'm neither insecure, nor a loser.

On Wed, 23 Aug 2023 20:09:01 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com:
>> On Wed, 23 Aug 2023 16:47:46 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com:
>>>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk
>>>> partitions then it will do the equivalent of swapping if it needs to.
>>>
>>> The Oracle Data Warehousing Guide says that the performance
>>> advantage of raw partitions is between three and five percent.
>>> And you lose much comfort features like shnapshots. So no one
>>> actually uses raw partitions.
>>
>> Oh right. You're an Oracle expert too now? :)
>
>I have a OCP-DBA for Oracle 8i and I read that 20 years ago.

Does that on your wall alongside your Microsoft Certified Muppet certificates?

>> Its a type of paging.
>
>Paging is synchronous, i.e. the thread which pages is stopped until
>the page is fetched. All modern database engines use asynchronous
>I/O, thereby issuing multiple requests and answering the responses
>often in a totally different order.

Until the data can be loaded from disk a query - even a highly parallelised
one - will be partially or fully stalled however the I/O is done.

>And it's also not paging because this is explicitly issued by the
>database server, whereas real paging is a transparent memory access
>which isn't noticed by the application.

You think programs using SQL are aware of the database fetching and
saving to disk?

On Wed, 23 Aug 2023 20:24:55 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.08.2023 um 20:20 schrieb Chris M. Thomasson:
>> Pot Kettle? Bonita, you have a lot of experience wrt verbal assaults,
>> right?
>
>Muttley is just annoying. If I show a solution to a problem and think
>it is technically elegant, he somehow wants to explain it away because

Your idea of elegance is completely orthogonal to most peoples.

>The guy is disturbed.

Irony day again?

>And because he then compares himself to me at that point, he produces
>such images as saying that he was involved in some Java project,

Actually I specifically said I WASNT involved except how Java slowed down
the server we were sharing with the java team. I realise English isn't your
1st language but do try to read properly.

>although based on other statements about Java you can say that
>he only has clichéd views of it.

Views gained from real world experience.

Am 24.08.2023 um 19:22 schrieb Muttley@dastardlyhq.com:

>> Paging is synchronous, i.e. the thread which pages is stopped until
>> the page is fetched. All modern database engines use asynchronous
>> I/O, thereby issuing multiple requests and answering the responses
>> often in a totally different order.

> Until the data can be loaded from disk a query - even a highly parallelised
> one - will be partially or fully stalled however the I/O is done.

I wanted to explain why this isn't paging.
You don't underdtand the difference.

>> And it's also not paging because this is explicitly issued by the
>> database server, whereas real paging is a transparent memory access
>> which isn't noticed by the application.

> You think programs using SQL are aware of the database fetching and
> saving to disk?

What does this have to do with the discussion of
paging vs. asynchronous I/O through a database server?

Am 24.08.2023 um 19:25 schrieb Muttley@dastardlyhq.com:
> On Wed, 23 Aug 2023 20:24:55 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 23.08.2023 um 20:20 schrieb Chris M. Thomasson:
>>> Pot Kettle? Bonita, you have a lot of experience wrt verbal assaults,
>>> right?
>>
>> Muttley is just annoying. If I show a solution to a problem and think
>> it is technically elegant, he somehow wants to explain it away because
>
> Your idea of elegance is completely orthogonal to most peoples.

People who know C++ very well will appreciate my work.

> Actually I specifically said I WASNT involved except how Java slowed down
> the server we were sharing with the java team. I realise English isn't your
> 1st language but do try to read properly.

Now you row back.

>> although based on other statements about Java you can say that
>> he only has clichéd views of it.

> Views gained from real world experience.

You don't have any experience with that.
You're at the level of very simplex code.

On Thu, 24 Aug 2023 19:27:25 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 24.08.2023 um 19:22 schrieb Muttley@dastardlyhq.com:
>
>>> Paging is synchronous, i.e. the thread which pages is stopped until
>>> the page is fetched. All modern database engines use asynchronous
>>> I/O, thereby issuing multiple requests and answering the responses
>>> often in a totally different order.
>
>> Until the data can be loaded from disk a query - even a highly parallelised
>> one - will be partially or fully stalled however the I/O is done.
>
>I wanted to explain why this isn't paging.
>You don't underdtand the difference.

They're analogous, not identical , but close enough. Both involve loading
data into memory and saving it out to disk before the operation can proceed
and in the case of ACID DBMSs the transaction data MUST be written to disk
before the operation can complete.

But I'm sure you know all this, right?

>>> And it's also not paging because this is explicitly issued by the
>>> database server, whereas real paging is a transparent memory access
>>> which isn't noticed by the application.
>
>> You think programs using SQL are aware of the database fetching and
>> saving to disk?
>
>What does this have to do with the discussion of
>paging vs. asynchronous I/O through a database server?

FFS , are you even aware of what you wrote?

On Thu, 24 Aug 2023 19:29:11 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 24.08.2023 um 19:25 schrieb Muttley@dastardlyhq.com:
>> Your idea of elegance is completely orthogonal to most peoples.
>
>People who know C++ very well will appreciate my work.

Obviously none of them are on this group.

>> Actually I specifically said I WASNT involved except how Java slowed down
>> the server we were sharing with the java team. I realise English isn't your
>> 1st language but do try to read properly.
>
>Now you row back.

Go back and read my post.

>>> although based on other statements about Java you can say that
>>> he only has clichéd views of it.
>
>> Views gained from real world experience.
>
>You don't have any experience with that.
>You're at the level of very simplex code.

Some of my code is currently orbiting Earth and some more is in a missile
system. But yeah, all simple stuff.

You never did tell us what job you did - so what area do you work in?

Am 24.08.2023 um 19:40 schrieb Muttley@dastardlyhq.com:
> On Thu, 24 Aug 2023 19:29:11 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 24.08.2023 um 19:25 schrieb Muttley@dastardlyhq.com:
>>> Your idea of elegance is completely orthogonal to most peoples.
>>
>> People who know C++ very well will appreciate my work.
>
> Obviously none of them are on this group.

There aren't people who program like that, but in contrast
to you most readers here understand that code.

> You never did tell us what job you did - so what area do you work in?

I'm programming C++ / (C#) software for high frequency trading.

Am 24.08.2023 um 19:37 schrieb Muttley@dastardlyhq.com:
> On Thu, 24 Aug 2023 19:27:25 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 24.08.2023 um 19:22 schrieb Muttley@dastardlyhq.com:
>>
>>>> Paging is synchronous, i.e. the thread which pages is stopped until
>>>> the page is fetched. All modern database engines use asynchronous
>>>> I/O, thereby issuing multiple requests and answering the responses
>>>> often in a totally different order.
>>
>>> Until the data can be loaded from disk a query - even a highly parallelised
>>> one - will be partially or fully stalled however the I/O is done.
>>
>> I wanted to explain why this isn't paging.
>> You don't underdtand the difference.
>
> They're analogous, not identical , but close enough. Both involve loading
> data into memory and saving it out to disk before the operation can proceed
> and in the case of ACID DBMSs the transaction data MUST be written to disk
> before the operation can complete.

But that is a very superficial comparison.
And there are no transactions in paging either.

On 8/23/2023 11:51 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com:
>>> On Wed, 23 Aug 2023 16:47:46 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com:
>>>>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk
>>>>> partitions then it will do the equivalent of swapping if it needs to.
>>>>
>>>> The Oracle Data Warehousing Guide says that the performance
>>>> advantage of raw partitions is between three and five percent.
>>>> And you lose much comfort features like shnapshots. So no one
>>>> actually uses raw partitions.
>>>
>>> Oh right. You're an Oracle expert too now? :)
>>
>> I have a OCP-DBA for Oracle 8i and I read that 20 years ago.
>> I checked that in the current DWH-guide and they reverted
>> that statement to five to ten percent.
>>
>>>> And this feature has nothing to do with how you dimension your
>>>> buffer pool or your heaps.
>>
>>> Its a type of paging.
>>
>> Paging is synchronous, i.e. the thread which pages is stopped until
>> the page is fetched.
>
> Actually, sometimes the operating system will anticipate a future
> page fault and preload the page. Particularly on POSIX systems
> that support the madvise(2) or posix_madvise(2) system call(s).

Yup. Cacheline prefetch can be damn good as well, in certain scenarios...

On Thu, 24 Aug 2023 19:49:43 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 24.08.2023 um 19:40 schrieb Muttley@dastardlyhq.com:
>> On Thu, 24 Aug 2023 19:29:11 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 24.08.2023 um 19:25 schrieb Muttley@dastardlyhq.com:
>>>> Your idea of elegance is completely orthogonal to most peoples.
>>>
>>> People who know C++ very well will appreciate my work.
>>
>> Obviously none of them are on this group.
>
>There aren't people who program like that, but in contrast
>to you most readers here understand that code.

Its not a case of not understanding it, its a case of I can't be arsed going
through it to figure it out. If you want to make a coding point KISS.

>> You never did tell us what job you did - so what area do you work in?
>
>I'm programming C++ / (C#) software for high frequency trading.

Home trader then.

On Thu, 24 Aug 2023 19:52:10 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 24.08.2023 um 19:37 schrieb Muttley@dastardlyhq.com:
>> They're analogous, not identical , but close enough. Both involve loading
>> data into memory and saving it out to disk before the operation can proceed
>> and in the case of ACID DBMSs the transaction data MUST be written to disk
>> before the operation can complete.
>
>But that is a very superficial comparison.
>And there are no transactions in paging either.

*sigh*

Forget it.

Am 25.08.2023 um 18:07 schrieb Muttley@dastardlyhq.com:

> Its not a case of not understanding it, ...

Comment it and show that you understand it.

>>> You never did tell us what job you did - so what area do you work in?

>> I'm programming C++ / (C#) software for high frequency trading.

> Home trader then.

No, I'm no trading myself.

On Fri, 25 Aug 2023 18:10:35 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.08.2023 um 18:07 schrieb Muttley@dastardlyhq.com:
>
>> Its not a case of not understanding it, ...
>
>Comment it and show that you understand it.

Sorry pal, unlike you I have a life and have much more interesting things to
do than go through some dogs dinner code you posted by some random guy on
a newsgroup.

>>> I'm programming C++ / (C#) software for high frequency trading.
>
>> Home trader then.
>
>No, I'm no trading myself.

If you work for a fintec then I pity the devs who will have to maintain your
code in the future. More than likely they'll toss it and start again.

Am 25.08.2023 um 18:15 schrieb Muttley@dastardlyhq.com:
> On Fri, 25 Aug 2023 18:10:35 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 25.08.2023 um 18:07 schrieb Muttley@dastardlyhq.com:
>>
>>> Its not a case of not understanding it, ...
>>
>> Comment it and show that you understand it.
>
> Sorry pal, ...

That's what I expected.

>
>>>> I'm programming C++ / (C#) software for high frequency trading.
>>
>>> Home trader then.
>>
>> No, I'm no trading myself.
>
> If you work for a fintec then I pity the devs who will have to maintain
> your code in the future. More than likely they'll toss it and start again.

The company I work for has more skilled staff like you.

On Fri, 25 Aug 2023 18:18:09 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.08.2023 um 18:15 schrieb Muttley@dastardlyhq.com:
>> On Fri, 25 Aug 2023 18:10:35 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 25.08.2023 um 18:07 schrieb Muttley@dastardlyhq.com:
>>>
>>>> Its not a case of not understanding it, ...
>>>
>>> Comment it and show that you understand it.
>>
>> Sorry pal, ...
>
>That's what I expected.

The arrogance that you expect people to have to figure out your code then
comment on it is quite breathtaking.

>> If you work for a fintec then I pity the devs who will have to maintain
>> your code in the future. More than likely they'll toss it and start again.
>
>The company I work for has more skilled staff like you.

Ah, you think you're so much better than everyone else there. What a surprise.

Am 26.08.2023 um 10:03 schrieb Muttley@dastardlyhq.com:

>>> If you work for a fintec then I pity the devs who will have to maintain
>>> your code in the future. More than likely they'll toss it and start again.

>> The company I work for has more skilled staff like you.

> Ah, you think you're so much better than everyone else there. What a surprise.

Stick with your C code and continue to ask beginner's C++ questions.

On Sat, 26 Aug 2023 10:16:48 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 26.08.2023 um 10:03 schrieb Muttley@dastardlyhq.com:
>
>>>> If you work for a fintec then I pity the devs who will have to maintain
>>>> your code in the future. More than likely they'll toss it and start again.
>
>>> The company I work for has more skilled staff like you.
>
>> Ah, you think you're so much better than everyone else there. What a
>surprise.
>
>Stick with your C code and continue to ask beginner's C++ questions.

Do carry on with your pompous assery, I'll get some popcorn :)

On 8/23/2023 11:37 AM, Daniel wrote:
> On Wednesday, August 23, 2023 at 2:21:18 PM UTC-4, Chris M. Thomasson wrote:
>>>
>> Bonita, you have a lot of experience wrt verbal assaults, right?
>
> How would you know? You don't seem to have _any_ experience of it
> yourself :-) Alf neither.

:^)

On Thursday, 17 August 2023 at 05:26:37 UTC+3, Tim Rentsch wrote:
>
> I suggest computing all 32 bit primes for the benchmark
> tests. Shouldn't take too long.
>
Took 14 minutes to find those 203280221 primes single threaded
on i7-8550U.

Öö Tiib <ootiib@hot.ee> writes:

> On Thursday, 17 August 2023 at 05:26:37 UTC+3, Tim Rentsch wrote:
>>
>> I suggest computing all 32 bit primes for the benchmark
>> tests. Shouldn't take too long.
>>
> Took 14 minutes to find those 203280221 primes single threaded
> on i7-8550U.

What do you mean by find? Do you include printing them out because that
will depend rather more on the OS.

I wanted to try a newer algorithm, so I coded up a rather naive version
of Atkin & Bernstein's sieve in C. It needs some tidying and I imagine
a bit can be shaved off the time.

It can generate a bitmap of the 203280221 primes and then count them in
about 40 seconds on an i5-8265U CPU @ 1.60GHz (single threaded). It
takes about 55 seconds to write them (in decimal) to a file. The result
is over 2GB:

$ wc primes
203280221 203280221 2178719347 primes

--
Ben.

I optimized the code somewhat further:

#include <iostream>
#include <vector>
#include <charconv>
#include <string_view>
#include <algorithm>
#include <fstream>
#include <cctype>
#include <cstring>
#include <bit>
#include "ndi.h"

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

using namespace std;

int main( int argc, char **argv )
{ constexpr size_t BUF_SIZE = 0x100000;
try
{
size_t end;
if( argc < 2 )
return EXIT_FAILURE;
char const *sizeStr = argv[1];
bool hex = sizeStr[0] == '0' && (sizeStr[1] == 'x' || sizeStr[1] == 'X');
sizeStr += 2 * hex;
if( from_chars_result fcr = from_chars( sizeStr, sizeStr + strlen(
sizeStr ), end, !hex ? 10 : 16 ); (bool)fcr.ec || *fcr.ptr )
return EXIT_FAILURE;
if( size_t e = end; ++end + 7 < e )
throw bad_alloc();
using bit_vec = vector<uint8_t>;
using bit_it = bit_vec::iterator;
bit_vec sieve( (end + 7) / 8, -1 );
ofstream ofs;
using ndi_vec = vector<ndi<char>>;
using ndi_vec_it = ndi_vec::iterator;
constexpr size_t AHEAD = 32;
ndi_vec printBuf;
ndi_vec_it bufBegin, bufEnd, bufFlush;
if( argc < 3 || *argv[2] )
{
ofs.exceptions( ofstream::failbit | ofstream::badbit );
ofs.open( argc >= 3 ? argv[2] : "primes.txt", ofstream::trunc );
printBuf.resize( BUF_SIZE + AHEAD - 1 );
bufBegin = printBuf.begin();
bufEnd = bufBegin;
bufFlush = bufBegin + BUF_SIZE;
}
auto print = [&]() { ofs << string_view( &*to_address( bufBegin ),
&*to_address( bufEnd ) ); };
for( size_t p = 2; p != end; )
{
bit_it pSieve = sieve.begin();
for( size_t m = p; (m += p) < end; )
pSieve[m / 8] &= ~(1u << m % 8);
pSieve += ++p / 8;
for( uint8_t m = 1u << p % 8, mNew; ; ++p )
{
if( p == end ) [[unlikely]]
goto brk;
if( *pSieve & m ) [[unlikely]]
break;
mNew = rotl( m, 1 );
pSieve += mNew < m;
m = mNew;
}
if( !ofs.is_open() )
continue;
auto [ptr, ec] = to_chars( &*bufEnd, &*to_address( bufEnd + (AHEAD -
1) ), p );
if( (bool)ec ) [[unlikely]]
throw system_error( (int)ec, generic_category(), "converson failed" );
bufEnd = ptr - &*bufBegin + bufBegin; // NOP
*bufEnd++ = '\n';
if( bufEnd >= bufFlush )
print(),
bufEnd = bufBegin;
}
brk:
print();
return EXIT_SUCCESS;
}
catch( bad_alloc const & )
{
cout << "out of memory" << endl;
}
catch( ios_base::failure const & )
{
cout << "I/O error" << endl;
}
catch( system_error const &se )
{
cout << se.what() << endl;
}
}

On Monday, 28 August 2023 at 02:50:05 UTC+3, Ben Bacarisse wrote:
> Öö Tiib <oot...@hot.ee> writes:
>
> > On Thursday, 17 August 2023 at 05:26:37 UTC+3, Tim Rentsch wrote:
> >>
> >> I suggest computing all 32 bit primes for the benchmark
> >> tests. Shouldn't take too long.
> >>
> > Took 14 minutes to find those 203280221 primes single threaded
> > on i7-8550U.
> What do you mean by find? Do you include printing them out because that
> will depend rather more on the OS.
>
I did try to invent a sieve algorithm this weekend, it worked, but bit
sluggish, so I posted it.
I did not measure printing or storing to file, only sieving and counting
(to test that there are 203280221).

> I wanted to try a newer algorithm, so I coded up a rather naive version
> of Atkin & Bernstein's sieve in C. It needs some tidying and I imagine
> a bit can be shaved off the time.
>
> It can generate a bitmap of the 203280221 primes and then count them in
> about 40 seconds on an i5-8265U CPU @ 1.60GHz (single threaded). It
> takes about 55 seconds to write them (in decimal) to a file. The result
> is over 2GB:
>
> $ wc primes
> 203280221 203280221 2178719347 primes
>
Thanks, so I apparently need to optimize my algorithm at least 30 times
faster for it to be worth anything. Maybe next weekend.