From: "H. Peter Anvin" <hpa@zytor.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Avi Kivity <avi@redhat.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Pavel Machek <pavel@ucw.cz>, Matteo Croce <technoboy85@gmail.com>,
Sven-Haegar Koch <haegar@sdinet.de>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: i686 quirk for AMD Geode
Date: Tue, 10 Nov 2009 12:25:02 -0800 [thread overview]
Message-ID: <4AF9CC1E.2050700@zytor.com> (raw)
In-Reply-To: <20091110201602.GA26633@1wt.eu>
On 11/10/2009 12:16 PM, Willy Tarreau wrote:
>
> Indeed, but there is a difference between [cmpxchg, bswap, cmov, nopl]
> on one side and [sse*] on the other : distros are built assuming the
> former are always available while they are not always. And the distro
> which make the difference have to provide an dedicated build for earlier
> systems just for compatibility. SSE*, 3dnow* etc... are only used by a
> handful of media players/converters/encoders which are able to detect
> themselves what to use and already have the necessary fallbacks because
> these instruction sets vary too much between processors and vendors.
>
That is increasingly not true since gcc is now doing autovectorization.
> One could argue that cmpxchg/bswap/xadd are supported by 486 and that
> implementing them for 386 is almost useless now (though it costs almost
> nothing to provide them, I did a few years ago).
>
> CMOV/NOPL are rarely used, thus have no reason to cause a massive
> performance drop, but are frequent enough (at least cmov) for almost
> any program to have at least one or two inside, making it incompatible
> with a given processor, and are almost obvious to implement too.
I could 970 cmovs in libc out of 322660 instructions. That is one in
333 instruction. In other words, a trap-and-emulate of some 500 cycles
would add some two cycles *per instruction* during execution -- hardly
an insignificant number. All in all, any of this is really only useful
as a limp.
> SSE*/3dnow* would be much much harder and would only serve very few
> programs, and serve them badly because when they're used, it would
> be intensive.
>
> I personally am not against being able to emulate every optional
> instruction, quite the opposite instead. It's just that if in order
> to do this, we add cost to the other obvious ones, we lose what we
> expected to win (simplicity and efficiency).
I don't see any particular subset as being more obvious than the other,
with the *possible* exception of NOPL, simply because NOPL was
undocumented for so long.
-hpa
next prev parent reply other threads:[~2009-11-10 20:32 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-03 2:12 i686 quirk for AMD Geode Matteo Croce
2009-10-03 2:34 ` H. Peter Anvin
2009-10-03 3:08 ` Matteo Croce
2009-10-03 2:35 ` H. Peter Anvin
2009-10-03 7:21 ` Ingo Molnar
2009-10-03 9:53 ` Matteo Croce
2009-10-03 14:12 ` H. Peter Anvin
2009-10-03 14:56 ` Matteo Croce
2009-11-06 14:59 ` Matteo Croce
2009-11-06 16:44 ` H. Peter Anvin
2009-11-06 22:18 ` Matteo Croce
2009-11-07 0:49 ` Alan Cox
2009-11-08 17:37 ` Pavel Machek
2009-11-08 17:40 ` Matteo Croce
2009-11-08 18:10 ` Pavel Machek
2009-11-08 18:13 ` Matteo Croce
2009-11-08 19:29 ` Sven-Haegar Koch
2009-11-08 19:36 ` Pavel Machek
2009-11-08 19:47 ` Matteo Croce
2009-11-08 19:51 ` Pavel Machek
2009-11-08 20:08 ` Alan Cox
2009-11-10 5:27 ` Willy Tarreau
2009-11-10 6:02 ` H. Peter Anvin
2009-11-10 10:41 ` Avi Kivity
2009-11-10 10:56 ` Alan Cox
2009-11-10 17:08 ` H. Peter Anvin
2009-11-10 17:24 ` Alan Cox
2009-11-10 18:49 ` H. Peter Anvin
2009-11-10 19:50 ` Avi Kivity
2009-11-10 20:01 ` H. Peter Anvin
2009-11-10 20:16 ` Willy Tarreau
2009-11-10 20:25 ` H. Peter Anvin [this message]
2009-11-10 20:34 ` Willy Tarreau
2009-11-10 20:54 ` Pavel Machek
2009-11-10 21:12 ` Willy Tarreau
2009-11-10 21:19 ` H. Peter Anvin
2009-11-10 22:06 ` Willy Tarreau
2009-11-10 22:15 ` H. Peter Anvin
2009-11-10 22:20 ` Ingo Molnar
2009-11-10 22:42 ` Willy Tarreau
2009-11-10 22:47 ` H. Peter Anvin
2009-11-11 5:52 ` Willy Tarreau
2009-11-11 6:15 ` H. Peter Anvin
2009-11-11 6:36 ` Willy Tarreau
2009-11-11 7:57 ` H. Peter Anvin
2009-11-11 9:32 ` Willy Tarreau
2009-11-12 2:23 ` Matt Thrailkill
2009-11-12 5:27 ` Willy Tarreau
2009-11-12 5:31 ` H. Peter Anvin
2009-11-12 5:40 ` Willy Tarreau
2009-11-23 19:27 ` Eric W. Biederman
2009-11-23 19:35 ` H. Peter Anvin
2009-11-23 20:03 ` Eric W. Biederman
2009-11-11 10:03 ` Alan Cox
2009-11-11 8:17 ` Pavel Machek
2009-11-10 22:21 ` Willy Tarreau
2009-11-11 10:21 ` Alan Cox
2009-11-11 10:43 ` Willy Tarreau
2009-11-11 16:15 ` H. Peter Anvin
2009-11-10 22:27 ` Lennart Sorensen
2009-11-10 22:29 ` H. Peter Anvin
2009-11-10 22:34 ` Lennart Sorensen
2009-11-10 22:38 ` H. Peter Anvin
2009-11-10 22:54 ` Lennart Sorensen
2009-11-11 8:03 ` Pavel Machek
2009-11-11 9:35 ` Willy Tarreau
2009-11-10 21:21 ` Matt Thrailkill
2009-11-10 21:26 ` H. Peter Anvin
2009-11-10 22:01 ` Matteo Croce
2009-11-10 22:10 ` Willy Tarreau
2009-11-11 10:54 ` Bernd Petrovitsch
2009-11-12 0:51 ` Daniel Pittman
2009-11-12 1:00 ` H. Peter Anvin
2009-11-10 16:29 ` H. Peter Anvin
2009-11-08 19:46 ` Matteo Croce
2009-11-08 19:50 ` Pavel Machek
2009-11-08 20:41 ` Krzysztof Halasa
2009-11-08 18:42 ` Matteo Croce
2009-11-09 20:16 ` Lennart Sorensen
2009-11-09 21:03 ` Matteo Croce
2009-11-09 21:17 ` H. Peter Anvin
2009-11-09 21:23 ` Lennart Sorensen
2009-11-12 12:18 ` Pavel Machek
2009-11-13 2:03 ` Andres Salomon
2009-11-13 10:50 ` Alan Cox
2009-11-13 16:23 ` Lennart Sorensen
2009-11-13 16:57 ` Alan Cox
2009-11-13 19:24 ` Lennart Sorensen
2009-11-13 21:21 ` Alan Cox
2009-11-16 17:50 ` Lennart Sorensen
2009-11-17 11:59 ` Alan Cox
2009-11-17 14:34 ` Lennart Sorensen
2009-11-17 16:43 ` H. Peter Anvin
2009-11-17 17:10 ` Lennart Sorensen
2009-11-17 16:48 ` Valdis.Kletnieks
2009-11-17 17:25 ` Lennart Sorensen
2009-11-17 17:33 ` H. Peter Anvin
2009-11-17 18:33 ` Lennart Sorensen
2009-11-18 20:21 ` Lennart Sorensen
2009-11-18 20:59 ` H. Peter Anvin
2009-11-18 21:11 ` Lennart Sorensen
2009-11-19 0:41 ` Lennart Sorensen
2009-11-13 5:55 ` Yuhong Bao
2009-11-13 16:24 ` Lennart Sorensen
2009-11-13 13:33 ` Pádraig Brady
2009-11-13 16:25 ` Lennart Sorensen
2009-11-08 17:35 ` Pavel Machek
2009-10-03 18:05 ` Arjan van de Ven
2009-10-03 22:04 ` Matteo Croce
2009-10-03 22:32 ` Gabor Gombas
2009-10-03 22:54 ` Matteo Croce
2009-10-04 7:29 ` Gabor Gombas
2009-10-04 2:25 ` Arjan van de Ven
2009-10-04 14:58 ` Alan Cox
2009-11-09 21:14 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2009-11-06 15:49 Martin Schleier
2009-11-06 15:59 ` Alan Cox
2009-11-06 16:42 ` Matteo Croce
2009-11-06 16:57 ` Martin Schleier
2009-11-06 18:22 ` Alan Cox
2009-11-06 20:06 ` Martin Schleier
[not found] ` <20091106210259.290b281a@lxorguk.ukuu.org.uk>
2009-11-06 22:33 ` Martin Schleier
2009-11-06 23:05 ` Krzysztof Halasa
2009-11-07 0:05 ` Martin Schleier
2009-11-07 10:37 ` Krzysztof Halasa
2009-11-07 11:11 ` Matteo Croce
2009-11-08 2:14 ` H. Peter Anvin
2009-11-08 16:05 ` Andres Salomon
2009-11-08 18:04 ` Matteo Croce
2009-11-08 18:46 ` Andres Salomon
2009-11-08 18:22 ` Matteo Croce
2009-11-08 18:47 ` Andres Salomon
2009-11-10 5:58 ` Willy Tarreau
2009-11-08 22:10 H. Peter Anvin
2009-11-09 0:22 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AF9CC1E.2050700@zytor.com \
--to=hpa@zytor.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=avi@redhat.com \
--cc=haegar@sdinet.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=technoboy85@gmail.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.