Smalltalk › Squeak › Squeak VM

it's amazing to me...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Eliot Miranda-2

it's amazing to me...

to be able to evaluate

ByteArray new: 8 * 1024 * 1024 * 1024

and all it takes is a few seconds. No drama.

Now to see if I can save and restore an 8Gb image with the new non-stdio unix file support.

_,,,^..^,,,_

best, Eliot

David T. Lewis

Re: it's amazing to me...

On Mon, Oct 19, 2020 at 10:17:12AM -0700, Eliot Miranda wrote:
>
> to be able to evaluate
> ByteArray new: 8 * 1024 * 1024 * 1024
> and all it takes is a few seconds. No drama.
>
> Now to see if I can save and restore an 8Gb image with the new non-stdio
> unix file support.

I might have missed something, but does this mean that you have implemented
file I/O at the file descriptor level as opposed to the FILE* level for
Unix? I have always wondered which approach would give the best real-world
performance, and my guess was that the approach that Andreas used for the
Windows VM (HANDLE aka file descriptor level) is probably better overall.

Dave

Eliot Miranda-2

Re: it's amazing to me...

Hi Dave,

On Mon, Oct 19, 2020 at 12:14 PM David T. Lewis <[hidden email]> wrote:

On Mon, Oct 19, 2020 at 10:17:12AM -0700, Eliot Miranda wrote:
>
> to be able to evaluate
> ByteArray new: 8 * 1024 * 1024 * 1024
> and all it takes is a few seconds. No drama.
>
> Now to see if I can save and restore an 8Gb image with the new non-stdio
> unix file support.

I might have missed something, but does this mean that you have implemented
file I/O at the file descriptor level as opposed to the FILE* level for
Unix?

Only for image read/write, not for general file i/o. Though that shouldn't be difficult and I may get to soon. But I take Tim's suggestion of grouping the file pointer and the read/write data in one as a good one, and so would like to use pread/pwrite which provide this functionality.

I have always wondered which approach would give the best real-world
performance, and my guess was that the approach that Andreas used for the
Windows VM (HANDLE aka file descriptor level) is probably better overall.

Yes, it appears to be faster. The only complication is having to chunk reads/writes (as happens on Win32 for the same reason) because read/write don't like > 2Gb-1 (the max positive signed 32-bit value).

Dave

_,,,^..^,,,_

best, Eliot

timrowledge

Re: it's amazing to me...

> On 2020-10-19, at 12:26 PM, Eliot Miranda <[hidden email]> wrote:
>
> But I take Tim's suggestion of grouping the file pointer and the read/write data in one as a good one

It's definitely a good idea but to do it properly we'd really need to replace the mess that is FileStream. For RISC OS I had to make an absurdly over complicated linked list set up within the VM to deal with translating the FileStream prims to the OS view. As a small bonus it did provide the ability to open a file multiple times (something I find utterly horrific) to cope with the weird way a lot of FieStream works. The good news is that nobody ever found a bug in it, so maybe I got that right.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RWD: Rewind Disk