By: David Kanter (dkanter.delete@this.realworldtech.com), November 17, 2010 12:12 pm
Room: Moderated Discussions
someone (someone@somewhere.com) on 11/17/10 wrote:
---------------------------
>David Kanter (dkanter@realworldtech.com) on 11/17/10 wrote:
>---------------------------
>>First of all, I'd like to give a big thank you to the poster who noticed the ISSCC
>>advance program. The paper title regarding Poulson was a great find and well
>in advance of any one else picking it up.
>>
>>I wrote a short piece that contains my thoughts and speculation on the upcoming
>>Poulson microarchitecture. This is relatively well educated speculation, but speculation
>>nonetheless, and it will be interesting to see the presentation and paper in February.
>>
>>In the mean time, here's the article for everyone to enjoy:
>>http://www.realworldtech.com/page.cfm?ArticleID=RWT111710021604
>>
>>As always, comments and questions are welcome.
>>
>>
>>David
>
>I think Atom may be a preview to the type of MT used
>in Poulson. Atom is a two-issue wide in-order design
>that employs SMT. It will try to issue two instructions
>from the primary thread but if it can't it will try to fill in
>the second slot from the secondary thread.
>
>Poulson will likely operate in a similar way but at the
>level of bundles. It will try to issue up to four bundles
>from the primary thread. It will almost always be able to
>issue two bundles but more than that may be rare unless
>the app is recompiled with Poulson scheduling selected.
>The front end will attempt to fill in unused bundle slots
>from the secondary thread.
>
>This is a big win in two ways. The first is with 2 threads
>running current binaries there'll be 2 independent pairs
>of bundles ready to issue the majority of the time when
>both threads are unstalled. The second way is with true
>fine grained thread interleaving (i.e. SMT) stall cycles
>that dominate low ILP workloads can be mitigated to a
>far greater extent than Montecito/Tukwila's high switch
>penalty SoeMT ever could.
Yes, that was along the lines of what I was thinking for a dynamic thread management policy (i.e. done in HW). Of course, Intel might also leave that up to the software...which would be stupid, but also more philosophically consistent with EPIC.
David
---------------------------
>David Kanter (dkanter@realworldtech.com) on 11/17/10 wrote:
>---------------------------
>>First of all, I'd like to give a big thank you to the poster who noticed the ISSCC
>>advance program. The paper title regarding Poulson was a great find and well
>in advance of any one else picking it up.
>>
>>I wrote a short piece that contains my thoughts and speculation on the upcoming
>>Poulson microarchitecture. This is relatively well educated speculation, but speculation
>>nonetheless, and it will be interesting to see the presentation and paper in February.
>>
>>In the mean time, here's the article for everyone to enjoy:
>>http://www.realworldtech.com/page.cfm?ArticleID=RWT111710021604
>>
>>As always, comments and questions are welcome.
>>
>>
>>David
>
>I think Atom may be a preview to the type of MT used
>in Poulson. Atom is a two-issue wide in-order design
>that employs SMT. It will try to issue two instructions
>from the primary thread but if it can't it will try to fill in
>the second slot from the secondary thread.
>
>Poulson will likely operate in a similar way but at the
>level of bundles. It will try to issue up to four bundles
>from the primary thread. It will almost always be able to
>issue two bundles but more than that may be rare unless
>the app is recompiled with Poulson scheduling selected.
>The front end will attempt to fill in unused bundle slots
>from the secondary thread.
>
>This is a big win in two ways. The first is with 2 threads
>running current binaries there'll be 2 independent pairs
>of bundles ready to issue the majority of the time when
>both threads are unstalled. The second way is with true
>fine grained thread interleaving (i.e. SMT) stall cycles
>that dominate low ILP workloads can be mitigated to a
>far greater extent than Montecito/Tukwila's high switch
>penalty SoeMT ever could.
Yes, that was along the lines of what I was thinking for a dynamic thread management policy (i.e. done in HW). Of course, Intel might also leave that up to the software...which would be stupid, but also more philosophically consistent with EPIC.
David