On Mon, 21 Aug 2023 19:50:32 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 21.08.2023 um 19:19 schrieb Muttley@dastardlyhq.com:
>> On Mon, 21 Aug 2023 11:00:15 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> I tried to combine the bitmap-approach with the heap-approach,
>>> having a bitmap that fits into the cache and which is a window
>>> inside the rows of numbers.
>>
>> If only erastothenes had had C++20 he too could have come up with some
>> hopeless complicated solution no one understood. Or maybe he would have
>> done some simple baby code in C...
>
>On my PC printing the all primes below 1E8 takes 0.827s with your
>code. With my code it takes about 0.36s.

I'm fairly sure I could speed it up if I could be bothered.

>Take this as a reference:

Sorry, can't be bothered to wade through that mess.

Am 21.08.2023 um 20:12 schrieb Muttley@dastardlyhq.com:

> On Mon, 21 Aug 2023 19:50:32 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> On my PC printing the all primes below 1E8 takes 0.827s with your
>> code. With my code it takes about 0.36s.

> I'm fairly sure I could speed it up if I could be bothered.

For sure not.

>> Take this as a reference:

> Sorry, can't be bothered to wade through that mess.

It's a mess because you're overburdened with reading the code.

On Mon, 21 Aug 2023 20:22:36 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 21.08.2023 um 20:12 schrieb Muttley@dastardlyhq.com:
>
>> On Mon, 21 Aug 2023 19:50:32 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>>> On my PC printing the all primes below 1E8 takes 0.827s with your
>>> code. With my code it takes about 0.36s.
>
>> I'm fairly sure I could speed it up if I could be bothered.
>
>For sure not.

And why's that then? Give us your insight.

>
>>> Take this as a reference:
>
>> Sorry, can't be bothered to wade through that mess.
>
>It's a mess because you're overburdened with reading the code.

A mess is burdensome.

Am 21.08.2023 um 21:01 schrieb Muttley@dastardlyhq.com:
> On Mon, 21 Aug 2023 20:22:36 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 21.08.2023 um 20:12 schrieb Muttley@dastardlyhq.com:
>>
>>> On Mon, 21 Aug 2023 19:50:32 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>
>>>> On my PC printing the all primes below 1E8 takes 0.827s with your
>>>> code. With my code it takes about 0.36s.
>>
>>> I'm fairly sure I could speed it up if I could be bothered.
>>
>> For sure not.
>
> And why's that then? ...

Because you can only write simple code.

>
>>
>>>> Take this as a reference:
>>
>>> Sorry, can't be bothered to wade through that mess.
>>
>> It's a mess because you're overburdened with reading the code.
>
> A mess is burdensome.
>
>

On Tuesday, 22 August 2023 at 06:27:51 UTC+3, Bonita Montero wrote:
> Am 21.08.2023 um 21:01 schrieb Mut...@dastardlyhq.com:
> > On Mon, 21 Aug 2023 20:22:36 +0200
> > Bonita Montero <Bonita....@gmail.com> wrote:
> >> Am 21.08.2023 um 20:12 schrieb Mut...@dastardlyhq.com:
> >>
> >>> On Mon, 21 Aug 2023 19:50:32 +0200
> >>> Bonita Montero <Bonita....@gmail.com> wrote:
> >>
> >>>> On my PC printing the all primes below 1E8 takes 0.827s with your
> >>>> code. With my code it takes about 0.36s.
> >>
> >>> I'm fairly sure I could speed it up if I could be bothered.
> >>
> >> For sure not.
> >
> > And why's that then? ...
>
> Because you can only write simple code.

Do not hijack nice thread of finding primes with your optimising
textual output.
Store primes however you want to and do not time text streaming
whatsoever. The problem was to find primes.

On Tue, 22 Aug 2023 05:27:36 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 21.08.2023 um 21:01 schrieb Muttley@dastardlyhq.com:
>> On Mon, 21 Aug 2023 20:22:36 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 21.08.2023 um 20:12 schrieb Muttley@dastardlyhq.com:
>>>
>>>> On Mon, 21 Aug 2023 19:50:32 +0200
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>
>>>>> On my PC printing the all primes below 1E8 takes 0.827s with your
>>>>> code. With my code it takes about 0.36s.
>>>
>>>> I'm fairly sure I could speed it up if I could be bothered.
>>>
>>> For sure not.
>>
>> And why's that then? ...
>
>Because you can only write simple code.

Simpler code = more efficient, less bugs and easier to maintain all other
things being equal. Complexity in code isn't a goal, its something to be
kept to a minimum. If you were even half the genius coder you seem to think
you are you'd already be aware of this.

Am 22.08.2023 um 08:25 schrieb Öö Tiib:
> On Tuesday, 22 August 2023 at 06:27:51 UTC+3, Bonita Montero wrote:
>> Am 21.08.2023 um 21:01 schrieb Mut...@dastardlyhq.com:
>>> On Mon, 21 Aug 2023 20:22:36 +0200
>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>> Am 21.08.2023 um 20:12 schrieb Mut...@dastardlyhq.com:
>>>>
>>>>> On Mon, 21 Aug 2023 19:50:32 +0200
>>>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>>
>>>>>> On my PC printing the all primes below 1E8 takes 0.827s with your
>>>>>> code. With my code it takes about 0.36s.
>>>>
>>>>> I'm fairly sure I could speed it up if I could be bothered.
>>>>
>>>> For sure not.
>>>
>>> And why's that then? ...
>>
>> Because you can only write simple code.
>
> Do not hijack nice thread of finding primes with your optimising
> textual output.

The speedup over cout << p << endl is massive, at least with MSVC;
I've measured that, you didn't.

Am 22.08.2023 um 08:56 schrieb Muttley@dastardlyhq.com:
> On Tue, 22 Aug 2023 05:27:36 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 21.08.2023 um 21:01 schrieb Muttley@dastardlyhq.com:
>>> On Mon, 21 Aug 2023 20:22:36 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 21.08.2023 um 20:12 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> On Mon, 21 Aug 2023 19:50:32 +0200
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>
>>>>>> On my PC printing the all primes below 1E8 takes 0.827s with your
>>>>>> code. With my code it takes about 0.36s.
>>>>
>>>>> I'm fairly sure I could speed it up if I could be bothered.
>>>>
>>>> For sure not.
>>>
>>> And why's that then? ...
>>
>> Because you can only write simple code.
>
> Simpler code = more efficient, ...

I've shown that my code is 2.3 times more efficient.
In most cases more complex code is faster.

> ... less bugs ...

Show me the bugs. I can manage such code, you don't. I did use
iterators as mich as possible to have iterator debugging to find
bugs if they would have happened.

> Complexity in code isn't a goal, ...

It's inevitable if the code should be more efficient.

> If you were even half the genius coder you seem to think
> you are you'd already be aware of this.

I'm not a genius, but I have extreme calm in my head that
I can program something like this.

Am 22.08.2023 um 11:27 schrieb Bonita Montero:

>> Simpler code = more efficient, ...

> I've shown that my code is 2.3 times more efficient.
> In most cases more complex code is faster.

On my secondary Linux PC (Threadripper 3990X) my code is 61% faster.

Am 22.08.2023 um 11:23 schrieb Bonita Montero:
> Am 22.08.2023 um 08:25 schrieb Öö Tiib:
>> On Tuesday, 22 August 2023 at 06:27:51 UTC+3, Bonita Montero wrote:
>>> Am 21.08.2023 um 21:01 schrieb Mut...@dastardlyhq.com:
>>>> On Mon, 21 Aug 2023 20:22:36 +0200
>>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>>> Am 21.08.2023 um 20:12 schrieb Mut...@dastardlyhq.com:
>>>>>
>>>>>> On Mon, 21 Aug 2023 19:50:32 +0200
>>>>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>>>
>>>>>>> On my PC printing the all primes below 1E8 takes 0.827s with your
>>>>>>> code. With my code it takes about 0.36s.
>>>>>
>>>>>> I'm fairly sure I could speed it up if I could be bothered.
>>>>>
>>>>> For sure not.
>>>>
>>>> And why's that then? ...
>>>
>>> Because you can only write simple code.
>>
>> Do not hijack nice thread of finding primes with your optimising
>> textual output.
>
> The speedup over cout << p << endl is massive, at least with MSVC;
> I've measured that, you didn't.
>

C:\Users\Boni\Documents\Source\bitmapSieve>bg --times --affinity 1
--high x64\Release\bitmapSieve 100000000
real 9675.36ms
user 2875.00ms
sys 6718.75ms
cycles 43.369.468.839

C:\Users\Boni\Documents\Source\bitmapSieve>bg --times --affinity 1
--high x64\Release\bitmapSieve 100000000
real 370.28ms
user 281.25ms
sys 62.50ms
cycles 1.653.010.785

26 times faster on Windows (Zen4):

boni@EliteDesk:~$ g++ -march=native -std=c++20 -O2 bitmapSieve.cpp
boni@EliteDesk:~$ time ./a.out 100000000

real 0m17,552s
user 0m5,406s
sys 0m12,113s
boni@EliteDesk:~$ g++ -march=native -std=c++20 -O2 bitmapSieve.cpp
boni@EliteDesk:~$ time ./a.out 100000000

real 0m1,808s
user 0m1,680s
sys 0m0,085s

9.7 times faster on Linux (Skylake).

On Tuesday, 22 August 2023 at 12:23:53 UTC+3, Bonita Montero wrote:
> Am 22.08.2023 um 08:25 schrieb Öö Tiib:
> > On Tuesday, 22 August 2023 at 06:27:51 UTC+3, Bonita Montero wrote:
> >> Am 21.08.2023 um 21:01 schrieb Mut...@dastardlyhq.com:
> >>> On Mon, 21 Aug 2023 20:22:36 +0200
> >>> Bonita Montero <Bonita....@gmail.com> wrote:
> >>>> Am 21.08.2023 um 20:12 schrieb Mut...@dastardlyhq.com:
> >>>>
> >>>>> On Mon, 21 Aug 2023 19:50:32 +0200
> >>>>> Bonita Montero <Bonita....@gmail.com> wrote:
> >>>>
> >>>>>> On my PC printing the all primes below 1E8 takes 0.827s with your
> >>>>>> code. With my code it takes about 0.36s.
> >>>>
> >>>>> I'm fairly sure I could speed it up if I could be bothered.
> >>>>
> >>>> For sure not.
> >>>
> >>> And why's that then? ...
> >>
> >> Because you can only write simple code.
> >
> > Do not hijack nice thread of finding primes with your optimising
> > textual output.
>
> The speedup over cout << p << endl is massive, at least with MSVC;
> I've measured that, you didn't.
>
We already know that you are especially daff but I repeat: it does not
matter to efficiency of finding primes. Open other thread if you want
to discuss text output optimisations not finding primes.

Am 22.08.2023 um 14:15 schrieb Öö Tiib:

> We already know that you are especially daff but I repeat: it does not
> matter to efficiency of finding primes. Open other thread if you want
> to discuss text output optimisations not finding primes.

I'd optimized both inside the _same_ program. You and Muttley
think that simple coding is enough, I've shown multiple times
that I can do it much better.
Unfortunately printf() and cout << are by far not that fast
as they could be, even if the output is redirected to a file.

On Tue, 22 Aug 2023 11:27:29 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.08.2023 um 08:56 schrieb Muttley@dastardlyhq.com:
>> Simpler code = more efficient, ...
>
>I've shown that my code is 2.3 times more efficient.
>In most cases more complex code is faster.

No, not in most cases as endless bloated frameworks with their huge memory
and CPU requirements demonstrate on a daily basis to me. There's a big
difference between code thats fully featured and code thats needlessly
compicated because the developer(s) were unable to think clearly or see the
obvious solution.

>> Complexity in code isn't a goal, ...
>
>It's inevitable if the code should be more efficient.

Bollocks.

>> If you were even half the genius coder you seem to think
>> you are you'd already be aware of this.
>
>I'm not a genius, but I have extreme calm in my head that
>I can program something like this.

Oh right, you're a Zen dev are you? :) Whatever you say!

Am 22.08.2023 um 16:13 schrieb Muttley@dastardlyhq.com:

> No, not in most cases as endless bloated frameworks ...

I'm using standard C++ and no bloating framworks. The memory-con-
sumtion is eight times less than with your code because I store
each bool as a bit. Your code has bloat, not mine in that sense.

> There's a big difference between code thats fully featured and code
> thats needlessly compicated because the developer(s) were unable to
> think clearly or see the obvious solution.

It overburdens you, not every developer.

On Tue, 22 Aug 2023 16:17:21 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.08.2023 um 16:13 schrieb Muttley@dastardlyhq.com:
>
>> No, not in most cases as endless bloated frameworks ...
>
>I'm using standard C++ and no bloating framworks. The memory-con-
>sumtion is eight times less than with your code because I store
>each bool as a bit. Your code has bloat, not mine in that sense.

Accessing bits in a word is normally slower than accessing the whole word
on most CPUs. However due to the huge memory this sort of algo can use this
access time is probably more than offset by paging delays.

Using bits doesn't make you a genius.

>> There's a big difference between code thats fully featured and code
>> thats needlessly compicated because the developer(s) were unable to
>> think clearly or see the obvious solution.
>
>It overburdens you, not every developer.

Whoosh...

Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com:

> Accessing bits in a word is normally slower than accessing the whole word
> on most CPUs. ...

I have shown that when the amount of data is large enough, access time
has the greatest weight. Furthermore, most of the calculations for the
bits within the byte in other arithmetic units take place in parallel.
If I choose the data set small enough, your algorithm is faster, but
then performance doesn't count anyway.

> Using bits doesn't make you a genius.

Did I claim that for myself ?

On Tue, 22 Aug 2023 16:48:45 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com:
>
>> Accessing bits in a word is normally slower than accessing the whole word
>> on most CPUs. ...
>
>I have shown that when the amount of data is large enough, access time
>has the greatest weight. Furthermore, most of the calculations for the
>bits within the byte in other arithmetic units take place in parallel.

CPUs only have 1 data bus no matter how many cores they have so the optimum
number of threads for this sort of algorithm is very much a suck it and
see approach depending on hardware and on a single core CPU your approach
would suck badly.

>> Using bits doesn't make you a genius.
>
>Did I claim that for myself ?

By denigrating anyone who doesn't like your coding style the implication is
there for all to see. You think yourself a better programmer than anyone
else on this group.

Am 22.08.2023 um 16:57 schrieb Muttley@dastardlyhq.com:

> CPUs only have 1 data bus no matter how many cores they have so the optimum
> number of threads for this sort of algorithm is very much a suck it and
> see approach depending on hardware and on a single core CPU your approach
> would suck badly.

Data is fetched in quantities of a cacheline size. And with my code
an eight of that quantity is fetched from memory. That's the reason
while my code is much faster than yours.

> By denigrating anyone who doesn't like your coding style the implication
> is there for all to see. You think yourself a better programmer than anyone
> else on this group.

That's obvious. I'm programming C++ since 1992 and I program at all
since I'm 10.

Muttley@dastardlyhq.com writes:
>On Tue, 22 Aug 2023 16:48:45 +0200
>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com:
>>
>>> Accessing bits in a word is normally slower than accessing the whole word
>>> on most CPUs. ...
>>
>>I have shown that when the amount of data is large enough, access time
>>has the greatest weight. Furthermore, most of the calculations for the
>>bits within the byte in other arithmetic units take place in parallel.
>
>CPUs only have 1 data bus no matter how many cores

That is not an accurate statement for any processor built in
the last decade or more. Most of them use a mesh, crossbar or ring structure, not
a shared bus structure to interface the cores to the memory subsystem on the
chip. Most have multiple DRAM controllers (from one at
the real low end to twenty at the high end) and stripe
the DRAM address space across the controllers. All CPUs have private
L1 and L2 caches, and large shared LLC caches (LLC is distributed
across mesh elements) whic signifinctly reduce DRAM controller accesses.

Likewise, on the I/O side, there are multiple bridges from the
mesh/ring structures into the I/O side (e.g. one host bridge per
PCI Express root port, one or more for on-chip accelerators, etc).

On Tue, 22 Aug 2023 17:00:42 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.08.2023 um 16:57 schrieb Muttley@dastardlyhq.com:
>
>> CPUs only have 1 data bus no matter how many cores they have so the optimum
>> number of threads for this sort of algorithm is very much a suck it and
>> see approach depending on hardware and on a single core CPU your approach
>> would suck badly.
>
>Data is fetched in quantities of a cacheline size. And with my code

If it has to be paged from disk in the first place the size of the cache is a
total irrelevance as far as time taken is concerned.

>an eight of that quantity is fetched from memory. That's the reason
>while my code is much faster than yours.

As I said, it depends on the hardware. Try both on a Z80 and see what happens.

>> By denigrating anyone who doesn't like your coding style the implication
>> is there for all to see. You think yourself a better programmer than anyone
>> else on this group.
>
>That's obvious.

Thanks for proving you're as arrogant as I thought.

>I'm programming C++ since 1992 and I program at all
>since I'm 10.

If you want to get into a pissing contest about who's been programming longer
I suspect a lot of people on this group have been doing it a lot longer than
you.

On Tue, 22 Aug 2023 15:49:09 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Tue, 22 Aug 2023 16:48:45 +0200
>>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com:
>>>
>>>> Accessing bits in a word is normally slower than accessing the whole word
>>>> on most CPUs. ...
>>>
>>>I have shown that when the amount of data is large enough, access time
>>>has the greatest weight. Furthermore, most of the calculations for the
>>>bits within the byte in other arithmetic units take place in parallel.
>>
>>CPUs only have 1 data bus no matter how many cores
>
>That is not an accurate statement for any processor built in
>the last decade or more. Most of them use a mesh, crossbar or ring

Given millions of 8 and 16 bit processors are still designed and produced for
embedded systems that statement is nonsense and ARM based systems can use
whatever parts they want in the CPU.

>structure, not
>a shared bus structure to interface the cores to the memory subsystem on the
>chip. Most have multiple DRAM controllers (from one at
>the real low end to twenty at the high end) and stripe
>the DRAM address space across the controllers. All CPUs have private
>L1 and L2 caches, and large shared LLC caches (LLC is distributed
>across mesh elements) whic signifinctly reduce DRAM controller accesses.
>
>Likewise, on the I/O side, there are multiple bridges from the
>mesh/ring structures into the I/O side (e.g. one host bridge per
>PCI Express root port, one or more for on-chip accelerators, etc).

Thats nice, but CPU > x86.

Am 22.08.2023 um 19:56 schrieb Muttley@dastardlyhq.com:

> If it has to be paged from disk in the first place the size of the
> cache is a total irrelevance as far as time taken is concerned.

No one uses software that actually pages to disk.
Paging is just for that the softwar doesn't crash.

> As I said, it depends on the hardware. Try both on a Z80 and see what happens.

Your code wasn't intended for a Z-80.

> Thanks for proving you're as arrogant as I thought.

When you're good in sth. you often appear arrogant.

> If you want to get into a pissing contest about who's been programming
> longer I suspect a lot of people on this group have been doing it a lot
> longer than you.

Maybe, but at this level.

On Tue, 22 Aug 2023 20:13:17 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.08.2023 um 19:56 schrieb Muttley@dastardlyhq.com:
>
>> If it has to be paged from disk in the first place the size of the
>> cache is a total irrelevance as far as time taken is concerned.
>
>No one uses software that actually pages to disk.
>Paging is just for that the softwar doesn't crash.

I suggest you go and google how operating system virtual memory works.

>> As I said, it depends on the hardware. Try both on a Z80 and see what
>happens.
>
>Your code wasn't intended for a Z-80.

What was it intended for then given it was written in basic C?

>> Thanks for proving you're as arrogant as I thought.
>
>When you're good in sth. you often appear arrogant.

"sth"?

>> If you want to get into a pissing contest about who's been programming
>> longer I suspect a lot of people on this group have been doing it a lot
>> longer than you.
>
>Maybe, but at this level.

At your level? Absolutely.

Muttley@dastardlyhq.com writes:
>On Tue, 22 Aug 2023 15:49:09 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>On Tue, 22 Aug 2023 16:48:45 +0200
>>>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> Accessing bits in a word is normally slower than accessing the whole word
>>>>> on most CPUs. ...
>>>>
>>>>I have shown that when the amount of data is large enough, access time
>>>>has the greatest weight. Furthermore, most of the calculations for the
>>>>bits within the byte in other arithmetic units take place in parallel.
>>>
>>>CPUs only have 1 data bus no matter how many cores
>>
>>That is not an accurate statement for any processor built in
>>the last decade or more. Most of them use a mesh, crossbar or ring
>
>Given millions of 8 and 16 bit processors are still designed and produced for
>embedded systems that statement is nonsense and ARM based systems can use
>whatever parts they want in the CPU.

ARM based multicore systems generally use CMN-400/500/600/700 IP (from ARM)
as the processor interconnect.

https://developer.arm.com/Processors/CoreLink%20CMN-600

And all those 8 and 16-bit processors are single core, so your
statement above, which references "no matter how many cores"
doesn't apply to them.

>
>>structure, not
>>a shared bus structure to interface the cores to the memory subsystem on the
>>chip. Most have multiple DRAM controllers (from one at
>>the real low end to twenty at the high end) and stripe
>>the DRAM address space across the controllers. All CPUs have private
>>L1 and L2 caches, and large shared LLC caches (LLC is distributed
>>across mesh elements) whic signifinctly reduce DRAM controller accesses.
>>
>>Likewise, on the I/O side, there are multiple bridges from the
>>mesh/ring structures into the I/O side (e.g. one host bridge per
>>PCI Express root port, one or more for on-chip accelerators, etc).
>
>Thats nice, but CPU > x86.

What does that mean? Every major multicore processor currently
shipping (including Apple M7+) operate as described above.
Including most mid-range and high-end application specific
system-on-chips (SoC), including those using the ARM
architecture.

The proceedings from https://hotchips.org/ over the last two
decades describe the state of the art.

Am 22.08.2023 um 20:18 schrieb Muttley@dastardlyhq.com:
> On Tue, 22 Aug 2023 20:13:17 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.08.2023 um 19:56 schrieb Muttley@dastardlyhq.com:
>>
>>> If it has to be paged from disk in the first place the size of the
>>> cache is a total irrelevance as far as time taken is concerned.
>>
>> No one uses software that actually pages to disk.
>> Paging is just for that the softwar doesn't crash.
>
> I suggest you go and google how operating system virtual memory works.

Swapping is for stability and not for performance.
No one considers running applications actually swapping.

> What was it intended for then given it was written in basic C?

You didn't write that on a Z-80.