<div dir="ltr"><div>Hi Walter, </div><div><br></div><div>My vague understanding was that mult-threaded IPP had been disabled some time ago because Intel figured out that it was a giant PITA. (Which was certainly the case for us, since the multithreaded IPP calls were not thread safe, so they didn't play nice with DiFX which uses pthreads. So in 2012 we added that call to set ippNumThreads to 1, which I think was the only edit ever related to IPP threading.)</div><div><br></div><div>Gemini believes similarly (edited summary below) so I think it is perfectly safe to remove that call; best of all would be to have it be conditional on IPP version (e.g., only made for versions 2022.3 and earlier).</div><div><br></div><div>Cheers,</div><div>Adam</div><div><h3>The Function of <code>ippSetNumThreads()</code></h3><p>Historically, Intel IPP maintained both single-threaded and multi-threaded versions of its libraries. The multi-threaded versions utilized OpenMP under the hood to automatically parallelize workloads across available CPU cores.</p><p>The <code>ippSetNumThreads(int numThr)</code> function was used to manually configure the number of OpenMP threads that IPP internal functions were allowed to spawn.</p><ul><li><p id="gmail-p-rc_e6c0c4607b362aa7-19"><span class="gmail-citation-1 gmail-citation-end-1">By default, IPP would use a number of threads equal to the number of processors in the system.<span><sup class="gmail-superscript"></sup></span></span><span> <span class="gmail-ng-star-inserted"></span></span></p><div class="gmail-source-inline-chip-container gmail-ng-star-inserted"><button class="gmail-button gmail-ng-star-inserted" aria-label="View source details. Opens side panel."><span role="img" class="gmail-mat-icon gmail-notranslate gmail-symbol gmail-gds-icon-s gmail-google-symbols gmail-mat-ligature-font gmail-mat-icon-no-color gmail-ng-star-inserted" aria-hidden="true"></span></button></div><p></p></li><li><p>Developers typically used <code>ippSetNumThreads(1)</code> to explicitly disable IPP's internal parallelization, which was crucial to prevent thread oversubscription if the host application was already managing its own threads.</p></li></ul><h3>IPP Threading Behavior Post-Deprecation</h3><p>Starting around IPP 8.0/8.2, Intel officially deprecated IPP's internal multi-threading libraries and functions, including <code>ippSetNumThreads()</code>. The threading behavior of IPP shifted fundamentally:</p><p><b>1. Shift from Internal to External Threading</b>
Intel realized that having a library handle threading internally often caused severe performance bottlenecks and interoperability issues when mixed with the host application's own threading model. Today, IPP relies entirely on <b>external threading</b> (also known as application-level threading).</p><p><b>2. Single-Threaded but Thread-Safe</b>
Modern IPP functions are strictly single-threaded by design. However, they are entirely <b>thread-safe</b>. The expectation is that you, the developer, will handle the thread management at the application level using modern concurrency frameworks like Intel Threading Building Blocks (TBB), OpenMP, Cilk Plus, POSIX threads, or Windows threads. You divide your data into chunks across your application's threads, and then each thread calls the highly optimized, single-threaded IPP primitives to process its respective chunk.</p><p><b>3. The Current State of the API</b>
In recent versions of Intel IPP, calling <code>ippSetNumThreads()</code> or <code>ippGetNumThreads()</code> no longer actually does anything. Because the underlying internal threading libraries have been removed, these functions simply return the status code <code>ippStsNoOperation</code>. Intel has kept them around as "dummy" functions solely to prevent compilation errors in legacy codebases, but they are slated for complete removal from the API in upcoming releases.</p><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 29 Apr 2026 at 04:31, Walter Brisken via Difx-users <<a href="mailto:difx-users@listmgr.nrao.edu" target="_blank">difx-users@listmgr.nrao.edu</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">Hi DiFX folks,<br>
<br>
A new Intel Integrated Performatives Primitives (IPP) version was <br>
released just last week. This is version 2026.0.0, superseding the <br>
previous version 2022.3.0.<br>
<br>
<a href="https://www.intel.com/content/www/us/en/developer/tools/oneapi/ipp-download.html?operatingsystem=linux&linux-install=offline" rel="noreferrer" target="_blank">https://www.intel.com/content/www/us/en/developer/tools/oneapi/ipp-download.html?operatingsystem=linux&linux-install=offline</a><br>
<br>
Note that this web page is only partially updated and the "whats new" <br>
section of the IPP web page doesn't include any details on what has <br>
changed between the two versions.<br>
<br>
<br>
I have successfully compiled DiFX using this and will begin testing it <br>
soon. There is one build caveat: this version deprecates a call to <br>
ippSetNumThreads(). To allow building to continue, the call to this <br>
function in mpifxcorr.cpp can simply be commented out. Alternatively if <br>
you want to keep the source code for released versions of DiFX clean, <br>
you can append to the bottom of the ippcore.h file that comes with IPP <br>
the following line:<br>
<br>
#define ippSetNumThreads(n) 0<br>
<br>
That will simply cause nothing to happen when trying to make the <br>
function call.<br>
<br>
A question for those that may know IPP more than I do: without the <br>
ability to set number of threads, what is the behavior regarding <br>
"threadiness" now? I note that this function call was deprecated in <br>
2022.3.0, and maybe also earlier versions, so it is possible that this <br>
call has been effectively a no-op for quite some time. Any clarity on <br>
this would be useful!<br>
<br>
Cheers,<br>
<br>
Walter<br>
<br>
_______________________________________________<br>
Difx-users mailing list<br>
<a href="mailto:Difx-users@listmgr.nrao.edu" target="_blank">Difx-users@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/difx-users" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/difx-users</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><div dir="ltr" style="font-size:12.8px"><div dir="ltr" style="font-size:12.8px"><div dir="ltr" style="font-size:12.8px"><div dir="ltr" style="font-size:12.8px"><div dir="ltr" style="font-size:12.8px">!=============================================================!<br><div dir="ltr" style="font-size:12.8px">Prof. Adam Deller </div></div><div style="font-size:12.8px">Centre for Astrophysics & Supercomputing </div><div dir="ltr" style="font-size:12.8px">Swinburne University of Technology <br>John St, Hawthorn VIC 3122 Australia</div><div style="font-size:12.8px">phone: +61 3 9214 5307</div><div style="font-size:12.8px">fax: +61 3 9214 8797</div><div style="font-size:12.8px">!=============================================================!</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>