>I found some decent info on Intel's site finally. I'll take a whack
>at an MMX enhanced bzero, I am unsure of the correctness, heck, I
>don't even know if my assembler would take it. This is to bzero a
>single memory page via writing a 64bit amount to RAM.
>
> MOV ESI, [memory location]
> PXOR MM0, MM0
> MOV CX, 512
>begin:
> MOVQ ESI:[0], MM0
> ADD ESI, 8
> LOOPNZ begin
> EMMS
I just write also a memcpy that works using 64bit transfer using MMX and
it gain a improvement of more than x2 on large array (some megabyte). I
never tried it in the kernel also thinking that in the kernel the most of
memcpy works on little array and not always multiple of 8 byte so the
improvement should be minor.
Here the result with two different bufsize:
andrea@arca:~/devel/mmx/memcpy$ ./memcpy
BUFSIZE = 65536
memcpy from libc
time elapsed: 1568 ms
memcpy in linux/include/asm/string.h of 2.1.89
time elapsed: 1360 ms
memcpyby8 developed by Andrea Arcangeli using MMX
time elapsed: 737 ms
andrea@arca:~/devel/mmx/memcpy$ ./memcpy
BUFSIZE = 1024
memcpy from libc
time elapsed: 23 ms
memcpy in linux/include/asm/string.h of 2.1.89
time elapsed: 5 ms
memcpyby8 developed by Andrea Arcangeli using MMX
time elapsed: 7 ms
As you can see seems that for small array the performance drops (even if I
can' t realize why...).
I am not sure if we must save and restore the fpu state before and then
using MMX if we run in the kernel. Must the state of the fpu be preserved
after a call (asm in general) or a syscall (kernel)?
Andrea[s] Arcangeli
begin 644 memcpy.c.gz
M'XL("-.4!C4"`VUE;6-P>2YC`*5436^;0!`]L[]B2DH%A,3&L2HKQ#U4:J5*
M42]5+JTKA&%QMF)W75@[)57^>V?XLF-'4:)R86?F[<SN>_!.A$J+3<;AJC*9
MT.>W']C)+E57(R,DIRP[R7@N%(>/-Y^_??G^"<+Q9`H^O)\R5IERDQH@Z#8I
MP&PC5FBU@B7/=<F#)#>\C%AZFY3@ZU*L`O`S7IF(L:T6&91\)2J$Q-3`I93'
M_C)KQ0TE=)XEM?O.;`/X>G-][47,:OO"'">=FVU<\=0/Q\T#IUUN@\D(8.2#
MQ!7X(_;03:MN]=W!)*$,B.BYB<T57CG06I?8.'=MZ@F\2-85SR[!*3*$+)0=
M0-/UK+T-3<$WN&(^CL15QW(D3D\]9N$9+9^3]$#_AS1R(0%QBT1H&\;+$
M#D+!LC8<U$8N\=!.%M"=-SAVR<'Y`XG*0%2XHC.(H.L9]`WQ'%:WQ@N?A1@_
M$'E"%21_PZ$/<2RY3-=UO*RG;I<S.H!4J\KTH+S4$H>+>QX;4$1U+W6','*-
M,[K]GM'1#D":9!LIZS!H7I.(Q7%2R3C&V5M=)$84'`.76?9"A9<+(_6V`->9
M>($S7JB%L;&29%D!;Z>!,^DS#<H9!ZX3>D>HL,]D/$7411_^4O<0+G%U:<]+
M&]SV8%X`;8C7&-9TYR%H3^X!;0QWP,D>[@+7:C3U"(*4ZK*V/:+!;$J%&S0&
MSY$_>P7YUC&YR+Z"$<Q0Y*?9[?A";AR>TA=#WQLTC]V1_AN(2P1(V?,^0)IR
M4PE(F<-R2_QL)]AQ)3RL%%JO&SD."US*:B_NI$(&'TFS#Q@/]7!/D4&X1]A.
M&ZPC#R21=:R1`9D(=>0KS*)_C#[TU@(]A!6%3MW>2OU&)IV[C3MZU)S^P!?M
M(*#WM'G`&81H(/-9YR"]>\P;LSO^R0<?Z??/T3S()+JXO?2^5U.F_11=ZM9X
;R3YZY[5/[WWD(O_;8?:"#@_L'XJO"E;Q!@``
`
end
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu