lkml.org 
[lkml]   [1997]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: MMX performance....
    On 6 Feb 1997, Robert Krawitz wrote:

    > In article <Pine.LNX.3.95.970206153658.11525D-100000@pc5829.hil.siemens.at> Ingo Molnar <mingo@pc5829.hil.siemens.at> writes:
    >
    > On Thu, 6 Feb 1997, Dale R. Worley wrote:
    >
    > > From what I understand, everytime you switch between MMX mode and regular
    > > FP mode, 100 or so cycles are burned. If you are context switching
    > > alot (any multitasking enviornment), this would seem to add up.
    > >
    > > Assuming that the "cycles" are fundamental CPU cycles (as opposed to
    > > memory accesses, or something), that could take 1 microsecond or less
    > > (depending on your clock speed), which isn't much. [...]
    >
    > 2.1.25 does a system call in 150 cycles and context switches in 190 cycles
    > microseconds. Wanna add 100 cycles to each memory copy operation?
    >
    > 100 cycles are alot. And XFree86 is rendering fonts using the FPU. And we
    > have the pentium memcpy patch which uses the FPU for 64 bit wide memory
    > copy.
    >
    > Hmm. I haven't had a chance to look at the MMX instruction set, but
    > I'll be shocked, SHOCKED, if the MMX instruction set doesn't have 64
    > bit memory transfer instructions. Perhaps a logical alternative would
    > be to implement the Pentium memcpy in terms of whichever FPU/MMX mode
    > was in effect at the time.

    I'd be shocked as well. Most of the core instruction times are listed as
    1, and from what I can tell, it's just a hack on the already existing
    functional units in the FPU, taking advantage of the fast multiplier, etc.

    > The Pentium memcpy() patch, BTW, has a lot of overhead of its own; it
    > dumps and restores the FPU state (when it's in use it dumps the
    > registers; when not, it dumps just the rest of the state). That's why
    > it's configured to operate only when the amount of data to be copied
    > is large. The overhead is well worth it, though, since memory
    > bandwidth on write is used so much more efficiently.

    What's the break-even copy size? Your patch seems to suggest 512 or 1024
    bytes.

    --
    "Love the dolphins," she advised him. "Write by W.A.S.T.E.."



    \
     
     \ /
      Last update: 2005-03-22 13:38    [W:0.019 / U:69.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site