Messages in this thread | | | Date | Fri, 19 Jun 1998 05:43:50 -0700 | From | "David S. Miller" <> | Subject | Re: f@#$ing MMX emulator |
| |
Date: Fri, 19 Jun 1998 14:26:51 +0200 From: Erik Corry <erik@arbat.com>
In article <19980619162224.C118@caffeine.ix.net.nz> you wrote: > On Thu, Jun 18, 1998 at 09:00:46PM -0700, David S. Miller wrote: >> Not totally true, as Ingo has shown doing IP checksums on MMX was not >> significantly different in complexity from doing it on Sparc VIS.
Doesn't give much benefit, though, according to Mingo http://x2.dejanews.com/getdoc.xp?AN=362293483
"but for most RL MTU's the FPU save/restore operation eats a considerable amount of the saved cycles"
Sore point, because this initially was our problem on sparc64 VIS, and this gap closed up once we implemented smart FPU saving throughout the sparc64 port. Now it's a non-issue and the FPU isn't save in most cases even under high interrupt and overall load.
Read what Ingo says as "It's fast, but it doesn't show because of problem XXX." and so we should look for a solution for XXX before just tossing in the towel about this idea.
"this MMX ISA extension thing is not worth to be generated by a compiler, it's only worth to make it's way into a few very specialized assembly functions"
Any program that wants to be portable needs a C version of any MMX code. This is going to be 1000 times faster than the emulated MMX version, and it is by definition performance- critical code. There's no point in emulating MMX.
True and these cases are where you can use the dynamic binding facilities of procedure calls available in userland or the kernel. For example, based upon hw capability flags glibc ld.so could decide to bind memcpy() to an MMX optimized version on capable cpu's. In fact the infrastructure for this is %95 in glibc right now.
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |