I'm convinced it will take three micro-instructions (one to extract the mask, one to perform the actual gather, and one to perform the final blend), with a maximum throughput of one instruction per cycle when all elements are from the same cache line. The micro-op breakdown is obvious considering that Haswell won't support FMA4 and the current vblendv instruction can take three 256-bit source registers thanks to a movmsk micro-instruction which extracts the mask and passes it as an immediate to a vblend micro-instruction.
I'm also expecting Haswell to feature one regular 256-bit load unit and one 256-bit gather unit per core. It needs the extra L1 bandwidth for the FMA instructions, and this setup would allow the gather unit to have a slightly higher latency and thus a reasonably power efficient implementation.
It would be irrational of Intel to aim for anything less. LRBni supports 512-bit gather, and they wouldn't add gather to AVX2 if it wasn't efficient. 2 x 256-bit execution begs for a high performance gather instruction. Also, there's nothing reasonable in between sequential extract/insert, and gathering from one cache line at a time, so it has to be the latter. And lastly note that the coherency rules for the instruction are consistent with such an implementation.
What do you mean? The decoder has no knowledge of the cachelines or pages involved.I think the decoding granularity for gather would be somewhere between 1 uop/cacheline and 1uop/page for the first implementation.
Sandy Bridge already has 2 x 256-bit FP per core. And they're not going to risk letting AMD take the lead by doubling the width of the FlexFPU unit. Furthermore, Larrabee / Knight's Corner has 512-bit units. So why would you think Haswell will take a step back? What configuration do you have in mind instead?Also, there is no reason to believe whatsoever that Haswell will have 2x256b FP hw/core. Quite the contrary.
I mean decoding to 8 load uops and then fusing them before TLB lookup and/or fusing the nearby entries in load queue. Should have explained it better.What do you mean? The decoder has no knowledge of the cachelines or pages involved.
I am counting SB as 1x256 as it does one mul/add per clock.Sandy Bridge already has 2 x 256-bit FP per core. And they're not going to risk letting AMD take the lead by doubling the width of the FlexFPU unit. Furthermore, Larrabee / Knight's Corner has 512-bit units. So why would you think Haswell will take a step back? What configuration do you have in mind instead?
So are you suggesting Haswell will only do one fma per clock?I am counting SB as 1x256 as it does one mul/add per clock.
So are you suggesting Haswell will only do one fma per clock?
It can't be just 8 load uops. You need to extract the index values and insert the loaded elements, so you're looking at 24 uops. But that's no better than what we get today with a sequence of extractps/insertps instructions. Also, vgather takes a mask operand, and writes it back when the instruction gets interrupted, so where exactly would you take that into account?I mean decoding to 8 load uops and then fusing them before TLB lookup and/or fusing the nearby entries in load queue. Should have explained it better.
Having one execution port that can take a 256-bit MAD operation is nowhere near the same as having two ports for a 256-bit ADD and a 256-bit MUL. The latter can be turned into two 256-bit MAD ports by adding a third source operand, while the former would require an additional execution port, scheduler, bypass network, higher decoding rate, etc. Sandy Bridge already has the two 256-bit execution ports, so it's not a huge step to make it capable of two 256-bit MAD operations.I am counting SB as 1x256 as it does one mul/add per clock.
Haswell chips will most likely range from 2 to 8+ cores, and 15 to 130 Watt TDP. Just because 22 nm Tri-Gate enables much lower power consumption at low voltage and frequency for the ultrabook market, doesn't mean it's not intended to outperform Sandy Bridge for the desktop and laptop market!Haswell was designed with low power in mind above all else. There's now way they are throwing lots of FP hw at it.
Bulldozer has two 128-bit MAD units per module. Turning this into two 256-bit units at the next process shrink is even simpler than what Intel has to do design wise to get there. Also last time I checked Intel doesn't have any 16-core CPUs for 523 dollar, nor any 8-core for 266 dollar, nor any 6-core for 130 dollar. So it would be a bad mistake to underestimate AMD at this point.AMD is in no position to compete. Intel has known this for ~5 years now.
That would mean Bulldozer outperforms it at legacy 128-bit SSE code. Not gonna happen.I'd be surprised if it did more.
That much seems fair. But what about the TLB lookups?It can't be just 8 load uops. You need to extract the index values and insert the loaded elements, so you're looking at 24 uops. But that's no better than what we get today with a sequence of extractps/insertps instructions. Also, vgather takes a mask operand, and writes it back when the instruction gets interrupted, so where exactly would you take that into account?
Instead of splitting it at the decoder and fusing in the load unit, it's much simpler and more efficient to just split in the load unit, when required. First a vmovmskps uop extracts the mask, which is sent to the load unit together with the full VSIB data by the actual vgather uop. The load unit computes the virtual address of the first element in the mask, and checks which other elements access the same cache line. It queues this cache line fetch and the offsets for each of the elements it wants, and updates the mask. If there are remaining elements, in the next clock cycle the load unit computes the virtual address of the next element in the mask, and again check which other elements access the same cache line and queues it. This is repeated till all the elements are, well, gathered. The third uop writes back the result with a vblend operation.
What about the actual area/power of the multipliers and adders? What about the 2x throughput of L1 and L2? The effort involved is more than the encoding space for the third operand.Having one execution port that can take a 256-bit MAD operation is nowhere near the same as having two ports for a 256-bit ADD and a 256-bit MUL. The latter can be turned into two 256-bit MAD ports by adding a third source operand, while the former would require an additional execution port, scheduler, bypass network, higher decoding rate, etc. Sandy Bridge already has the two 256-bit execution ports, so it's not a huge step to make it capable of two 256-bit MAD operations.
It's 2 to 4 cores, from 15 to 95W.Haswell chips will most likely range from 2 to 8+ cores, and 15 to 130 Watt TDP. Just because 22 nm Tri-Gate enables much lower power consumption at low voltage and frequency for the ultrabook market, doesn't mean it's not intended to outperform Sandy Bridge for the desktop and laptop market!
That would mean Bulldozer outperforms it at legacy 128-bit SSE code. Not gonna happen.
No difference there. The load unit issues one cache line fetch per cycle.That much seems fair. But what about the TLB lookups?
Again, GPUs sustain very high throughput per Watt. So why would it be all that hard to equip a CPU with similar wide SIMD units and keep power consumption in check? Also don't forget the impressive characteristics of 22 nm Tri-Gate, which will have fully matured by the time Haswell hits the streets.What about the actual area/power of the multipliers and adders? What about the 2x throughput of L1 and L2? The effort involved is more than the encoding space for the third operand.
I'm not.It's 2 to 4 cores, from 15 to 95W.
I am ignoring the equivalent of Haswell-E.
As far as I've gathered it's a wash. Sometimes having two MAD units helps because you can also execute two multiplies or two additions simultaneously, instead of just one multiplication and one addition. But Bulldozer suffers from high latencies.Doesn't BD lose to SB for SSE codes today?
Haswell adds FMA support. The way to do that and not make it slower than Bulldozer or Sandy Bridge, is by having two 256-bit MAD units.Will leaving FP alone somehow slowdown Haswell?
That is just dodging the question.Again, GPUs sustain very high throughput per Watt. So why would it be all that hard to equip a CPU with similar wide SIMD units and keep power consumption in check? Also don't forget the impressive characteristics of 22 nm Tri-Gate, which will have fully matured by the time Haswell hits the streets.
I'm not.
What's wrong with 1x256b MAD?Haswell adds FMA support. The way to do that and not make it slower than Bulldozer or Sandy Bridge, is by having two 256-bit MAD units.
Intel also tends to make $$$, not lose it.Nick said:Also last time I checked Intel doesn't have any 16-core CPUs for 523 dollar, nor any 8-core for 266 dollar, nor any 6-core for 130 dollar. So it would be a bad mistake to underestimate AMD at this point.
MUL + FMA doesn't make sense imho, if anything I'd suspect it would be ADD + FMA.Two 256-bit FMA pipes per core could be an overkill, but we still don't know anything about the Haswell's load/store pipeline capabilities. Probably Intel could settle for asymmetric ALU design with FMA + MUL "co-issue" organization, or FMA + ADD.
I think what he means if GPU can deal with it with an even worse cache system, there should be a way for CPU.That is just dodging the question.
I just wondering wether it is enough...What's wrong with 1x256b MAD?
No. Read that bit of conversation again.I think what he means if GPU can deal with it with an even worse cache system, there should be a way for CPU.
A CPU can address DLP, at best, as an afterthought when it is designed with serial integer IPC/W above all else in the first place. It needs to delegate that bit to ... ahem ... specialists.I just wondering wether it is enough...
Intel's idea is using vector system in order to reach a high level of DLP to gain high performance.
1x256b FMAD doesn't seen enough....Both NVIDIA's GPUs and AMD's SIMD units (I mean, both GPU and APU) will be highly programmable in 2013.
Oh. I do forgot about INT IPC/W indeed. That does sounds reasonable in many application.No. Read that bit of conversation again.
When I pointed out that the cost of 2nd 256b FMA unit was more the encoding space for third operand, he responded with some thing to do with vectors and GPUs.
That does not in any way address the cost of adding the 2nd FP unit and the business advantage/engineering constraints trade-offs involved in a CPU whose primary design goal is low power.
A CPU can address DLP, at best, as an afterthought when it is designed with serial integer IPC/W above all else in the first place. It needs to delegate that bit to ... ahem ... specialists.
How is that dodging the question? The GF116-400 has 192 FMA ALUs clocked at 1800 Mhz, on 40 nm. So why would it be such a big deal to have a quad-core Haswell with a mere 64 FMA ALUs clocked at 4 Ghz, on 22 nm Tri-Gate? And since Sandy Bridge has two 256-bit ports, we're over half way there already!That is just dodging the question.
For the desktop market there will indeed be few 8-core sales (though more than 1%). But that's not even the point. Haswell is -not- exclusively designed for low power. Tri-Gate enables a massive decrease in power consumption with a modest decrease in clock frequency. But it just as much enables higher performance at the same power consumption. So just because Haswell will be suited for ultrabooks doesn't mean they had to make any compromises for other markets.If the 99% is not able to purchase it, then the 99% is going to care for it. And neither am I.
Everything! All applications using floating-point calculations would suffer. x86 has had dual FP ports since the Pentium Pro, 16 years ago. And even if magically all applications would suddenly use FMA operations, it would still be slower than having a separate adder and multiplier.What's wrong with 1x256b MAD?
