Interesting presentation
|
Prev: Multi-core lag for Left 4 Dead 1 and 2 and Quake 4 on AMD X23800+ processor... why ?
Next: Which is the most beautiful and memorable hardware structure in a CPU?
From: Anton Ertl on 5 Apr 2010 09:26 Morten Reistad <first(a)last.name> writes: >The classic mainframe paging got underway when a disk access took somewhat >more than 200 instructions to perform. Where "somewhat more than 200" translates to "on the order of 10000". The first machine with virtual memory was the Atlas, where a fixed-point register add took 1.59 microseconds according to <http://en.wikipedia.org/wiki/Atlas_Computer>. The page does not tell how fast the drum store (used for secondary storage) was, but the drums were bigger and rotated slower than today's disk drives. E.g., <http://en.wikipedia.org/wiki/IBM_System/360> mentions the IBM 2301, which had 3500rpm. If the (earlier) Atlas drum rotated at the same speed, we get a rotational latency of 8571 microseconds, i.e., 5391 instructions. To that add the time to read in the page (a full rotation would be 10782 instructions, but maybe they could store more than one page per track, and thus have faster read times). Later mainframe paging probably had similar speed ratios. > Now it is main memory that takes a >similar number of instructions to access. Not on the machines I use. A main memory access typically takes a few hundred cycles. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: nmm1 on 5 Apr 2010 10:22 In article <2010Apr5.152611(a)mips.complang.tuwien.ac.at>, Anton Ertl <anton(a)mips.complang.tuwien.ac.at> wrote: >Morten Reistad <first(a)last.name> writes: > >>The classic mainframe paging got underway when a disk access took somewhat >>more than 200 instructions to perform. > >Where "somewhat more than 200" translates to "on the order of 10000". Yes. That was true even a decade later, when IBM rediscovered it! >> Now it is main memory that takes a >>similar number of instructions to access. > >Not on the machines I use. A main memory access typically takes a few >hundred cycles. Grrk. Remember that current systems are 'multi-issue', so the comparable instruction time is less. Make it a thousand, and I will agree with you :-) At 10,000 versus 1,000, the analogy isn't perfect, but it's close. Regards, Nick Maclaren.
From: Stephen Fuld on 5 Apr 2010 11:55 On 4/3/2010 10:49 AM, Andy "Krazy" Glew wrote: > On 4/3/2010 10:29 AM, nmm1(a)cam.ac.uk wrote: > >> What I don't understand is why everybody is so attached to demand >> paging - it was near-essential in the 1970s, because memory was >> very limited, but this is 35 years later! As far as I know, NONE >> of the facilities that demand paging provides can't be done better, >> and more simply, in other ways (given current constraints). > > I think my last post identified a slightly far-out reason: you can page > without knowledge of software. But you can't swap. > > Paging (and other oblivious caching) has a more graceful fall-off. Note > that I can't say truly graceful, because modern OSes don't page well. > > If you are doing whole program swapping, you can't run a program larger > than memory With paging you can - although you better not be accessing a > footprint larger than memory That depends upon the implementation of the segments. You could arrange things so that whole segments could be swapped. Sort of an intermediate approach. > If you are doing segment swapping, and if data structures are > constrained to be no larger than a segment, then you can't have a data > structure larger than main memory. Or even approaching in size, since > you will hae other segments. With paging you can. Again, a smart implementation of segments could address this (sorry for the pun). It has been done. > Sure, there have been compilers that automatically split up stuff like > "char array[1024*1024*1024*16]" into multiple segments (where segments > had a fixed maximum size). But that sure does look like paging. Just > potentially with variable size pages. True, but the "pages' are typically much larger, and their size is more related to the logic of the program instead of some physical characteristic of the machine. > Hmmm... modern techniques like COW zero filled pages and forking work > better with pages than with segments. You could COW whole segments. But > it really is better to have a level underneath the segments. It could be > segments and sub-segments, but it so often is segments and paging. And > if you have paging, you don't need segments. True, you don't need segments, but there might be some advantages of having them. See below. > Segments are associated far too often with restrictions such as "you > can't have data structures bigger than 64K." Or 1G, Or 2^40 Such > restrictions are the kiss of death. Well, you already have the limit of the size of the register. And with a well done segment implementation, you could sort of get around this. That is, with individually swappable segments, you could have an arbitrarily large program, potentially even larger than you would think with the amount of data you can address with the bits in a single register. As I said above, it has been done. To your list of advantages of paging, I would add the elimination of memory fragmentation. But there are some potential advantages of a well done segmentation scheme as well. For example: It makes more sense to have such things as usage restrictions be based on a structure that is logically related to the program instead of some arbitrary fixed size. Things like execute only, read only, cachability, etc. are obvious examples. You can potentially eliminate a lot of the mess of addressing shared libraries. If each shared library element started at address zero relative to some segment start register, you could eliminate the need for position independent code, mapping the same code to different addresses in different programs, etc. -- - Stephen Fuld (e-mail address disguised to prevent spam)
From: nmm1 on 5 Apr 2010 12:19 In article <hpd162$n2s$1(a)news.eternal-september.org>, Stephen Fuld <SFuld(a)Alumni.cmu.edu.invalid> wrote: > >To your list of advantages of paging, I would add the elimination of >memory fragmentation. Eh? Not merely does it not eliminate it, it can make it worse! The dogma that page tables must not be visible to the programmer has made a lot of memory tuning nigh-on impossible for as long as demand paging has been around. As the Atlas/Titan showed, virtual memory without demand paging eliminates memory fragmentation just as well as demand paging does. Regards, Nick Maclaren.
From: Anton Ertl on 5 Apr 2010 14:37
nmm1(a)cam.ac.uk writes: >In article <2010Apr5.152611(a)mips.complang.tuwien.ac.at>, >Anton Ertl <anton(a)mips.complang.tuwien.ac.at> wrote: >>Not on the machines I use. A main memory access typically takes a few >>hundred cycles. > >Grrk. Remember that current systems are 'multi-issue', so the >comparable instruction time is less. Yes, the superscalarity allows them to reach an IPC of about 1 on typical applications; not sure if we would see the same IPC in a paging handler. Of course you might argue that the Atlas also had some additional latencies that caused a factor of 3 or 4 fewer instructions to be executed for each page-in than I computed. I don't know enough about the Atlas to support or contradict that. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html |