build based on 255854d

dev/.documenter-siteinfo.json

@@ -1 +1 @@
-{"documenter":{"julia_version":"1.9.3","generation_timestamp":"2023-11-11T20:52:32","documenter_version":"1.1.2"}}
+{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2023-12-04T11:29:40","documenter_version":"1.2.1"}}

dev/index.html

@@ -32,4 +32,4 @@
   0.024 ns (0 allocations: 0 bytes)
 3</code></pre><p>As a rule of thumb, if a benchmark reports that it took less than a nanosecond to perform, this hoisting probably occurred. You can avoid this by referencing and dereferencing the interpolated variables </p><pre><code class="language-julia hljs">julia&gt; @btime $(Ref(a))[] + $(Ref(b))[]
   1.277 ns (0 allocations: 0 bytes)
-3</code></pre><p>As described in the <a href="https://juliaci.github.io/BenchmarkTools.jl/stable/reference/">Manual</a>, the BenchmarkTools package supports many other features, both for additional output and for more fine-grained control over the benchmarking process.</p></article><nav class="docs-footer"><a class="docs-footer-nextpage" href="manual/">Manual »</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option><option value="auto">Automatic (OS)</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> version 1.1.2 on <span class="colophon-date" title="Saturday 11 November 2023 20:52">Saturday 11 November 2023</span>. Using Julia version 1.9.3.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>
+3</code></pre><p>As described in the <a href="https://juliaci.github.io/BenchmarkTools.jl/stable/reference/">Manual</a>, the BenchmarkTools package supports many other features, both for additional output and for more fine-grained control over the benchmarking process.</p></article><nav class="docs-footer"><a class="docs-footer-nextpage" href="manual/">Manual »</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option><option value="auto">Automatic (OS)</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> version 1.2.1 on <span class="colophon-date" title="Monday 4 December 2023 11:29">Monday 4 December 2023</span>. Using Julia version 1.9.4.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>

dev/linuxtips/index.html

@@ -75,4 +75,4 @@
 MCE:          0          0  Machine check exceptions
 MCP:      61112      61112  Machine check polls
 ERR:          0
-MIS:          0</code></pre><p>Some interrupts, like <a href="https://en.wikipedia.org/wiki/Non-maskable_interrupt">non-maskable interrupts (<code>NMI</code>)</a>, can&#39;t be redirected, but you can change the SMP affinities of the rest by writing processor indices to <code>/proc/irq/n/smp_affinity_list</code>, where <code>n</code> is the IRQ number. Here&#39;s an example that sets IRQ <code>22</code>&#39;s SMP affinity to processors <code>0</code>, <code>1</code>, and <code>2</code>:</p><pre><code class="nohighlight hljs">➜ echo 0-2 | sudo tee /proc/irq/22/smp_affinity_list</code></pre><p>The optimal way to configure SMP affinities depends a lot on your benchmarks and benchmarking process. For example, if you&#39;re running a lot of network-bound benchmarks, it can sometimes be more beneficial to evenly balance ethernet driver interrupts (usually named something like <code>eth0-*</code>) than to restrict them to specific processors.</p><p>A smoke test for determining the impact of IRQs on benchmark results is to see what happens when you turn on/off an IRQ load balancer like <a href="http://linux.die.net/man/1/irqbalance"><code>irqbalance</code></a>. If this has a noticeable effect on your results, it might be worth playing around with SMP affinities to figure out which IRQs should be directed away from your shielded processors.</p><h4 id="Performance-monitoring-interrupts-(PMIs)-and-perf"><a class="docs-heading-anchor" href="#Performance-monitoring-interrupts-(PMIs)-and-perf">Performance monitoring interrupts (PMIs) and <code>perf</code></a><a id="Performance-monitoring-interrupts-(PMIs)-and-perf-1"></a><a class="docs-heading-anchor-permalink" href="#Performance-monitoring-interrupts-(PMIs)-and-perf" title="Permalink"></a></h4><p>Performance monitoring interrupts (PMIs) are sent by the kernel&#39;s <a href="https://perf.wiki.kernel.org/index.php/Main_Page"><code>perf</code></a> subsystem, which is used to set and manage <a href="https://en.wikipedia.org/wiki/Hardware_performance_counter">hardware performance counters</a> monitored by other parts of the kernel. Unless <code>perf</code> is a dependency of your benchmarking process, it may be useful to lower <code>perf</code>&#39;s sample rate so that PMIs don&#39;t interfere with your experiments. One way to do this is to set the <a href="https://www.kernel.org/doc/Documentation/sysctl/kernel.txt"><code>kernel.perf_cpu_time_max_percent</code></a> parameter to <code>1</code>:</p><pre><code class="nohighlight hljs">➜ sudo sysctl kernel.perf_cpu_time_max_percent=1</code></pre><p>This tells the kernel to inform <code>perf</code> that it should lower its sample rate such that sampling consumes less than 1% of CPU time. After changing this parameter, you may see messages in the system log like:</p><pre><code class="nohighlight hljs">[ 3835.065463] perf samples too long (2502 &gt; 2500), lowering kernel.perf_event_max_sample_rate</code></pre><p>These messages are nothing to be concerned about - it&#39;s simply the kernel reporting that it&#39;s lowering <code>perf</code>&#39;s max sample rate in order to respect the <code>perf_cpu_time_max_percent</code> property we just set.</p><h2 id="Additional-resources"><a class="docs-heading-anchor" href="#Additional-resources">Additional resources</a><a id="Additional-resources-1"></a><a class="docs-heading-anchor-permalink" href="#Additional-resources" title="Permalink"></a></h2><ul><li><p>While not highly navigable and a bit overwhelming for newcomers, the most authoritative resource for kernel information is the official Linux documentation hosted at <a href="https://www.kernel.org/doc/Documentation/">the Linux Kernel Archives</a>.</p></li><li><p>Akkan et al.&#39;s <a href="http://dl.acm.org/citation.cfm?id=2318925">2012 paper on developing a noiseless Linux environment</a> explores the optimal configurations for isolating resources from timer interrupts and the scheduler, as well as the benefits of tickless kernels. The paper makes use of Linux&#39;s <a href="https://wiki.archlinux.org/index.php/Cgroups"><code>cgroups</code></a>, which are similar to the cpusets discussed in this document.</p></li><li><p>De et al.&#39;s <a href="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5161046&amp;tag=1">2009 paper on reducing OS jitter in multithreaded systems</a> is similar to Akkan et al.&#39;s paper, but focuses on minimizing jitter for applications that make use of hyperthreading/SMT. Their experimental approach is different as well, relying heavily on analysis of simulated jitter &quot;traces&quot; attained by clever benchmarking.</p></li><li><p>For a solid overview of the Linux performance testing ecosystem, check out <a href="https://www.youtube.com/watch?v=FJW8nGV4jxY">Brendan Gregg&#39;s talk on Linux performance tools</a>. Note that this talk is more focused on debugging system performance problems as they arise in a large distributed environment, rather than application benchmarking or experimental reproducibility.</p></li><li><p>The <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/">RHEL6 Performance Tuning Guide</a> is useful for introducing yourself to various kernel constructs that can cause performance problems. You can also check out the <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/">RHEL7 version</a> of the same guide if you want something more recent, but I find the RHEL6 version more readable.</p></li></ul></article><nav class="docs-footer"><a class="docs-footer-prevpage" href="../manual/">« Manual</a><a class="docs-footer-nextpage" href="../reference/">Reference »</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option><option value="auto">Automatic (OS)</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> version 1.1.2 on <span class="colophon-date" title="Saturday 11 November 2023 20:52">Saturday 11 November 2023</span>. Using Julia version 1.9.3.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>
+MIS:          0</code></pre><p>Some interrupts, like <a href="https://en.wikipedia.org/wiki/Non-maskable_interrupt">non-maskable interrupts (<code>NMI</code>)</a>, can&#39;t be redirected, but you can change the SMP affinities of the rest by writing processor indices to <code>/proc/irq/n/smp_affinity_list</code>, where <code>n</code> is the IRQ number. Here&#39;s an example that sets IRQ <code>22</code>&#39;s SMP affinity to processors <code>0</code>, <code>1</code>, and <code>2</code>:</p><pre><code class="nohighlight hljs">➜ echo 0-2 | sudo tee /proc/irq/22/smp_affinity_list</code></pre><p>The optimal way to configure SMP affinities depends a lot on your benchmarks and benchmarking process. For example, if you&#39;re running a lot of network-bound benchmarks, it can sometimes be more beneficial to evenly balance ethernet driver interrupts (usually named something like <code>eth0-*</code>) than to restrict them to specific processors.</p><p>A smoke test for determining the impact of IRQs on benchmark results is to see what happens when you turn on/off an IRQ load balancer like <a href="http://linux.die.net/man/1/irqbalance"><code>irqbalance</code></a>. If this has a noticeable effect on your results, it might be worth playing around with SMP affinities to figure out which IRQs should be directed away from your shielded processors.</p><h4 id="Performance-monitoring-interrupts-(PMIs)-and-perf"><a class="docs-heading-anchor" href="#Performance-monitoring-interrupts-(PMIs)-and-perf">Performance monitoring interrupts (PMIs) and <code>perf</code></a><a id="Performance-monitoring-interrupts-(PMIs)-and-perf-1"></a><a class="docs-heading-anchor-permalink" href="#Performance-monitoring-interrupts-(PMIs)-and-perf" title="Permalink"></a></h4><p>Performance monitoring interrupts (PMIs) are sent by the kernel&#39;s <a href="https://perf.wiki.kernel.org/index.php/Main_Page"><code>perf</code></a> subsystem, which is used to set and manage <a href="https://en.wikipedia.org/wiki/Hardware_performance_counter">hardware performance counters</a> monitored by other parts of the kernel. Unless <code>perf</code> is a dependency of your benchmarking process, it may be useful to lower <code>perf</code>&#39;s sample rate so that PMIs don&#39;t interfere with your experiments. One way to do this is to set the <a href="https://www.kernel.org/doc/Documentation/sysctl/kernel.txt"><code>kernel.perf_cpu_time_max_percent</code></a> parameter to <code>1</code>:</p><pre><code class="nohighlight hljs">➜ sudo sysctl kernel.perf_cpu_time_max_percent=1</code></pre><p>This tells the kernel to inform <code>perf</code> that it should lower its sample rate such that sampling consumes less than 1% of CPU time. After changing this parameter, you may see messages in the system log like:</p><pre><code class="nohighlight hljs">[ 3835.065463] perf samples too long (2502 &gt; 2500), lowering kernel.perf_event_max_sample_rate</code></pre><p>These messages are nothing to be concerned about - it&#39;s simply the kernel reporting that it&#39;s lowering <code>perf</code>&#39;s max sample rate in order to respect the <code>perf_cpu_time_max_percent</code> property we just set.</p><h2 id="Additional-resources"><a class="docs-heading-anchor" href="#Additional-resources">Additional resources</a><a id="Additional-resources-1"></a><a class="docs-heading-anchor-permalink" href="#Additional-resources" title="Permalink"></a></h2><ul><li><p>While not highly navigable and a bit overwhelming for newcomers, the most authoritative resource for kernel information is the official Linux documentation hosted at <a href="https://www.kernel.org/doc/Documentation/">the Linux Kernel Archives</a>.</p></li><li><p>Akkan et al.&#39;s <a href="http://dl.acm.org/citation.cfm?id=2318925">2012 paper on developing a noiseless Linux environment</a> explores the optimal configurations for isolating resources from timer interrupts and the scheduler, as well as the benefits of tickless kernels. The paper makes use of Linux&#39;s <a href="https://wiki.archlinux.org/index.php/Cgroups"><code>cgroups</code></a>, which are similar to the cpusets discussed in this document.</p></li><li><p>De et al.&#39;s <a href="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5161046&amp;tag=1">2009 paper on reducing OS jitter in multithreaded systems</a> is similar to Akkan et al.&#39;s paper, but focuses on minimizing jitter for applications that make use of hyperthreading/SMT. Their experimental approach is different as well, relying heavily on analysis of simulated jitter &quot;traces&quot; attained by clever benchmarking.</p></li><li><p>For a solid overview of the Linux performance testing ecosystem, check out <a href="https://www.youtube.com/watch?v=FJW8nGV4jxY">Brendan Gregg&#39;s talk on Linux performance tools</a>. Note that this talk is more focused on debugging system performance problems as they arise in a large distributed environment, rather than application benchmarking or experimental reproducibility.</p></li><li><p>The <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/">RHEL6 Performance Tuning Guide</a> is useful for introducing yourself to various kernel constructs that can cause performance problems. You can also check out the <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/">RHEL7 version</a> of the same guide if you want something more recent, but I find the RHEL6 version more readable.</p></li></ul></article><nav class="docs-footer"><a class="docs-footer-prevpage" href="../manual/">« Manual</a><a class="docs-footer-nextpage" href="../reference/">Reference »</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option><option value="auto">Automatic (OS)</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> version 1.2.1 on <span class="colophon-date" title="Monday 4 December 2023 11:29">Monday 4 December 2023</span>. Using Julia version 1.9.4.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>