Path: csiph.com!usenet.pasdenom.info!news.etla.org!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Fri, 27 Feb 2015 02:30:46 -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> <201502241507.t1OF7aUm018883@fido.openend.se> <rosuav@gmail.com> <CAPTjJmpg+Ar-83fLPN5Pg3U5udLbkS0tBqF+aGQbiLrCVJ5aSw@mail.gmail.com> <201502241524.t1OFO09k022270@fido.openend.se> <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>
In-Reply-To: <54f00787$0$12979$c3e8da3$5496439d@news.astraweb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19302.1425022259.18130.python-list@python.org>
Lines: 70
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86564

On 02/27/2015 12:58 AM, Steven D'Aprano wrote:
> Dave Angel wrote:
>
>> (Although I believe Seymour Cray was quoted as saying that virtual
>> memory is a crock, because "you can't fake what you ain't got.")
>
> If I recall correctly, disk access is about 10000 times slower than RAM, so
> virtual memory is *at least* that much slower than real memory.
>

It's so much more complicated than that, that I hardly know where to 
start.  I'll describe a generic processor/OS/memory/disk architecture; 
there will be huge differences between processor models even from a 
single manufacturer.

First, as soon as you add swapping logic to your 
processor/memory-system, you theoretically slow it down.  And in the 
days of that quote, Cray's memory was maybe 50 times as fast as the 
memory used by us mortals.  So adding swapping logic would have slowed 
it down quite substantially, even when it was not swapping.  But that 
logic is inside the CPU chip these days, and presumably thoroughly 
optimized.

Next, statistically, a program uses a small subset of its total program 
& data space in its working set, and the working set should reside in 
real memory.  But when the program greatly increases that working set, 
and it approaches the amount of physical memory, then swapping becomes 
more frenzied, and we say the program is thrashing.  Simple example, try 
sorting an array that's about the size of available physical memory.

Next, even physical memory is divided into a few levels of caching, some 
on-chip and some off.  And the caching is done in what I call strips, 
where accessing just one byte causes the whole strip to be loaded from 
non-cached memory.  I forget the current size for that, but it's maybe 
64 to 256 bytes or so.

If there are multiple processors (not multicore, but actual separate 
processors), then each one has such internal caches, and any writes on 
one processor may have to trigger flushes of all the other processors 
that happen to have the same strip loaded.

The processor not only prefetches the next few instructions, but decodes 
and tentatively executes them, subject to being discarded if a 
conditional branch doesn't go the way the processor predicted.  So some 
instructions execute in zero time, some of the time.

Every address of instruction fetch, or of data fetch or store, goes 
through a couple of layers of translation.  Segment register plus offset 
gives linear address.  Lookup those in tables to get physical address, 
and if table happens not to be in on-chip cache, swap it in.  If 
physical address isn't valid, a processor exception causes the OS to 
potentially swap something out, and something else in.

Once we're paging from the swapfile, the size of the read is perhaps 4k. 
  And that read is regardless of whether we're only going to use one 
byte or all of it.

The ratio between an access which was in the L1 cache and one which 
required a page to be swapped in from disk?  Much bigger than your 
10,000 figure.  But hopefully it doesn't happen a big percentage of the 
time.

Many, many other variables, like the fact that RAM chips are not 
directly addressable by bytes, but instead count on rows and columns. 
So if you access many bytes in the same row, it can be much quicker than 
random access.  So simple access time specifications don't mean as much 
as it would seem;  the controller has to balance the RAM spec with the 
various cache requirements.
-- 
DaveA