Hi Michael,

Michael S (already5chosen@yahoo.com) on 2/17/11 wrote:
---------------------------
>>>As far as I understand, "normal" SNB uOps are 2-input-1-output. There are a few
>>>3-input-1-output instructions of which four-operand form of VBLENDPS/VBLENDPD is
>>>by far the most important. According to my understanding, SNB implements 4op VBLENDPx
>>>either by splitting it into two uOps (more likely) or by simultaneous issue of a
>>>single uOP to two execution ports (much less likely). One can conclude by comparison
>>>of latency/throughput of 4op form vs normal 3op+imm form of the same instruction.
>>>Such implementation makes a perfect sense for VBLENDPx since any the alternative
>>>sequence of 2-input instructions [I can think about] is slower in throughput and, at best, equal in latency.
>>>Similar cracked implementation of [3-input] FMA makes much less sense, since it
>>>provides no throughput benefits over alternative sequence 2-input instructions and
>>>while it can offer significant latency benefits they apply only to typically non-critical
>>>multiplicand-to-result path, while often critical latency of adder-input-to-result
>>>path is not improved and likely even worsen.
>>>
>>>Intel could still do it, not because it makes sense, but because they were stupid
>>>enough to announce it publicly (and also because it could be rather efficiently
>>>implemented on Silverthorn-derived cores, that is, if Silverthorn line survive that
>>>long), but I would expect that their implementation will have a throughput of 1 256bit FMA per clock rather than 2.
>>
>>GPUs, Larrabee, and Bulldozer all support 3-input-1-output operations. It's really
>>not that big of a stretch for Intel's CPUs to support dual 256-bit FMA per core.
>
>Core2/NHM and SNB are ALOT faster at "CPU" type of tasks than GPUs and Larrabee
>and likely measurably faster than Bulldozer. Could it be that _not_ supporting 3-inputs uOps is one of the reasons?

I don't see how. Many CPUs support 3-input instructions. For instance Cell BE supports FMA in both the PPEs and SPEs at 3.2 GHz even on a 90 nm process. So on 22 nm Intel should have no trouble supporting FMA.

>>VBLENDPS takes only an 8-bit immediate as fourth operand so how they implemented
>>it is no indication of how "true" 4 operand FMA will be implemented (http://www.x86-secret.com/img/dossier/divers/i
>df2008/hsw-01b.jpg).
>
>BS. Update your manuals.
>Then look at 253666.pdf p.3-86 and 248966.pdf p.C-5

Ah, VBLENDVPS, not VBLENDPS. By bad.

>>Dual 128-bit FMA as you're proposing seems a rather pointless waste of transistors
>>to me.
>
>Please, show me where I proposed Dual 128-bit FMA?

You were talking about splitting VBLEND(V)PS into two micro-operations. I wrongfully interpreted that as two 128-bit operations executed in parallel. I've had a look at the optimization manual now and apparently it's implemented as two uops executed sequentially on the same port.

However, you can't do that with FMA, unless you have execution units with both adders and multipliers and only one operation can be performed. That would be a waste. It seems much more likely to me they'll just feed in the extra operand and double the throughput.

>>Either they'll support dual 256-bit FMA, or they won't support FMA at all.
>
>We will see.

Here an Intel engineer talks about the "raw FLOPS improvement" of FMA: http://software.intel.com/en-us/forums/showthread.php?t=61121

>>And since it has already been annoucned for Haswell, only one option remains.
>
>What exactly was announced?

Nothing official, but some very strong indications. software.intel.com/file/32266: slide 3 puts FMA right next to Sandy Bridge. While that's not definitive, Intel always attempts to keep quiet about instruction support of next generation architectures to maximize the impact on the official announcement.

Note that back in 2008 they placed it in a >2010 timeframe: http://www.cse.scitech.ac.uk/disco/mew19/Presentations/Intel_BillHoran.pdf. Lots of analysts expect FMA to arrive with Haswell. It's all over the web.

>>>Unless, of course, the abandon their brand new SNB microarchitecture after just
>>>one or two generations and move to something significantly different. Which doesn't sound very likely.
>>
>>If you look at the drastic changes between Intel's architectures in the past years,
>>it's not unlikely at all they'll implement 2x256-FMA for Haswell.
>
>Since introduction of PPro more than 15 years ago there were not so many drastic changes in microarchitecture:
>Pii - small evolutionary changes related to addition of MMX and slower L2 cache
>Piii - small evolutionary changes mostly related to addition of SSA
>---------
>WMT - new uArch completely unrelated
>NWD - almost no uArch changes over WMT
>PSC - very significant changes, almost new uArch
>CDM/Tulsa - almost no uArch changes over PST
>-------------
>Banias - significant evolutionary changes over Piii
>Dothan - small evolutionary changes
>Yonah - almost no uArch changes over Dothan
>-------------
>Merom - very big, but still evolutionary changes over Dothan/Yonah
>Penryn - small evolutionary changes over Merom
>Nehalem - significant evolutionary changes in core uArch, mostly related to fully
>reworked L2 and up cache and memory interface
>Westmere - almost no uArch changes over Nehalem
>-----------
>Sabdy Bridge - new uArch, but not completely unrelated to Nehalem/Westmere, despite
>drastic changes in basic OoO engine there is still mostly the same execution ports structure.
>
>So, if we forget P-IV (and Silverthorn) for sake of brevity, and look only at PPro
>linage, there was one very big change (Merom) and one drastic change (SNB) in 15 years.

Adding FMA support isn't that drastic. Again, AMD Bulldozer adds 2 x 128-bit / 1 x 256-bit FMA support per module. While Bulldozer itself could be considered a drastic change, FMA is only part of a much longer list of changes.

The FMA encodings are fully specified so it would be hard to imagine Intel would wait till after Haswell to implement it. Other architectures have had FMA support for years already, including Itanium.

>> The tick-tock
>>model means they revisit the entire architecture every two years anyway. So yes,
>>they'll abandon their brand new SNB architecture after just two generations and
>>move to something significantly different.
>>
>>Note also that the AVX specification reserves an encoding bit to widen it to 512
>>and 1024-bit vectors. It's clear Intel has long-term plans to improve throughput.
>>Else they would not have designated a semantic to that bit already. It's extremely
>>doubtful that both both FMA and this widening bit were specified unintentional.
>
>I said that 2 FMAs per clock are unlikely in mainline Intel CPUs, but never said
>anything against 1 512b FMA per clock. It is possible and sane, although not very likely in the near future.

What would make 2 x 256-bit FMA less likely than 1 x 512-bit FMA?

>BTW, unlike others here, I am not negative on possibility scatter/gather in the mainline CPUs.
>At first glance, I see nothing wrong about general idea. If nothing else, parallel
>multiplication of arbitrary integer offset by arithmetic series of small integers
>seem useful and could be done in hardware very cheaply and much more efficiently
>than in software, where it require clumsy copying between vector and GPR registers.
>So, even if the "memory" part is implemented in microcode or some "cheap" serial
>state machine, it still makes sense in some circimstances.

I agree any improvement over today's serial load/store would be very welcome, including (as a starting point) an implementation which performs sequential extract/insert operations outside of the arithmetic execution units.

>"RISC school" arguments against SG that popped here so far (multiple memory references
>by single instruction are evil, evil, evil, evil), does not look convincing, esp
>in light of Tarantula proposal by Gurus of RISC Ashram themselves.
>But I didn't make an effort of thinking about other downsides, so it's possible that I overlooked something.

Sounds interesting. Do you happen to have some pointers to documents describing this technology? I'm very interested in the viability/tradeoffs of gather/scatter implementations.

Thanks,

Nicolas