<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 2:30 PM Andrea Di Biagio <<a href="mailto:andrea.dibiagio@gmail.com">andrea.dibiagio@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>In the absence of data dependencies, throughput of a block of code is superiorly limited by the dispatch rate (i.e. our DispatchWidth), and the availability of hardware resources.<br><br></div>DispatchWidth is the maximum number of micro opcodes that can be dispatched to the out-of-order every cycle. That value inevitably affects the block throughput. Example: if a block in input decodes to 4 micro-opcodes in total, and the processor can only dispatch up to 2 opcodes per cycle, then the maximum block throughput cannot exceed 0.5 (i.e. one block every two cycles).<br><br></div>Block throughput is also constrained by the availability of hardware resources.<br></div>Example: if we have 4 ADD micro-opcodes, and each opcode consumes 1cy of ALU pipeline, then the block throughput is superiorly limited by N/4, where N is the number of ALU pipelines available on the target, and 4 is the number of ALU cycles consumed. So, if there is only 1 ALU pipeline, then the block throughput is superiorly limited to 1/4 = 0.25 (blocks per cycle)<br><br></div><div>Back to the computation of the "Block Throughput".<br></div></div></blockquote><div dir="ltr"><div><br></div><div>Sorry, I should have written "Block RThroughput" here.<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It is statically computed as the reciprocal of the block throughput. As for the normal instruction throughput, the computation doesn't take into account operand dependencies. Therefore, we could say that it is computed as the MAX of:<br></div><div> - #MicroOpcodes of a block / DispatchWidth<br></div><div> - #Consumed resource cycles / #Resources [ for every resource kind ].<br></div><div><div><div><div><div><div><div><br></div><div>In the absence of loop-carried dependencies
between different iterations, the observed ‘uOps Per Cycle’ tends to a theoretical
maximum throughput which can be computed by dividing the total number of uOps of a
block by the Block RThroughput.<br><br></div><div>You can find more information about it in the llvm-mca docs under section "How LLVM-MCA works".<br><br></div><div>I hope it helps!</div><div>-Andrea<br>
</div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 12:43 PM Tom Chen <<a href="mailto:cyt046@gmail.com" target="_blank">cyt046@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Andrea,<div>So does this definition make sense for basic blocks with more than one instructions? E.g. how should one interpret a basic block with RThroughput of 2.3?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 7:39 AM Andrea Di Biagio <<a href="mailto:andrea.dibiagio@gmail.com" target="_blank">andrea.dibiagio@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Tom,</div><div><br></div><div>Field 'Total Cycles' from the summary view simply reports the elapsed number of cycles for the entire simulation.</div><div><br></div><div>Rthroughput (from the "Instruction Info" view) is the reciprocal of the instruction throughput.<br></div><div>Throughput is computed as the maximum number of instructions of a same type that can be executed per clock cycle in the absence of operand dependencies.</div><div><br></div><div>Example (x86 - AMD Jaguar):<br></div><div> ADD EAX, ESI<br><br></div><div>The integer unit in Jaguar has two ALU pipelines. An ADD instruction can issue to any of those pipelines. That means, two independent ADD can be issue during a same cycle. Therefore, throughput is 2 (instructions per cycle), and RThrougput (1/throughput) is 0.5.<br><br></div><div>I hope it helps,</div><div>-Andrea<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 6, 2019 at 10:11 PM Tom Chen via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">What is the difference between the two? I thought "Rthroughput" is basically the number of cycles required to execute a single iteration at steady state, but this does not seem to match with the schedule/timeline generated by llvm-mca.<div>Thanks in advance,</div><div>Tom</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>