Messages in this thread | | | Date | Tue, 10 Nov 2009 21:16:02 +0100 | From | Willy Tarreau <> | Subject | Re: i686 quirk for AMD Geode |
| |
On Tue, Nov 10, 2009 at 12:01:47PM -0800, H. Peter Anvin wrote: > On 11/10/2009 11:50 AM, Avi Kivity wrote: > >> > >> Consider SSE3, for example. Why should the same concept not apply to > >> SSE3 instructions as to CMOV? > > > > Because then user programs would run 20x or more slower than the user > > expects. Better to terminate early (and teach userspace how to choose > > the instruction subset correctly). > > > > I picked the example carefully: SSE3 is a small set of instructions > which probably aren't used very heavily. In that sense, it has > *exactly* the same properties as CMOV - if you have the source, you're > better off recompiling, but it *might* help you if you happen to only > have a binary. > > What I want people to understand is that this is a *huge* rathole, and > it doesn't have any obvious bottom that I can see.
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.
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.
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).
Regards, Willy
| |