<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<pre>Hi Nicolas,
</pre>
<br>
<div class="moz-cite-prefix">On 3/6/19 4:35 AM, Nicolas Koenig
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:06649772-7f58-3475-867c-f11e08578622@student.ethz.ch">Hello
world,
<br>
<br>
After asking this question on another mailing list, I was
redirected to this list. I hope someone on here will be able to
help me :)
<br>
<br>
While running a few benchmarks, I noticed that the following code
(with SMT disabled) only manages about 2.25 xsadddp instr/clk
(measured via pmc6) instead of the expected 4:
<br>
<br>
loop:
<br>
.rept 12
<br>
xsadddp %vs2, %vs1, %vs1
<br>
.endr
<br>
bdnz loop
<br>
<br>
From what I can gather, the bottleneck shouldn't be the history
buffers. Since there are no long latency operations, FIN->COMP
shouldn't take more than 12 cycles (the size of the secondary HB
for FPSCR, the smallest relevant one). The primary HB and the
issue queue shouldn't overflow either, since xsadddp takes 7
cycles from issue to finish and they can accomodate 20 and 13
entries respectivly with one instruction only using one of each.
It doesn't stall on writeback ports either, because there are only
4 results in any one clock and 4 writeback ports (the decrement of
the bdnz instruction is handled in the branch slice without
involving the writeback network).
<br>
<br>
Has anyone here any idea where the bottleneck might be?
<br>
</blockquote>
<pre>Donald Stence was kind enough to answer this question for me. Here is his note,
which indicates this is actually performing better than you think!
</pre>
<div dir="ltr">
<pre>Hi Bill,</pre>
</div>
<div dir="ltr">
<pre> P9's design has it combine 64-bit execution units from two slices for processing a single 128-bit op.</pre>
</div>
<div dir="ltr">
<pre> Therefore, it can only issue two 128-bit ops per cycle, a theoretical max.</pre>
</div>
<div dir="ltr">
<pre> </pre>
</div>
<div dir="ltr">
<pre> The Dispatch rate is higher than the Issue rate, of 2 xsaddp's per cycle, will result in the Issue Queue</pre>
</div>
<div dir="ltr">
<pre> slots becoming full within just a few cycles and will result in Dispatch holds (nothing gets Dispatched</pre>
</div>
<div dir="ltr">
<pre> for a cycle because there are no available Issue slots to place more ops into).</pre>
</div>
<div dir="ltr">
<pre> </pre>
</div>
<div dir="ltr">
<pre> The branch overlaps and actually pushes the IPC up from just 2 ops/cycle.</pre>
</div>
<div dir="ltr">
<pre> </pre>
</div>
<div dir="ltr">
<pre> Thanks,</pre>
</div>
<div dir="ltr">
<pre> </pre>
</div>
<div dir="ltr">
<pre>Donald Stence</pre>
</div>
<div dir="ltr">
<pre>IBM PSP - P10 Technical Lead</pre>
</div>
<div dir="ltr"> <br>
<pre>Cheers,</pre>
<pre>Bill</pre>
</div>
<blockquote type="cite"
cite="mid:06649772-7f58-3475-867c-f11e08578622@student.ethz.ch">
<br>
Thanks in advance
<br>
Nicolas
<br>
_______________________________________________
<br>
Linuxppc-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Linuxppc-users@lists.ozlabs.org">Linuxppc-users@lists.ozlabs.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.ozlabs.org/listinfo/linuxppc-users">https://lists.ozlabs.org/listinfo/linuxppc-users</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>