Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Fri, 27 Feb 2015 10:24:55 -0500
From: Dave Angel <davea@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Newbie question about text encoding
References: <aae131a7-29a1-4f79-ac16-d1e223616c51@googlegroups.com> <CAPTjJmoSZm8xRxeq-8G5KOKWddQxq23ieWqsY+jjCJXuY3DP0A@mail.gmail.com> <201502241620.t1OGKf4n002146@fido.openend.se> <54ECB134.5090304@davea.name> <201502241945.t1OJjshO013092@fido.openend.se> <201502241957.t1OJvrJS015604@fido.openend.se> <mailman.19148.1424810518.18130.python-list@python.org> <ef520397-b1f0-47bf-8d24-585a9ba230e2@googlegroups.com> <CAPTjJmreaPu7MZQgmbFNnhhg9R6w9dHPPo=yBbMoG85HxK+H_Q@mail.gmail.com> <mailman.19274.1424970167.18130.python-list@python.org> <00fbd940-52f6-44e2-bf08-b9f35c12e73f@googlegroups.com> <54efc2c8$0$12986$c3e8da3$5496439d@news.astraweb.com> <mailman.19299.1425002275.18130.python-list@python.org> <54f00787$0$12979$c3e8da3$5496439d@news.astraweb.com> <mailman.19302.1425022259.18130.python-list@python.org> <54f05aff$0$12980$c3e8da3$5496439d@news.astraweb.com> <54F078FD.5030801@davea.name> <CAPTjJmr8U9e-Q2GVrFNrTVPR0bC8Yo3=NYzdEkYcj1yBZaT+Eg@mail.gmail.com>
In-Reply-To: <CAPTjJmr8U9e-Q2GVrFNrTVPR0bC8Yo3=NYzdEkYcj1yBZaT+Eg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19308.1425050702.18130.python-list@python.org>
Lines: 61
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86574

On 02/27/2015 09:22 AM, Chris Angelico wrote:
> On Sat, Feb 28, 2015 at 1:02 AM, Dave Angel <davea@davea.name> wrote:
>> The term "virtual memory" is used for many aspects of the modern memory
>> architecture.  But I presume you're using it in the sense of "running in a
>> swapfile" as opposed to running in physical RAM.
>
> Given that this started with a quote about "you can't fake what you
> ain't got", I would say that, yes, this refers to using hard disk to
> provide more RAM.
>
> If you're trying to use the pagefile/swapfile as if it's more memory
> ("I have 256MB of memory, but 10GB of swap space, so that's 10GB of
> memory!"), then yes, these performance considerations are huge. But
> suppose you need to run a program that's larger than your available
> RAM. On MS-DOS, sometimes you'd need to work with program overlays (a
> concept borrowed from older systems, but ones that I never worked on,
> so I'm going back no further than DOS here). You get a *massive*
> complexity hit the instant you start using them, whether your program
> would have been able to fit into memory on some systems or not. Just
> making it possible to have only part of your code in memory places
> demands on your code that you, the programmer, have to think about.
> With virtual memory, though, you just write your code as if it's all
> in memory, and some of it may, at some times, be on disk. Less code to
> debug = less time spent debugging. The performance question is largely
> immaterial (you'll be using the disk either way), but the savings on
> complexity are tremendous. And then when you do find yourself running
> on a system with enough RAM? No code changes needed, and full
> performance. That's where virtual memory shines.
>
> It's funny how the world changes, though. Back in the 90s, virtual
> memory was the key. No home computer ever had enough RAM. Today? A
> home-grade PC could easily have 16GB... and chances are you don't need
> all of that. So we go for the opposite optimization: disk caching.
> Apart from when I rebuild my "Audio-Only Frozen" project [1] and the
> caches get completely blasted through, heaps and heaps of my work can
> be done inside the disk cache. Hey, Sikorsky, got any files anywhere
> on the hard disk matching *Pastel*.iso case insensitively? *chug chug
> chug* Nope. Okay. Sikorsky, got any files matching *Pas5*.iso case
> insensitively? *zip* Yeah, here it is. I didn't tell the first search
> to hold all that file system data in memory; the hard drive controller
> managed it all for me, and I got the performance benefit. Same as the
> above: the main benefit is that this sort of thing requires zero
> application code complexity. It's all done in a perfectly generic way
> at a lower level.

In 1973, I did manual swapping to an external 8k ramdisk.  It was a box 
that sat on the floor and contained 8k of core memory (not 
semiconductor).  The memory was non-volatile, so it contained the 
working copy of my code.  Then I built a small swapper that would bring 
in the set of routines currently needed.  My onboard RAM (semiconductor) 
was 1.5k, which had to hold the swapper, the code, and the data.  I was 
writing a GPS system for shipboard use, and the final version of the 
code had to fit entirely in EPROM, 2k of it.  But debugging EPROM code 
is a pain, since every small change took half an hour to make new chips.

Later, I built my first PC with 512k of RAM, and usually used much of it 
as a ramdisk, since programs didn't use nearly that amount.


-- 
DaveA