lkml.org 
[lkml]   [1997]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: MMX performance....
Date
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.

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.
--
Robert Krawitz <rlk@tiac.net> http://www.tiac.net/users/rlk/

Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Tall Clubs International -- http://www.tall.org/ or 1-800-521-2512

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2011 Jasper Spaans