From the original SynthMaker forum (2004–2014), with its members’ names and dates.
TomC ·
G'day, I'm currently doing some optimization with my math modules and I've got a question: which of the following code samples would run faster and how much?
streamin in; streamout out;
movaps xmm0,in; mulps xmm0,in; // xmm0 = in^2
streamin in; streamout out;
movaps xmm0,in; mulps xmm0,xmm0; // xmm0 = in^2
With the assumption that mulps xmm0,xmm0; is syntactically correct it should be faster because it's all register computation, right?
Cheers,
Tom
rl ·
right, but according to SM's analyzer module there is no measurable difference.
infuzion ·
rl wrote: right, but according to SM's analyzer module there is no measurable difference.
I never noticed that output; thanks rl! It will save latency for sure, which also has to be considered.
oddson ·
Sorry to go slightly off-topic here... but does anyone else find it strange the Signal Analyzer primitive is not in the 'Analysis' group?
stefan ·
infuzion wrote: rl wrote: right, but according to SM's analyzer module there is no measurable difference.
I never noticed that output; thanks rl! It will save latency for sure, which also has to be considered.
Just a FYI for other readers, infuzion is not talking about audio latency! 😉 Anyhoo, it might very well be that the CPU puts the variable in the cache, making the mul using the variable instead of a register about as fast as using just registers.
infuzion ·
stefan wrote: Just a FYI for other readers, infuzion is not talking about audio latency! 😉 Anyhoo, it might very well be that the CPU puts the variable in the cache, making the mul using the variable instead of a register about as fast as using just registers.
Yes, on this page latency = CPU latency.
Seems that variable vs register usage may be just as "fast" due to adding & multipling using one set of CPU "ports", while moving a variable into the operation (like for mulps xmm0,in;)uses a third port, so it doesn't interfere with the + or *. Intel®64 and IA-32 Architectures Optimization Reference Manual Order Number: 248966-014 November 2006 wrote: C.3.3 Latency and Throughput with Memory Operands Typically, instructions with a memory address as the source operand, add one more op to the “reg, reg” instructions. However, the throughput in most cases remains the same because the load operation utilizes port 2 without affecting port 0 or port 1.
Many instructions accept a memory address as either the source operand or as the destination operand. The former is commonly referred to as a load operation, while the latter a store operation.
The latency for instructions that perform either a load or a store operation are typically longer than the latency of corresponding register-to-register type of the same instructions. This is because load or store operations require access to the cache hierarchy and, in some cases, the memory sub-system.
For the sake of simplicity, all data being requested is assumed to reside in the first level data cache (cache hit). In general, instructions with load operations that execute in the integer ALU units require two more clock cycles than the corresponding register-to-register flavor of the same instruction. Throughput of these instructions with load operation remains the same with the register-to-register flavor of the instructions.
Floating-point, MMX technology, Streaming SIMD Extensions and Streaming SIMD Extension 2 instructions with load operations require 6 more clocks in latency than the register-only version of the instructions, but throughput remains the same.
stefan ·
If I understand it correctly, they state that the throughput (what you called speed) is the same but the latency is higher.
infuzion ·
stefan wrote: If I understand it correctly, they state that the throughput (what you called speed) is the same but the latency is higher.
Yes. So in the end, we should worry about speed, not latency? What is more important, or where could latency get us in trouble? I'm getting 😕
stefan ·
infuzion wrote: stefan wrote: If I understand it correctly, they state that the throughput (what you called speed) is the same but the latency is higher.
Yes. So in the end, we should worry about speed, not latency? What is more important, or where could latency get us in trouble? I'm getting 😕
Both are important. Most of the common SSE instructions executes in 1 cycle, which means that speed is of no consideration there, but the latency if these are. Speed is an issue in the more uncommon ones (haven't got a reference manual at hand though).
Latency "gets you in trouble" in situations like...
x = a / b; y = x * b; z = a * c;
the second statement has to wait until the first is calculated. You can get around that to some extent by moving stuff around:
x = a / b; z = a * c; y = x * b;
now, instead of waiting, the CPU goes ahead and executes a * c while a / b is being calculated.
infuzion ·
stefan wrote: now, instead of waiting, the CPU goes ahead and executes a * c while a / b is being calculated.
Thanks! I was just now thinking I'll have to re-recode some of my ASM to re-rearrange some computation.
stefan ·
infuzion wrote: stefan wrote: now, instead of waiting, the CPU goes ahead and executes a * c while a / b is being calculated.
Thanks! I was just now thinking I'll have to re-recode some of my ASM to re-rearrange some computation.
Also something one can take into consideration even when not doing ASM coding.
TomC ·
infuzion wrote: Intel®64 and IA-32 Architectures Optimization Reference Manual Order Number: 248966-014 November 2006 wrote: C.3.3 Latency and Throughput with Memory Operands
Great info
Do you know if that reference manual is available online somewhere or do I have to order it from Intel?
Cheers,
Tom
infuzion ·
TomC wrote: infuzion wrote: Intel®64 and IA-32 Architectures Optimization Reference Manual Order Number: 248966-014 November 2006 wrote: C.3.3 Latency and Throughput with Memory Operands
Great info
Do you know if that reference manual is available online somewhere or do I have to order it from Intel?
I can send it to you for the great low price of
TomC ·
infuzion wrote: TomC wrote: infuzion wrote: Intel®64 and IA-32 Architectures Optimization Reference Manual Order Number: 248966-014 November 2006 wrote: C.3.3 Latency and Throughput with Memory Operands
Great info
Do you know if that reference manual is available online somewhere or do I have to order it from Intel?
I can send it to you for the great low price of
Muchas gracias!
Tom
infuzion ·
TomC wrote:
infuzion wrote: I can send it to you for the great low price of
Muchas gracias!
bitte schon!
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker