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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox