Bug in TReadBufStream and proposed fix

[glorfin]

Seekable streams are a contradiction in terms.... As explained.

I agree that TStream is not the best name for this class of objects. However it exists and for compatibility we have to keep it.
Unfortunately, inappropriate terminology is not uncommon in science, not only computer science. "Action potential" in physiology, for example, which in fact is a process consisting of several ion currents, resulting in fast changes of membrane potential. But everybody knows what it is, and this process is called "action potential" just by tradition.

Same is with TStream. Yes, this is not the best name for these objects, but it is there. Objects themselves are nevertheless convenient for use and we (well, at least I) are not going to neglect them only because of inappropriate name.

And, after all. ("Stream" in English) <> ("TStream" in Pascal).

[SymbolicFrank]

I read a discussion somewhere (I think on this forum) about the efficiency of only paging in memory on-demand. So, if you start an executable, there is no memory paged in at all. Every action, including the loading of the executable itself will generate a whole lot of page faults, which in turn will map a single page (4kB) each.

At the time this mechanism was designed (80386, or half-way in an 80286), memory was scarce, and the designers envisioned lots of processes that all shared that.

Today we would (for example) use the larger page size of 2MB per page, and give each process a few in advance (code, data, stack). That is much more efficient. (The page tables are huge and all the management takes a lot of CPU time.)

Streams are like that: they were a good interface, first for serial devices and later for files, but we have much more resources nowadays.

[ASerge]

No, it does not. Because when you say that you read with the help of TBufStream, you actually read with TFilestream. Here is part of your code:

Thank you. My mistake . After correcting the test shows a good performance for BufStream

Creating test file with 1000000 bytes... Done.
Reading byte by byte using a TMemorystream: 0.017 sec
Reading byte by byte using a TFileStream: 0.944 sec
Reading byte by byte using a TReadBufStream: 0.018 sec
Reading byte by byte using a TFileMapRead: 0.013 sec

[SymbolicFrank]

Btw, ironically enough, most current CPUs spend the vast amount of their time either sleeping or waiting on the very slow main memory. Your average i7 spends on average 90,000 clock cycles waiting for a single byte to arrive from main memory. In that time, it could execute up to 720,000 instructions...

Then again, it is very unlikely it could write the results of those instructions back in any meaningful way, and accessing more than one byte sequentially is much faster.

On the other hand, your working set for all processes/threads combined, spread out over all processors in the system is just 32kB, if you use shared memory...

And the most important thing you want in cache memory is your page tables! Which have become huge!


A double page fault requires reloading that part of the page table from disk, which is so excessively slow that it will take many millions of cycles.

Then again, cache memory already fills more than 75% of the die of a CPU, and suffers seriously from diminishing returns.


In short, the best ways to speed up processing are:

1. Faster and/or wider memory access.
2. Using an SSD.

But, structurally, you want to get rid of the slow memory dictating speed, and use that die area occupied by cache memory in a more efficient way.

The best way to do that, is to regard hard disks as really slow memory, SSD's as very slow memory, RAM as slow memory and use the cache memory as main memory.

To explain: instead of just a few very fat and starved cores, you want many lean and mean ones. Get rid of registers as we know them, and give them multiple kilobytes of local storage, that is at least as fast as L2 cache memory, or even L1.

But, you want to be able to swap processes/threads, and send all the other processes/threads extensive messages, both which require you to be able to swap that local storage, fast.

Or, in other words: treat main memory and anything slower as a slow block device (map global page 087243658 to local page 24), and use paging to give all CPU cores a nice block of really fast local storage (previously cache memory).

And for synchronizing stuff, you create a build-in messaging on the system and chip level. Just a few words. Alerts.


But, in the mean time, we have to make do and use main memory as the best we have.

[glorfin]

After correcting the test shows a good performance for BufStream

Yes, it shows slightly better performance of mapping, but difference is not that dramatic.
Anyway, thank you for your experiment!