Quote:Original post by Washu
Eh, lets leave singletons out of this.

Quote:Original post by discman1028
So I am still adamant about the unusefulness of the *ss() operations.

Quote:Original post by discman1028

Quote:Original post by Washu
Eh, lets leave singletons out of this.

But I take your side! :)

Quote:Original post by discman1028
So I am still adamant about the unusefulness of the *ss() operations.

Hmmm maybe I lied, they could be of some use. Maybe you could store your W component (or any component), by convention*, of your vector4 in the [0] position. Then you could modify W by the [0] component of any other vector4 without affecting the X,Y,Z components. I'm not sure if that's why SSE chose to include those instructions, but it's one valid use I hadn't thought of.

The same thing could be done in any vector architecture, but you would have to generate a mask vector like <0xFFFFFFFF,0,0,0> in order to apply the change to the [0] component only.

Just trying to think of ways to use the darn things... :)

*by convention b/c if you shuffle, then perform, than shuffle back, you could have just done a packed operation, then shuffled the result and the original together to create the desired result, saving one instruction.

Quote:Original post by Washu
I added stuff to my post, you should read it again.

Quote:Original post by Washu
Also, the SS instructions allow you to operate on single floats throughout, thus avoiding the almost FPU entirely (not all functionality is replicated). Due to the number of SSE registers this allows for significantly more parallel calculation capabilities than the FPU can perform, typically. Especially since the destination can be seperated from the source, something that the FPU stack isn't so great at :)

Quote:Original post by Washu
One of the intel reference manuals relating to optimizing code for the Core2Duo platform.

Quote:
Execution of SIMD instructions on Intel Core Solo and Intel Core Duo processors are
improved over Pentium M processors by the following enhancements:
-- Micro-op fusion — Scalar SIMD operations on register and memory have single
μop flows comparable to X87 flows. Many packed instructions are fused to reduce
its μop flow from four to two μops.

...

Quote:
3.8.4 x87 vs. Scalar SIMD Floating-point Trade-offs
===================================================
There are a number of differences between x87 floating-point code and scalar
floating-point code (using SSE and SSE2). The following differences should drive
decisions about which registers and instructions to use:
-- When an input operand for a SIMD floating-point instruction contains values that
are less than the representable range of the data type, a denormal exception
occurs. This causes a significant performance penalty. An SIMD floating-point
3-85
GENERAL OPTIMIZATION GUIDELINES
operation has a flush-to-zero mode in which the results will not underflow.
Therefore subsequent computation will not face the performance penalty of
handling denormal input operands. For example, in the case of 3D applications
with low lighting levels, using flush-to-zero mode can improve performance by as
much as 50% for applications with large numbers of underflows.
-- Scalar floating-point SIMD instructions have lower latencies than equivalent x87
instructions. Scalar SIMD floating-point multiply instruction may be pipelined,
while x87 multiply instruction is not.
-- Only x87 supports transcendental instructions.
-- x87 supports 80-bit precision, double extended floating point. SSE support a
maximum of 32-bit precision. SSE2 supports a maximum of 64-bit precision.
-- Scalar floating-point registers may be accessed directly, avoiding FXCH and topof-
stack restrictions.
-- The cost of converting from floating point to integer with truncation is significantly
lower with Streaming SIMD Extensions 2 and Streaming SIMD Extensions
in the processors based on Intel NetBurst microarchitecture than with either
changes to the rounding mode or the sequence prescribed in the Example 3-45.
Assembly/Compiler Coding Rule 63. (M impact, M generality) Use Streaming
SIMD Extensions 2 or Streaming SIMD Extensions unless you need an x87 feature.
Most SSE2 arithmetic operations have shorter latency then their X87 counterpart
and they eliminate the overhead associated with the management of the X87
register stack.

Quote:
3.8.4.1 Scalar SSE/SSE2 Performance on Intel Core Solo and Intel Core
Duo Processors
===================================================
On Intel Core Solo and Intel Core Duo processors, the combination of improved
decoding and μop fusion allows instructions which were formerly two, three, and four
μops to go through all decoders. As a result, scalar SSE/SSE2 code can match the
performance of x87 code executing through two floating-point units. On Pentium M
processors, scalar SSE/SSE2 code can experience approximately 30% performance
degradation relative to x87 code executing through two floating-point units.

Quote:
6.4 SCALAR FLOATING-POINT CODE
===================================================
There are SIMD floating-point instructions that operate only on the least-significant
operand in the SIMD register. These instructions are known as scalar instructions.
They allow the XMM registers to be used for general-purpose floating-point computations.
In terms of performance, scalar floating-point code can be equivalent to or exceed
x87 floating-point code and has the following advantages:
-- SIMD floating-point code uses a flat register model, whereas x87 floating-point
code uses a stack model. Using scalar floating-point code eliminates the need to
use FXCH instructions. These have performance limits on the Intel Pentium 4
processor.
-- Mixing with MMX technology code without penalty.
-- Flush-to-zero mode.
-- Shorter latencies than x87 floating-point.

Quote:Original post by outRider
3) If you need cmov or fcmov and can't get the compiler to generate it for you, do it yourself with some inline assembly and hope the compiler doesn't do anything stupid trying to get your operands into the right registers.