<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Xeon, VNNI, and a Throttling in Software Tuning, Performance Optimization &amp; Platform Monitoring</title>
    <link>https://community.intel.com/t5/Software-Tuning-Performance/Xeon-VNNI-and-a-Throttling/m-p/1729089#M8584</link>
    <description>&lt;P&gt;&lt;SPAN&gt;Hey, I've got a tricky performance snag on&amp;nbsp;my new Intel Xeon cluster running that super-optimized HPC workload (using VNNI for INT8 gains).&lt;/SPAN&gt;&lt;/P&gt;&lt;DIV class=""&gt;&lt;P&gt;It's fast, but sometimes it just stalls out. I think it might be due to&amp;nbsp;cache-line contention.&lt;/P&gt;&lt;P&gt;So I've been wondering:&lt;/P&gt;&lt;P&gt;If&amp;nbsp;I only had Intel V-Tune and access to raw PMT data, how&amp;nbsp;to approach this?&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;What are the top two or three PMU events&amp;nbsp;to&amp;nbsp;profile in V-Tune to confirm it's actually cache contention and not just bad instruction flow?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;How&amp;nbsp;to use the PMT data (power, thermals, etc.) to definitively tell us, 'No, this isn't contention, the platform is just throttling the clock speed'?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;And finally, say the real fix is a vendor-pushed microcode patch for better VNNI instruction scheduling. How do&amp;nbsp;I ensure that the critical little binary file is legit before the CPU loads it, touching on&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;A href="https://signmycode.com/" target="_blank" rel="noopener"&gt;code signing&lt;/A&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;and Intel TXT?&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;/DIV&gt;</description>
    <pubDate>Fri, 05 Dec 2025 06:15:12 GMT</pubDate>
    <dc:creator>Aronj2</dc:creator>
    <dc:date>2025-12-05T06:15:12Z</dc:date>
    <item>
      <title>Xeon, VNNI, and a Throttling</title>
      <link>https://community.intel.com/t5/Software-Tuning-Performance/Xeon-VNNI-and-a-Throttling/m-p/1729089#M8584</link>
      <description>&lt;P&gt;&lt;SPAN&gt;Hey, I've got a tricky performance snag on&amp;nbsp;my new Intel Xeon cluster running that super-optimized HPC workload (using VNNI for INT8 gains).&lt;/SPAN&gt;&lt;/P&gt;&lt;DIV class=""&gt;&lt;P&gt;It's fast, but sometimes it just stalls out. I think it might be due to&amp;nbsp;cache-line contention.&lt;/P&gt;&lt;P&gt;So I've been wondering:&lt;/P&gt;&lt;P&gt;If&amp;nbsp;I only had Intel V-Tune and access to raw PMT data, how&amp;nbsp;to approach this?&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;What are the top two or three PMU events&amp;nbsp;to&amp;nbsp;profile in V-Tune to confirm it's actually cache contention and not just bad instruction flow?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;How&amp;nbsp;to use the PMT data (power, thermals, etc.) to definitively tell us, 'No, this isn't contention, the platform is just throttling the clock speed'?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;And finally, say the real fix is a vendor-pushed microcode patch for better VNNI instruction scheduling. How do&amp;nbsp;I ensure that the critical little binary file is legit before the CPU loads it, touching on&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;A href="https://signmycode.com/" target="_blank" rel="noopener"&gt;code signing&lt;/A&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;and Intel TXT?&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;/DIV&gt;</description>
      <pubDate>Fri, 05 Dec 2025 06:15:12 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Tuning-Performance/Xeon-VNNI-and-a-Throttling/m-p/1729089#M8584</guid>
      <dc:creator>Aronj2</dc:creator>
      <dc:date>2025-12-05T06:15:12Z</dc:date>
    </item>
  </channel>
</rss>

