11/28   Let's talk about virtual memory:
\__ if you'r edealing with virtual memory which
   far exceeds physical memory, you've already lost.
        \_ if you'r edealing with virtual memory which far exceeds
        \_ First of all, the guy is talking about
           number crunching, not image processing.
           It is likely that he's going to be
           addressing all of the memory he's
           crunching with.  And second, no one said
           it was impossible--it just is painfully
           slow.  disk is like 6 orders of magnitude
           slower than RAM.
           \_ uhh. "number crunching" applications
              usually exhibit greater locality
              than almost any other app, if
              optimized properly. -nick
                \_ which will help not at all if
                   it's using more than physical RAM.
                   \_ What part of "locality" don't
                      you understand, twink?  Nick knows
                      what he's talking about.
                   \_ Whether you can get away with crunching >> than RAM
                      depends strongly on the precise task.  A blocked
                      matrix multiply might perform well, especially if
                      you somehow anticipate the data needed next and
                      stream it into RAM beforehand so you don't have to
                      eat the large latency while it is paged in.....
                      Having a RAID array (expensive) also helps.
                      A non-sparse matrix-vector multiply, however, requires
                      1 memory reference for every 2 flops (not counting the
                      memory reference for the vector element).
                      memory reference for the vector element or result).
                      Assuming .5 flop per tick on a 400MHz P-II, we'd need
                      floats from the matrix at 100MHz, or 400MB/sec.
                      SDRAM might sustain that, but if the matrix were
                      SDRAM might sustain that, but if the matrix were much
                      larger than memory....  Performance would drop 10x
                      at least.  --PeterM
                      \_ I don't think ILP is heavily influenced by how
                         much a process' virtual memory compares to the
                         physical memory.  Virtual memory pages are usually
                         on the order of 64kb.  Compare that to, say, a Cray
                         vector register file which is a 32x32 64bit matrix.
                         That's 8kb and it takes several clock cycles for
                         a number crunching program to process the data in
                         the 64kb page anyway.  But this guy is talking about
                         a Pentium and a K6 to do number crunching.  I don't
                         think he's going to benefit from that kind of ILP
                         and even if he did he would still benefit from
                         the spatial and temporal locality of the program.
           physical memory, you've already lost.
           (\_ This has pretty much been my experience--PeterM )
               \_ First of all, the guy is talking about number
                  crunching, not image processing.  It is likely that
                  he's going to be addressing all of the memory he's
                  crunching with.  And second, no one said it was
                  impossible--it just is painfully slow.  disk is like 6
                  orders of magnitude slower than RAM.
                  \_ uhh. "number crunching" applications usually
                     exhibit greater locality than almost any other app,
                     if optimized properly. -nick
                     \_ which will help not at all if it's using more
                        than physical RAM.
                        \_ What part of "locality" don't you understand,
                           twink?  Nick knows what he's talking about.
                           \_ Whether you can get away with crunching >>
                              than RAM depends strongly on the precise
                              task.  A blocked matrix multiply might
                              perform well, especially if you somehow
                              anticipate the data needed next and stream
                              it into RAM beforehand so you don't have
                              to eat the large latency while it is paged
                              in.....  Having a RAID array (expensive)
                              also helps.  A non-sparse matrix-vector
                              multiply, however, requires 1 memory
                              reference for every 2 flops (not counting
                              the memory reference for the vector
                              element or result).  Assuming .5 flop per
                              tick on a 400MHz P-II, we'd need floats
                              from the matrix at 100MHz, or 400MB/sec.
                              SDRAM might sustain that, but if the
                              matrix were much larger than memory....
                              Performance would drop 10x at least.
                              --PeterM
                              \_ I don't think ILP is heavily influenced by
                                \_ ILP ==> "Instruction Level Parallelism"
                                   I don't understand why you mention it
                                   here.  --PeterM
                                   \_ You mentioned vector ops which is a
                                      form of instruction level parallelism.
                              how much a process' virtual memory
                              compares to the physical memory.  Virtual
                              memory pages are usually on the order of
                              64kb.  Compare that to, say, a Cray vector
                              register file which is a 32x32 64bit
                              matrix.  That's 8kb and it takes several
                              clock cycles for a number crunching
                              program to process the data in the 64kb
                              page anyway.  But this guy is talking
                              about a Pentium and a K6 to do number
                              crunching.  I don't think he's going to
                              benefit from that kind of ILP and even if
                              he did he would still benefit from the
                              spatial and temporal locality of the
                              program.