Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #6484 > unrolled thread

Indirect Bit

Back to article view | Back to comp.arch

Contents

  Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-10 19:31 -0800
    Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-11 01:29 -0500
      Re: Indirect Bit sarr.blumson@alum.dartmouth.org - 2012-04-11 14:48 +0000
        Re: Indirect Bit mac <acolvin@efunct.com> - 2012-04-12 14:43 +0000
      Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:19 +0200
        Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:24 -0700
    Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-11 08:32 +0200
      Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-11 05:49 -0700
        Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:22 -0700
          Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 08:14 -0700
            Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:13 -0700
              Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 20:01 -0700
                Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-14 03:16 +0000
                  Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 08:14 -0700
          Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:05 -0700
            Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:01 -0700
              Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 13:49 -0700
            Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-13 20:07 -0400
            Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-14 18:47 +0200
            Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:26 +0200
              Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:25 -0700
                Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 09:18 +0100
                  Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-23 19:35 -0400
                    Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 08:37 +0100
                      Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 09:42 +0100
                        Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 01:58 -0700
                          Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 11:26 +0100
                            Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 05:02 -0700
                              Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:58 +0100
                                Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 10:07 -0700
                      Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 04:30 -0700
                        Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:01 +0100
    Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-11 10:03 -0400
    Re: Indirect Bit kenney@cix.compulink.co.uk - 2012-04-11 09:22 -0500
      Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:11 -0700
        Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-12 18:05 -0400
          Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:13 -0700
        Re: Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-12 16:55 -0800
          Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 17:25 -0700
            Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-12 20:03 -0500
            Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:33 -0700
              Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 15:57 -0700
                Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:03 -0700
          Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:14 -0700
    Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-11 10:35 -0400
    Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-11 08:54 -0700
    Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 07:55 -0700
      Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-12 10:16 -0700
        Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-12 11:07 -0700
          Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:34 -0700
        Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-12 11:35 -0700
          Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:41 -0700
            Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-13 14:52 -0700
            Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 09:24 -0700
              Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-15 22:45 +0200
                Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 18:04 -0700
        Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:12 -0700
      Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-12 19:23 +0000
      Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-13 08:54 +0200
        Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-14 14:37 -0700
      Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-15 23:42 +0000
        Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:08 -0700
          Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:38 +0000
            Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:29 -0700
        Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:25 -0700
    Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:05 -0700
      Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 10:12 +0000
        Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 06:25 -0700
          Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-14 14:50 +0100
            Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 18:01 +0000
              Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 14:00 -0700
                Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-14 20:58 -0400
              Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 09:57 -0700
              Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-20 23:19 +0000
            Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:50 -0700
              Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 18:09 +0100
                Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:19 +0000
                  Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-17 09:20 +0100
                    Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-17 12:49 +0200
                      Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 12:40 +0000
                        Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-18 12:01 +0100
                  Re: Indirect Bit anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-17 12:34 +0000
                  Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-17 09:10 -0700
                    Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 22:05 +0000
                    Re: Indirect Bit jgk@panix.com (Joe keane) - 2012-04-19 19:37 +0000
                    Re: Indirect Bit torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-20 11:10 +0200
                      Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-20 11:24 +0200
                        Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:01 +0100
                        Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:03 +0100
                          Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-20 08:01 -0700
                            Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 16:35 +0100
                  Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:10 -0700
                    Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:37 -0700
            Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-16 11:21 -0700
              Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 19:36 +0100
                Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:17 -0700
                  Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:33 -0700
                  Re: Indirect Bit Andreas Eder <andreas_eder@gmx.net> - 2012-04-19 00:29 +0200
                  Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 10:50 +0100
                    Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-19 11:29 -0700
                      Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 21:39 +0100
                      Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-20 15:14 -0400
                        Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-20 22:43 -0700
                          Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-21 17:14 -0400
                            Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-21 19:47 -0500
                            Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 10:45 +0200
                              Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 09:57 +0100
                                Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-22 12:54 +0200
                                  Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:00 +0100
                                Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 13:28 +0200
                                  Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:04 +0100
                                    Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-22 23:00 +0200
                                      Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-22 18:05 -0400
                                      Re: Indirect Bit glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-22 23:20 +0000
                                      Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:22 +0100
                              Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-22 03:56 -0700
                                Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-22 12:28 -0400
                                  Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 12:56 -0500
                                    Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:15 -0700
                                  Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 22:30 +0200
                                    Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 21:40 +0100
                                      Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 17:15 -0500
                                        Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:26 +0100
                                          Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-23 08:02 -0700
                                            Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 17:02 +0100
                                            Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-23 20:17 +0200
                                          Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-23 13:07 -0500
                              Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:16 -0700
                                Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-23 13:14 -0700
                                  Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-23 16:51 -0400
                                  Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-23 14:22 -0700
                        Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-21 11:17 -0700
          Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-14 08:02 -0700

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#6484 — Indirect Bit

The PDP-10 and Nova had an indirect bit, in which a pointer
had both an address and a bit to indicate whether the object
being addressed was data or another pointer.  On the PDP-10,
the pointer was word length (36 bits) but addresses were only
18 bits, so there was plenty of room for the indirect bit,
four register select bits (used for a base register), and
a bunch of unused bits.  On the Nova which was 16 bits,
bit 0 was used, which took away the ability to address odd
bytes (or it could have been used to double the address
space, which would have meant a lot on the Nova).

These machines had the peculiar feature that an instruction
could execute for an indefinite number of cycles until the
last pointer was found (indirect bit = 0).  This allowed the
CPU to run through linked lists without wasting instruction
bandwidth and registers reading in the pointers so they can
address memory.

Now, with 64-bit architectures, there's a bunch of address
bits nobody needs.  How about taking A63 and using it as
an indirect bit?  That could extend the x86 architecture
in a way that's software-compatible with the existing
architecture.

This gets really interesting if it's handled in the memory
controller.  When the CPU issues an address with A63 = 1,
it falls through to the memory controller, which then reads
the pointer from memory (or cache), checks the state of A63
on that pointer, and either fetches the data to return to
the CPU or fetches another pointer.  Of course, the pointers
must contain virtual addresses, so the MC will have to have
its own MMU and TLB.

This offloads all of the messing around with pointers from
the CPU bus, registers, cache, etc.  If you do a lot of
linked lists, this is an enormous win.

What if you don't use linked lists?  Lots of APIs are
accessed through data structures for which the application
has a handle (pointer to a pointer).  For example, a
communication channel might be controlled through a handle
to a data structure that holds the channel's control and
status bits and anything else it needs, like a pointer
to a callback function.  Driver libraries and layered
communication protocols frequently use data structures
that collect together all of the API stuff for a device
or service.

This form of access differs from the linked list in that
you are only going two levels deep and you are applying an
offset to the second level.  That is, the object you want
to access probably isn't the zeroth item in the data
structure, so you need to apply an offset from the pointer.
How does software specify this offset?

Unless you're doing something stupid that wastes tons of
address space, you don't need more than about 40 virtual
address bits.  In the future, no von Neumann architecture
machine will ever need more than 52 address bits for a user
application.  If A51:A0 is the linear address, A52 is the
user/kernel bit, and A63 is the indirect bit, that leaves
10 bits available to use for the offset into the data
structure.  That's enough to address a 1K data structure
with byte granularity.  All of the API data structures
I've seen are much smaller than that, but if 64-bit word
granularity is acceptable, the offset can be shifted by
three bit positions to address 8K.

These two forms of access can be served by one mechanism.
The VA comes out of the CPU, then the MC cycles through one
or more pointers and applies the offset (A62:A53) to the
last pointer.  Even linked lists can benefit from the
offset, because the data in the referenced item probably
resides at an offset from the pointer to that item.

So why isn't this already being implemented?  It relieves
the biggest bottlenecks in the system -- CPU cache space,
CPU instruction bandwidth, and CPU-cache bus bandwidth.
Maybe it doesn't simulate well on typical applications,
but typical applications aren't available that take
advantage of it.  You'd need to modify the compiler and
recompile them to use the indirect bit and offset.

[toc] | [next] | [standalone]

#6486

On Tue, 10 Apr 2012 19:31:43 -0800, Mark Thorson <nospam@sonic.net>
wrote:

>The PDP-10 and Nova had an indirect bit, in which a pointer
>had both an address and a bit to indicate whether the object
>being addressed was data or another pointer.  On the PDP-10,
>the pointer was word length (36 bits) but addresses were only
>18 bits, so there was plenty of room for the indirect bit,
>four register select bits (used for a base register), and
>a bunch of unused bits.  On the Nova which was 16 bits,
>bit 0 was used, which took away the ability to address odd
>bytes (or it could have been used to double the address
>space, which would have meant a lot on the Nova).
>
>These machines had the peculiar feature that an instruction
>could execute for an indefinite number of cycles until the
>last pointer was found (indirect bit = 0).  This allowed the
>CPU to run through linked lists without wasting instruction
>bandwidth and registers reading in the pointers so they can
>address memory.


Which allowed ordinary applications to put the machine into a hard
loop.  In both cases (definitely in the PDP-10 case, and IIRC in the
Nova case), a timer mechanism was used in later models to prevent
that.  Ugly as all heck.


>Now, with 64-bit architectures, there's a bunch of address
>bits nobody needs.  How about taking A63 and using it as
>an indirect bit?  That could extend the x86 architecture
>in a way that's software-compatible with the existing
>architecture.
>
>This gets really interesting if it's handled in the memory
>controller.  When the CPU issues an address with A63 = 1,
>it falls through to the memory controller, which then reads
>the pointer from memory (or cache), checks the state of A63
>on that pointer, and either fetches the data to return to
>the CPU or fetches another pointer.  Of course, the pointers
>must contain virtual addresses, so the MC will have to have
>its own MMU and TLB.


But most of the interesting pointers are going to be in cache already
- what about those?


>This offloads all of the messing around with pointers from
>the CPU bus, registers, cache, etc.  If you do a lot of
>linked lists, this is an enormous win.


Linked lists don't particularly benefit from this sort of thing,
unless you want to find the last element in the linked list, which is
relatively rare.  Usually if your scanning a linked list, you do some
sort of comparison or processing on each member before moving on.


>What if you don't use linked lists?  Lots of APIs are
>accessed through data structures for which the application
>has a handle (pointer to a pointer).  For example, a
>communication channel might be controlled through a handle
>to a data structure that holds the channel's control and
>status bits and anything else it needs, like a pointer
>to a callback function.  Driver libraries and layered
>communication protocols frequently use data structures
>that collect together all of the API stuff for a device
>or service.
>
>This form of access differs from the linked list in that
>you are only going two levels deep and you are applying an
>offset to the second level.  That is, the object you want
>to access probably isn't the zeroth item in the data
>structure, so you need to apply an offset from the pointer.
>How does software specify this offset?


Yes, how?  Most structures with chains of pointers are, in fact, not
simple pointer-to-pointer cases.  You'd need an instruction with an
encoded offset for each level of indirection traversed - and then you
wouldn't need an indirect bit, since the number of levels traversed
would be encoded in the instruction.


>Unless you're doing something stupid that wastes tons of
>address space, you don't need more than about 40 virtual
>address bits.  In the future, no von Neumann architecture
>machine will ever need more than 52 address bits for a user
>application.  If A51:A0 is the linear address, A52 is the
>user/kernel bit, and A63 is the indirect bit, that leaves
>10 bits available to use for the offset into the data
>structure.  That's enough to address a 1K data structure
>with byte granularity.  All of the API data structures
>I've seen are much smaller than that, but if 64-bit word
>granularity is acceptable, the offset can be shifted by
>three bit positions to address 8K.


There are databases right now that use terabyte address spaces for
caching data.  The OS guys *really*, *really*, *really*, *really* want
a logical address space as big as the physical memory installed in the
machine plus any I/O mappings, plus a bit extra.  If you don't believe
me, ask Linus Torvalds - he'll pin your ears back.  So there are
single image systems right now that need 45+ bits of logical address
space.  Your limit of 52 bits seems dangerously close.


>These two forms of access can be served by one mechanism.
>The VA comes out of the CPU, then the MC cycles through one
>or more pointers and applies the offset (A62:A53) to the
>last pointer.  Even linked lists can benefit from the
>offset, because the data in the referenced item probably
>resides at an offset from the pointer to that item.
>
>So why isn't this already being implemented?  It relieves
>the biggest bottlenecks in the system -- CPU cache space,
>CPU instruction bandwidth, and CPU-cache bus bandwidth.
>Maybe it doesn't simulate well on typical applications,
>but typical applications aren't available that take
>advantage of it.  You'd need to modify the compiler and
>recompile them to use the indirect bit and offset.


Because it's a bad idea.

In most cases the pointer chasing code is in i-cache anyway.  If the
chased pointers are not all in L1D, then the instruction decode and
dispatch overhead is meaningless, as the instructions will be waiting
for the L2 (or further out bits of the memory system) to respond
anyway.

It also has very limited applicability, the problem of chasing
pointers-to-structures-containing-pointers is nasty.

Now a single level of indirect reference, perhaps with an offset
added, has some potential, but that doesn't require an indirect bit,
or have any of the other problems associated with them.

[toc] | [prev] | [next] | [standalone]

#6496

Robert Wessel <robertwessel2@yahoo.com> wrote:
:
: Which allowed ordinary applications to put the machine into a hard
: loop.  In both cases (definitely in the PDP-10 case, and IIRC in the
: Nova case), a timer mechanism was used in later models to prevent
: that.  Ugly as all heck.

The PDP-10 didn't have a "modify the pointer as you go by" mode (like
the GE/Honeywell/Bull 6x5, for instance, which did have the sort of
timer you describe) so the indirection was interruptible. So an
indirect loop was just one more way to program an infinite loop.
Not a problem unless you were paying for your time. :-)

-- 
--------
Sarr Blumson                    sarr.blumson@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/

[toc] | [prev] | [next] | [standalone]

#6501

>So an indirect loop was just one more way to program an infinite loop. Not
> a problem unless you were paying for your time. :-)

Lockup faults took something like 16 msec, not too expensive. A common
Honeywell idiom for assetrions was
    Tcc *,*
which conditionally jumped indirect through its own indirect address. This
created an address loop of length 1, eventually causing a lockup. Not
expected to be recovered

Honeywell also had a repeat-linked instruction to chase linked lists
testing for a condition. Fast when it was in hardware, slow in micricode.


-- 
mac the naïf

[toc] | [prev] | [next] | [standalone]

#6600

In article <2u7ao79gf1u3emurmtdp9resiafv6d4ijq@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
>On Tue, 10 Apr 2012 19:31:43 -0800, Mark Thorson <nospam@sonic.net>
>wrote:
>
>>The PDP-10 and Nova had an indirect bit, in which a pointer
>>had both an address and a bit to indicate whether the object
>>being addressed was data or another pointer.  On the PDP-10,
>>the pointer was word length (36 bits) but addresses were only
>>18 bits, so there was plenty of room for the indirect bit,
>>four register select bits (used for a base register), and
>>a bunch of unused bits.  On the Nova which was 16 bits,
>>bit 0 was used, which took away the ability to address odd
>>bytes (or it could have been used to double the address
>>space, which would have meant a lot on the Nova).
>>
>>These machines had the peculiar feature that an instruction
>>could execute for an indefinite number of cycles until the
>>last pointer was found (indirect bit = 0).  This allowed the
>>CPU to run through linked lists without wasting instruction
>>bandwidth and registers reading in the pointers so they can
>>address memory.
>
>
>Which allowed ordinary applications to put the machine into a hard
>loop.  In both cases (definitely in the PDP-10 case, and IIRC in the
>Nova case), a timer mechanism was used in later models to prevent
>that.  Ugly as all heck.

Corrections to both of you regarding the PDP10. Firstly, all
bits in the instruction and pointer are used; although the
earlier PDP10s (KA10, KI10) never implemented some featuers
like multiple segments.

Secondly, even though the PDP10 can run in an infinite
address resolve loop by something as simple as

	MOVE 1,@.

(The MOVE 1 could be replaced by any instruction and register)

It does, however respond to interrupts properly while doing so.

Conceptually quite elegant. But it kills pipelining.

..snip..

>Because it's a bad idea.
>
>In most cases the pointer chasing code is in i-cache anyway.  If the
>chased pointers are not all in L1D, then the instruction decode and
>dispatch overhead is meaningless, as the instructions will be waiting
>for the L2 (or further out bits of the memory system) to respond
>anyway.
>
>It also has very limited applicability, the problem of chasing
>pointers-to-structures-containing-pointers is nasty.
>
>Now a single level of indirect reference, perhaps with an offset
>added, has some potential, but that doesn't require an indirect bit,
>or have any of the other problems associated with them.

Indeed.

-- mrr

[toc] | [prev] | [next] | [standalone]

#6615

On 4/22/2012 6:19 AM, Morten Reistad wrote:
> In article<2u7ao79gf1u3emurmtdp9resiafv6d4ijq@4ax.com>,
> Robert Wessel<robertwessel2@yahoo.com>  wrote:
>> On Tue, 10 Apr 2012 19:31:43 -0800, Mark Thorson<nospam@sonic.net>
>> wrote:
>>
>>> The PDP-10 and Nova had an indirect bit,
 >>
>> [1] In most cases the pointer chasing code is in i-cache anyway.  If the
>> chased pointers are not all in L1D, then the instruction decode and
>> dispatch overhead is meaningless, as the instructions will be waiting
>> for the L2 (or further out bits of the memory system) to respond
>> anyway.
>>
>> [2] It also has very limited applicability, the problem of chasing
>> pointers-to-structures-containing-pointers is nasty.
>>
>> [3] Now a single level of indirect reference, perhaps with an offset
>> added, has some potential, but that doesn't require an indirect bit,
>> or have any of the other problems associated with them.

I agree with the last two points (which I have labelled [2] and [3]).

The first part, [1], may be missing the point - the idea is to mark the 
load request so that when it is sent out to the L2 or further out bits 
of the memory subsystem whatever part of the memory subsystem provides 
the data does the indirection.  Thereby eliminated two "bus crossings".

[toc] | [prev] | [next] | [standalone]

#6487

Mark Thorson wrote:
> Now, with 64-bit architectures, there's a bunch of address
> bits nobody needs.  How about taking A63 and using it as
> an indirect bit?  That could extend the x86 architecture
> in a way that's software-compatible with the existing
> architecture.

Virtual address bits are often used both from the top and the bottom, so 
"negative" addresses might already be allocated to the kernel.

Anyway, this could have been handled, but the main problem with your 
approach is that (a) it can occupy the memory bus for arbitrarily long 
time periods (unless you have a dead-man timer/counter which stops you 
after N indirections), and (b) it would require a totally new memory 
interface (which might be less of a problem), but it would not play well 
with OoO memory speculation afaik?

> This gets really interesting if it's handled in the memory
> controller.  When the CPU issues an address with A63 = 1,
> it falls through to the memory controller, which then reads
> the pointer from memory (or cache), checks the state of A63
> on that pointer, and either fetches the data to return to
> the CPU or fetches another pointer.  Of course, the pointers
> must contain virtual addresses, so the MC will have to have
> its own MMU and TLB.
>
> This offloads all of the messing around with pointers from
> the CPU bus, registers, cache, etc.  If you do a lot of
> linked lists, this is an enormous win.

It is not:

In a linked list you almost always have to check some item in the 
current node before you can know that you have to follow the next pointer.

Indirection is only a win when you have handles that must always be 
indirected through, or when you have the capability to combine 
indirection with immediate and/or register offsets:

In the latter case you can use it for single-instruction indexing into 
arrays of pointers to arrays.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#6491

On Apr 11, 9:32 am, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
> Mark Thorson wrote:
> > This offloads all of the messing around with pointers from
> > the CPU bus, registers, cache, etc.  If you do a lot of
> > linked lists, this is an enormous win.
>
> It is not:
>
> In a linked list you almost always have to check some item in the
> current node before you can know that you have to follow the next pointer.
>
> Indirection is only a win when you have handles that must always be
> indirected through, or when you have the capability to combine
> indirection with immediate and/or register offsets:
>
> In the latter case you can use it for single-instruction indexing into
> arrays of pointers to arrays.
>
> Terje
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Methinks, there is much more fundamental reason for traversing of list/
tree like structures by memory controller to be a horrible idea.
In two words - caches work.

[toc] | [prev] | [next] | [standalone]

#6516

On 4/11/2012 5:49 AM, Michael S wrote:

> Methinks, there is much more fundamental reason for traversing of list/
> tree like structures by memory controller to be a horrible idea.
> In two words - caches work.

Agreed, but this doesn't obviate Mark Thorson's (and Peter Kogge's, and 
...)'s point, that turning around a pointer indirection outside the 
processor may be worthwhile.

What it says is that turning indirections around at the memory 
controller, always, is probably not a good idea.  You probably need to 
adjust things so that it turns around at whatever level of the memory 
hierarchy is appropriate.  Maybe not the L1 cache, but possibly the L2 
or L3.

Which also means that, in addition to handling virtual memory, you may 
also need to handle cache coherency.  Usually the memory controller does 
not participate in the cache protocol, eh?  But, perhaps if you have an 
in memory directory. Was that Stanford's Dash and Flash project? (Can't 
remember if that was an in cache directory, or in memory.)

Now, many of the supercomputer folks I used to work with think that 
caches are a waste of power.  I'm not there yet.

[toc] | [prev] | [next] | [standalone]

#6523

On Apr 13, 12:22 am, "Andy (Super) Glew" <a...@SPAM.comp-arch.net>
wrote:
[snip]
> Which also means that, in addition to handling virtual memory, you may
> also need to handle cache coherency.  Usually the memory controller does
> not participate in the cache protocol, eh?  But, perhaps if you have an
> in memory directory. Was that Stanford's Dash and Flash project? (Can't
> remember if that was an in cache directory, or in memory.)

FLASH used two regions of main memory for storage of directory
information, one containing the basic directory information
("directory header"--flags, a node pointer, and a pointer into the
"pointer/link store") and another containing additional node
pointers ("pointer/link store"--containing linked list entries).

DASH seems to have had a separate directory controller attached
to a bus shared with cache controllers for the processors and
the memory controller.

I have to wonder if a future system might have directory
controllers in the memory modules.  If one needs a buffer
chip anyway (for bandwidth/capacity), offloading directory
function might be reasonable to provide scalability.

Processing in/near memory tradeoffs also depend on the
memory layout and interconnect.  E.g., DRAM chips
currently tend to be byte interleaved which would tend to
force processing to be outside the DRAM chip itself, which
loses some bandwidth and power benefits.  (If entire ECC
words were included in a DRAM, some internal processing
might be practical.  In addition, more aggressive error
correction/detection could be used without a bandwidth
penalty.)

Coarser-grained interleaving (cache line or 'page')
would seem to excessively increase latency, though such
might not nearly as important as bandwidth in a heavily
multithreaded future; but coarser interleaving would
seem to allow more opportunity for in chip processing.

Unless the fixation on price per bit can be overcome, I
do not see much hope for processing in/near memory (or
certain other improvements in the memory system).

[toc] | [prev] | [next] | [standalone]

#6528

On Apr 13, 9:14 am, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:

> Unless the fixation on price per bit can be overcome, I
> do not see much hope for processing in/near memory (or
> certain other improvements in the memory system).

I do not expect price per bit to stop being something very, very
important any time soon.

But I'm not sure if that's a problem. Because the extra cost of
putting processing power in memory ought to be paid for out of one's
"processing" budget, not one's "memory" budget. So one can't expect
the extra cost to not be noticed, and just rolled into the cost of
memory, but one can expect people to make a rational decision on
whether spending extra money on active memory adds more computing
power than spending extra money on a bigger central CPU.

Of course, this model has problems too. It's quite all right for
scientists to use standard parts to build a machine with, say, a fancy
hierarchical NUMA structure.

But when it comes to chips, the cost of custom or specialized chips
versus mass-market chips means that chips optimized to supercomputer
applications are, in general, impractical. More's the pity, of course,
but that looks as though it won't change soon - unless there are basic
improvements in reconfigurable computing.

So a specialized part, such as a memory chip with built-in
computational capabilities, is unlikely to be an option unless it can
be sold as valuable in the mass market for computer systems.

John Savard

[toc] | [prev] | [next] | [standalone]

#6532

On Apr 13, 7:13 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Apr 13, 9:14 am, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:
>
> > Unless the fixation on price per bit can be overcome, I
> > do not see much hope for processing in/near memory (or
> > certain other improvements in the memory system).
>
> I do not expect price per bit to stop being something very, very
> important any time soon.
>
> But I'm not sure if that's a problem. Because the extra cost of
> putting processing power in memory ought to be paid for out of one's
> "processing" budget, not one's "memory" budget. So one can't expect
> the extra cost to not be noticed, and just rolled into the cost of
> memory, but one can expect people to make a rational decision on
> whether spending extra money on active memory adds more computing
> power than spending extra money on a bigger central CPU.

In memory processors would probably not provide much
"processing" power, instead 'only' reducing the problem of the
memory wall (latency and perhaps especially bandwidth).  It is
not clear how such could be marketed to high volume uses.  (It
is possible that the more appliance-like nature of tablets and
smart phones [and, of course, more truly embedded systems] might
allow a system vendor to use PiM to improve performance and/or
power efficiency.)

I based my comment on the non-adoption of memory technologies
that would have improved performance more than they increased
cost (if produced at comparable volumes).

> Of course, this model has problems too. It's quite all right for
> scientists to use standard parts to build a machine with, say, a fancy
> hierarchical NUMA structure.
>
> But when it comes to chips, the cost of custom or specialized chips
> versus mass-market chips means that chips optimized to supercomputer
> applications are, in general, impractical. More's the pity, of course,
> but that looks as though it won't change soon - unless there are basic
> improvements in reconfigurable computing.

There are some (minor) indications that specialized chips might be
more practical in the not too distant future.  Electron beam
lithography (which shows some potential for become practical)
could reduce incremental costs.  In addition, if process shrinks
become less frequent and increasingly more expensive, the time
over which a specialized design could be profitable might
increase and more investment might be made into reducing fixed
costs for specialized designs.

There is also the factor of dark silicon.  If silicon area is
relatively inexpensive (and needed for off-chip bandwidth,
cooling, etc.), then including specialized (more efficient)
functionality on generic chips might become more attractive.

> So a specialized part, such as a memory chip with built-in
> computational capabilities, is unlikely to be an option unless it can
> be sold as valuable in the mass market for computer systems.

That seems likely, and I do not know how such could
achieve a large enough market.  The R&D investment necessary
seems most likely to come from a system vendor (like IBM or
Apple or possibly Oracle) rather than a software vendor
(like Microsoft) or a merchant processor vendor (like Intel
or ARM).  (The memory manufacturers do not seem to be that
big into R&D, especially not for disruptive technologies.)

Perhaps I am being overly pessimistic.  I certainly do not
know much about the economics involved or the actual R&D
efforts of any organization.

[toc] | [prev] | [next] | [standalone]

#6533

On Fri, 13 Apr 2012 20:01:31 -0700, Paul A. Clayton wrote:

> In memory processors would probably not provide much "processing" power,
> instead 'only' reducing the problem of the memory wall (latency and
> perhaps especially bandwidth).  It is not clear how such could be
> marketed to high volume uses.  (It is possible that the more
> appliance-like nature of tablets and smart phones [and, of course, more
> truly embedded systems] might allow a system vendor to use PiM to
> improve performance and/or power efficiency.)

Modern phone and tablet processors ship with memory in "stacked" form as 
a single package these days.  Is that not, perhaps, a better design point 
than trying to get a processor to run in DRAM process, or vice-versa?

That's a package with about 1G of DRAM and a dual or quad-core processor 
with SIMD floating point running north of 1GHz, usually with a matching 
GPU.  ARM definitely have an eye on the "server/HPC" market with the v8 
architecture, and they have definitely been talking with and about system 
vendors who could/would use their cores in SoC parts that replace the 
video encode/decode ASICs with some sort of sophisticated switch fabric.

ARM aren't alone in looking at the power-efficient compute market of 
course.  TI think there's an in for them, which is why their new C6000 
lines have MMUs and other "OS support" features.

Cheers,

-- 
Andrew

[toc] | [prev] | [next] | [standalone]

#6539

Andrew Reilly wrote:
[snip]
> Modern phone and tablet processors ship with memory in "stacked" form as
> a single package these days.  Is that not, perhaps, a better design point
> than trying to get a processor to run in DRAM process, or vice-versa?

From a perspective of market practicalities, such is probably the
case.
I am less confident that such is ideal with respect to technology.  It
is
not clear to me what the tradeoffs are with respect to process
technology
optimization.  Current DRAM is very cost optimized, so a more
performance-optimized DRAM (or other memory technology) might be
more friendly to processing.

Even processing near memory sacrifices some power and bandwidth
(though communicating 1 cm across a chip "should" be more expensive
than communicating 20 µm even leaving the chip, I receive the
impression that such is not yet widely the case).

There is a recentish startup trying to provide DRAM-friendly
processing, but such seems unlikely to succeed.

> That's a package with about 1G of DRAM and a dual or quad-core processor
> with SIMD floating point running north of 1GHz, usually with a matching
> GPU.  ARM definitely have an eye on the "server/HPC" market with the v8
> architecture, and they have definitely been talking with and about system
> vendors who could/would use their cores in SoC parts that replace the
> video encode/decode ASICs with some sort of sophisticated switch fabric.

One problem with such tight integration is that the power consumption
of the processor is more limited.  (This may be even more the case
for
commodity DRAM where reliability and required refresh rate may be
more sensitive to temperature.)  High single-thread performance costs
power, so even some server workloads might not fit that type of
system.
(OTOH, if bandwidth is the primary performance limit, tighter
integration
of memory would compensate for lower single-thread performance.)

Interconnect power could also be a factor.  I receive the impression
that the ARM systems are initially targeting non-coherent systems
which reduces the bandwidth (and thus power) requirements for each
node.

Stacked memory connected to a processor by an interposer seems
to be an alternative that allows a higher power envelope for the
processing component (presumably at the cost of latency, bandwidth,
and power--but probably also having lower manufacturing cost).

(High performance memory might also use a significant amount of
power, so even stacking memory might have power limits.)

> ARM aren't alone in looking at the power-efficient compute market of
> course.  TI think there's an in for them, which is why their new C6000
> lines have MMUs and other "OS support" features.

Something like Micron's Hybrid Memory Cube could be extended
to support processing near memory.

If only a moderate latency penalty was paid for going through the
wimpy power-efficient processing chip (and such a buffer chip was
desired anyway for bandwidth), then attaching such to a heavy-
weight processor might be practical.

Overall, I agree that such techniques show promise (and seem
substantially more practical than processing in memory).

[toc] | [prev] | [next] | [standalone]

#6527

On Apr 12, 10:22 pm, "Andy (Super) Glew" <a...@SPAM.comp-arch.net>
wrote:

> Now, many of the supercomputer folks I used to work with think that
> caches are a waste of power.  I'm not there yet.

We know from IBM's disappointing results with the STRETCH and the
360/91, and its unexpected bonus of performance from the 360/85, that
caches not only work, but they work well. On most normal computational
tasks, they make RAM look almost like it is as fast as the more
expensive and more power-consuming memory used in the cache.

So caches are anything but a waste in most computers. On the one hand,
some supercomputers, though, are sometimes used for problems with poor
locality. On the other hand, the 360/195, for example, got by very
nicely with 32 Kbytes of cache, and so it might legitimately be asked
if something like 2 Mbytes of cache as often found on current
microprocessors is really needed.

But performance results do show that the larger caches do pay off -
and part of the problem is how current operating systems work; another
part is shorter cycle times that make the cache miss penalty higher.

John Savard

[toc] | [prev] | [next] | [standalone]

#6529

On Friday, April 13, 2012 6:05:40 PM UTC-5, Quadibloc wrote:
> On Apr 12, 10:22 pm, "Andy (Super) Glew" <a...@SPAM.comp-arch.net>
> wrote:
> 
> > Now, many of the supercomputer folks I used to work with think that
> > caches are a waste of power.  I'm not there yet.
> 
> We know from IBM's disappointing results with the STRETCH and the
> 360/91, and its unexpected bonus of performance from the 360/85, that
> caches not only work, but they work well. On most normal computational
> tasks, they make RAM look almost like it is as fast as the more
> expensive and more power-consuming memory used in the cache.
> 
> So caches are anything but a waste in most computers. On the one hand,
> some supercomputers, though, are sometimes used for problems with poor
> locality. On the other hand, the 360/195, for example, got by very
> nicely with 32 Kbytes of cache, and so it might legitimately be asked
> if something like 2 Mbytes of cache as often found on current
> microprocessors is really needed.

360 had the /91 : 370 had the /195

But in both circumstances, main memory was only 10-ish clocks away, at least as wide as the largest primative data type, and heavily banked.

My guess is that if 3+GHz microprocessors had a multibanked main memory only 10-ish clocks away, they could get buy with 32KBytes rather well.

Mitch

[toc] | [prev] | [next] | [standalone]

#6543

On Apr 13, 6:01 pm, MitchAlsup <MitchAl...@aol.com> wrote:

> 360 had the /91 : 370 had the /195

Oh, there _was_ a 360/195. It was announced in 1969. Many of them
ended up being upgraded to 370/195s later.

> But in both circumstances, main memory was only 10-ish clocks away, at least as wide as the largest primative data type, and heavily banked.

> My guess is that if 3+GHz microprocessors had a multibanked main memory only 10-ish clocks away, they could get buy with 32KBytes rather well.

Indeed. So instead we have L1 and L2 cache. And we wish the RAM could
be almost as fast as the L2 cache instead.

John Savard

[toc] | [prev] | [next] | [standalone]

#6531

Quadibloc <jsavard@ecn.ab.ca> writes:
> We know from IBM's disappointing results with the STRETCH and the
> 360/91, and its unexpected bonus of performance from the 360/85, that
> caches not only work, but they work well. On most normal computational
> tasks, they make RAM look almost like it is as fast as the more
> expensive and more power-consuming memory used in the cache.
>
> So caches are anything but a waste in most computers. On the one hand,
> some supercomputers, though, are sometimes used for problems with poor
> locality. On the other hand, the 360/195, for example, got by very
> nicely with 32 Kbytes of cache, and so it might legitimately be asked
> if something like 2 Mbytes of cache as often found on current
> microprocessors is really needed.
>
> But performance results do show that the larger caches do pay off -
> and part of the problem is how current operating systems work; another
> part is shorter cycle times that make the cache miss penalty higher.

this mentions that documents included stuff about Harvest, have
been declassified and available:
http://www.fas.org/irp/news/2011/06/nsa060811.html

a couple recent posts mentioning ACS, and other machines:
http://www.garlic.com/~lynn/2012e.html#38 A bit of IBM System 360 nostalgia
http://www.garlic.com/~lynn/2012e.html#39 A bit of IBM System 360 nostalgia

references several webpages on ACS by Smotherman ... including
this which has lots of supercomputer & 360 minutia
http:/www.cs.clemson.edu/~mark/acs_end.html

the above includes reference to red/blue dual i-stream (aka hyperthread)
design for ACS-360.  Later in the mid-70s, 370/195 group sucked me into
looking at software support for possibly similar (dual i-stream)
implementation (but never came to pass).

in the 370/195 case, peak processing was 10mips ... but conditional
branch instructions drained the pipeline ... so most codes ran at
5mips. thought was two-threads would keep machine running at peak.

other ACS parts including lots of other history thrown in:
http://www.cs.clemson.edu/~mark/acs.html
http://www.cs.clemson.edu/~mark/acs_timeline.html

I've got some old email from somebody relating discussions with people
that had worked for Amdahl in the ACS-360 group ... with references to
"casualties of Amdahl/Bertram and innumerable other ego"

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#6541

Quadibloc wrote:
> locality. On the other hand, the 360/195, for example, got by very
> nicely with 32 Kbytes of cache, and so it might legitimately be asked
> if something like 2 Mbytes of cache as often found on current
> microprocessors is really needed.

Apples and Oranges:

The 2 MB cache in a modern cpu should be compared with 2 MB RAM in an 
old mainframe.

32 KB 360 cache <==> 32 KB L1 cache today.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#6601

In article <13f57392-9259-4e47-825f-fc031c9be857@v17g2000pbt.googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:
>On Apr 12, 10:22 pm, "Andy (Super) Glew" <a...@SPAM.comp-arch.net>
>wrote:
>
>> Now, many of the supercomputer folks I used to work with think that
>> caches are a waste of power.  I'm not there yet.
>
>We know from IBM's disappointing results with the STRETCH and the
>360/91, and its unexpected bonus of performance from the 360/85, that
>caches not only work, but they work well. On most normal computational
>tasks, they make RAM look almost like it is as fast as the more
>expensive and more power-consuming memory used in the cache.
>
>So caches are anything but a waste in most computers. On the one hand,
>some supercomputers, though, are sometimes used for problems with poor
>locality. On the other hand, the 360/195, for example, got by very
>nicely with 32 Kbytes of cache, and so it might legitimately be asked
>if something like 2 Mbytes of cache as often found on current
>microprocessors is really needed.
>
>But performance results do show that the larger caches do pay off -
>and part of the problem is how current operating systems work; another
>part is shorter cycle times that make the cache miss penalty higher.

Benchmarks show this clearly. Just having hyperchannel cache links
on of off can be the difference between 12k telephone calls and barely
600.

-- mrr

[toc] | [prev] | [next] | [standalone]

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

Back to top | Article view | comp.arch

csiph-web