<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 3/7/19 2:16 PM, Bill Schmidt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3898aaa3-25ac-2fc0-9c56-136d33afde9d@linux.ibm.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
On 3/7/19 1:24 PM, Bill Schmidt wrote:<br>
<blockquote type="cite"
cite="mid:ee62c915-0172-9ad4-2322-f8d204e33010@linux.ibm.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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>
</blockquote>
<pre>Hrm, it is pointed out to me that this is xsadddp, not xvadddp, so I don't think we have an answer yet.</pre>
</blockquote>
<pre>Segher discovered that xsadddp has the same limitation because of its internal
implementation on P9. Per the P9 UM:
"Because the binary floating-point registers (FPRs) are mapped to the vector-scalar registers 0 - 31 in the
Power ISA, the rightmost doubleword is updated with zero whenever a binary or decimal floating-point
instruction writes the target FPR. This behavior applies to any binary or decimal floating-point instruction
that writes an FPR, not just loads."
Thanks for letting us know about this!
Bill
</pre>
<blockquote type="cite"
cite="mid:3898aaa3-25ac-2fc0-9c56-136d33afde9d@linux.ibm.com">
<pre>
Sorry,
Bill
</pre>
<blockquote type="cite"
cite="mid:ee62c915-0172-9ad4-2322-f8d204e33010@linux.ibm.com">
<div dir="ltr"> </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"
moz-do-not-send="true">Linuxppc-users@lists.ozlabs.org</a> <br>
<a class="moz-txt-link-freetext"
href="https://lists.ozlabs.org/listinfo/linuxppc-users"
moz-do-not-send="true">https://lists.ozlabs.org/listinfo/linuxppc-users</a>
<br>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Linuxppc-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Linuxppc-users@lists.ozlabs.org" moz-do-not-send="true">Linuxppc-users@lists.ozlabs.org</a>
<a class="moz-txt-link-freetext" href="https://lists.ozlabs.org/listinfo/linuxppc-users" moz-do-not-send="true">https://lists.ozlabs.org/listinfo/linuxppc-users</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Linuxppc-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Linuxppc-users@lists.ozlabs.org">Linuxppc-users@lists.ozlabs.org</a>
<a class="moz-txt-link-freetext" href="https://lists.ozlabs.org/listinfo/linuxppc-users">https://lists.ozlabs.org/listinfo/linuxppc-users</a>
</pre>
</blockquote>
<br>
</body>
</html>