<div dir="ltr">OpenMP is cool.<br><br>I'd say the "take all cores" compile time switch will be a good start for pure analytical workloads like mine. Machine is oversaturated anyways, if it can return back to shell some minutes faster that would be great already.<br><br>My previous experiments with instrumenting PostGIS for that exploded on the fact that palloc is not openmp-safe.<br><div><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 27 июл. 2021 г. в 23:18, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Interested in knowing what people's general reaction to OpenMP work is. <br>
<br>
<a href="https://github.com/libgeos/geos/pull/468" rel="noreferrer" target="_blank">https://github.com/libgeos/geos/pull/468</a><br>
<br>
Going from PoC to something committable will involve a reasonable amount of CMake twiddling to detect support on multiple platforms and get the right linking info and so on. It can be flipped off as necessary. The biggest implementation thing missing is some kind of run-time API to signal to OpenMP the maximum number of cores to commit, since we'll want to at least wave our hands at trying to avoid capping out server resources.<br>
<br>
On the one hand it's kind of cool. On the other there's limited places to put it to work, and it adds complexity for certain.<br>
<br>
P.<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</blockquote></div>