DOS ain't dead - Incredibly slow MMX?

Incredibly slow MMX? (Developers)

posted by Rugxulo , Usono, 09.03.2009, 00:33

> I write another routine for testing MMX. It is darkening procedure for
> sprite (again for 16 bpp mode). Without MMX is it quite complicated and
> MMX is here a better speed gain.
>
> I figured that MMX access to VRAM is much slower than 386 access to VRAM.
>
> So, never use MMX for direct VRAM output. It is always better to draw into
> RAM buffer and then result copy into screen.

Is it possible that you can only issue a handful of MMX operations per cycle? Or that they take a long time to complete? I mean, you're basically using the FPU decoder unit (or whatever). I assume AMD's FPU finally caught up to Intel's pipelined 587 with the Athlon. Still, there is always a bottleneck, so maybe you hit it.

And maybe your issue is the EMMS (although FEMMS is disallowed on Intel and possibly a no-op on Athlon or newer). Or it could be the overhead from FNSAVE / FNRSTOR, perhaps? Are you or the compiler doing other FPU-related stuff? Have you tried in pure DOS without the context switches of multitasking?

Post reply

Complete thread:

Incredibly slow MMX? - Laaca, 02.03.2009, 21:15 (Developers)
- Incredibly slow MMX? - Rugxulo, 04.03.2009, 03:01
  - Incredibly slow MMX? - Laaca, 04.03.2009, 13:26
    - Incredibly slow MMX? - Rugxulo, 04.03.2009, 23:50
- Incredibly slow MMX? - Japheth, 04.03.2009, 17:55
  - Incredibly slow MMX? - Laaca, 08.03.2009, 22:04
    - Incredibly slow MMX? - Rugxulo, 09.03.2009, 00:33
    - Incredibly slow MMX? - mht, 21.03.2009, 12:57
- Incredibly slow MMX? - DOS386, 22.03.2009, 06:11