somebody wrote:
> "Darren New" <dne### [at] sanrrcom> wrote in message
> news:49b41abe$1@news.povray.org...
> 
>> It would have been more gain had 64-bit computers not come along and
>> eliminated the need to track that manually. Now, it's probably cheaper to
>> install Win64 than it is to pay someone to code up a swap file in POV. :-)
>> The power of mass market solutions trumps per-application solutions, in
> this
>> case.
> 
> Swapping to disk is immaterial of data bus width, it all depends on how much
> physical memory you have installed.

No. It also depends on how much address space you have available to work 
with, if you're talking about OS-supported demand-paged memory.

If you're talking about what Photoshop does, basically building its own 
demand-paged addressing system on top of the application, then no, that 
makes less difference. Photoshop has that feature because it was originally 
written in the days of 8-bit and 16-bit machines, where it was normal for 
the data to exceed the address space even in usual uses. Most programs of 
the time had the same kinds of features. It's very difficult to add 
after-the-fact, especially to a program written in a language where it's 
easy to make assumptions about how memory is organized.

> so even 64 bit systems shipping today may be limited to as
> little as 6GB.

6GB of physical RAM. That's not your problem. Your problem is that you have 
only 2GB of address space. You'd run into the same limitation regardless of 
how much physical RAM or disk you have.

> On top of that, for high efficiency, automatic memory management will not
> beat application managed memory.

That's debatable. It's certainly sometimes true. Not always, tho.

> Similarly, a text/hex editor that uses the same method (of loading into
> memory) for opening a 1KB file as a 1GB file is, to put it mildly, has got
> to be written by monkeys.

Talk to RSM. I tried to use his emacs a long time ago, and the executable 
wouldn't even link into the address space of an 8086. :-) Other editors of 
the time (just as powerful) knew memory was limited and did things to handle 
it.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:49b450c9@news.povray.org...
> somebody wrote:

> > Swapping to disk is immaterial of data bus width, it all depends on how
much
> > physical memory you have installed.

> No. It also depends on how much address space you have available to work
> with, if you're talking about OS-supported demand-paged memory.

I meant application managed swapping.

> If you're talking about what Photoshop does, basically building its own
> demand-paged addressing system on top of the application, then no, that
> makes less difference. Photoshop has that feature because it was
originally
> written in the days of 8-bit and 16-bit machines, where it was normal for
> the data to exceed the address space even in usual uses.

Yes, "usual use" is the operative phrase. It's very hard to anticipate what
a "usual use" is, even down 6 months down the road. Adobe got lucky being
forced to make correct decisions at that time. You are also correct that's
it's very difficult to alter the architecture of an existing program, as you
note below. Thus, the safe method is to *not* assume your data will always
fit into physical memory, even if it will fit into the address space for the
foreseeable future. If the possibility is there that the data may not fit
into physical memory, you have to ask if you or the OS will be in a better
position to decide when, if, what and how to page. OS, to me, should be the
last resort. I see entirely too many programs today being written with most
inefficient use of memory since "OS will manage it". With 64 bit address
space, I am pretty sure that we will see applications that are memory hogs
and inefficient at levels we have never seen before.

> Most programs of
> the time had the same kinds of features. It's very difficult to add
> after-the-fact, especially to a program written in a language where it's
> easy to make assumptions about how memory is organized.

Post a reply to this message

somebody wrote:
> Thus, the safe method is to *not* assume your data will always
> fit into physical memory, even if it will fit into the address space for the
> foreseeable future.

I disagree. You balance the functionality you lose against the speed and/or 
efficiency and/or programming convenience you gain.

 > If the possibility is there that the data may not fit
> into physical memory, you have to ask if you or the OS will be in a better
> position to decide when, if, what and how to page. 

Yep. And you have to balance it against the fact that the OS *will* make 
that decision regardless of whether you want it to or not, and regardless of 
whether you're coding your own paging or not. You also have to balance it 
against the fact that the OS knows who else is using the memory, the 
performance characteristics of the various devices in the machine (including 
page tables, main memory, USB memory, and the disks it may have available to 
swap to), paging behavior of previous executions of the program, and so on. 
I'm not sure you'd gain much by reimplementing all that logic in each 
application and *still* not having the global knowledge the OS has.

> OS, to me, should be the last resort. 

I'm glad all your programs implement their own custom swap files. Me, I'd 
rather have actual improvements in the outputted results, especially given 
that we both already have machines that can handle plenty of memory.

If 64-bit chips and OSes weren't already available, I might agree with you 
that it is important. But I'd rather see POV making full use of all the 
cores than getting slowed down to support someone running a 32-bit OS on a 
64-bit machine.

> I see entirely too many programs today being written with most
> inefficient use of memory since "OS will manage it". With 64 bit address
> space, I am pretty sure that we will see applications that are memory hogs
> and inefficient at levels we have never seen before.

Then don't buy them. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message