Mail Archives: pgcc/1998/06/29/20:06:45
| X-pop3-spooler: | POP3MAIL 2.1.0 b 4 980420 -bs-
|
| Message-ID: | <19980629155048.25657@cerebro.laendle>
|
| Date: | Mon, 29 Jun 1998 15:50:48 +0200
|
| From: | Marc Lehmann <pcg AT goof DOT com>
|
| To: | beastium <beastium-list AT Desk DOT nl>
|
| Subject: | bzip2-mx vs. bzip2-nomx
|
| Mail-Followup-To: | beastium <beastium-list AT desk DOT nl>
|
| Mime-Version: | 1.0
|
| X-Operating-System: | Linux version 2.1.106 (root AT cerebro) (gcc version pgcc-2.91.37 19980608 (gcc2 ss-980502 experimental))
|
| Status: | RO
|
| Lines: | 36
|
The feedback I received boils down to
bzip2-nomx bzip2-mx slowdown
pii 1.67 1.76 1.6%
amdk6 2.27 2.67 15%
144.77 168.84 14%
14.5 18.0 19% <- this i think is bogus,
judging from the report
cyrix6x86mx 1.75 2.22 21%
pentium-mmx anybody?
thanks for participating. if you look at the machine code, you can see that
bzip2-mx quite heavily uses mmx instructions, but it doesn't use them in the
mmx way but rather as register set extension with limited capabilities
(spill space, addition etc..).
it seems that, with improved scheduling and tuning, speed improvements are
possible, at least on p-ii, where the slowdown is small. my tests indicate
that the mmx unit on p-iis is suprisingly fast and can well execute a number
of mmx instructions in parallel.
this doesn't seem to be the case on k6 or 6x86mx chips, which perform quite
badly :( i believe mmx on these chips is useless for normal code and normal
compilers that cannot take advantage of the parallelisation. I guess thats
true for the pentium-mmx as well (though I have no data)
(maybe I can prove that mmx is just a useless pain in the ass everywhere ;)
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg AT goof DOT com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|
- Raw text -