Funktion verwendet alle Threads, statt nur eines einzelnen (TPS, library "fields")

[T3stversion]

Hallo,
ich habe folgendes Problem:
Ich möchte meteorologische Größen räumlich berechnen, dafür verwende ich die Funktion "Tps" (thin plate splines) der Bibliothek "fields".
Da insgesamt einige 100.000 Zeitschritte zu berechnen sind, möchte ich insgesamt 12 Instanzen laufen lassen, mit jeweils 1/12 des Gesamtzeitraumes. Insgesamt stehen 12 Kerne / 24 Threads zur Verfügung, das sollte also ohne Probleme gehen. Nun ist es aber so, das bereits bei einer Instanz alle 24 Threads zu 100% ausgelastet sind. Eigentlich sollte nur ein einzelner verwendet werden. Werden weitere Instanzen gestartet, teilen diese sich die Threads auf, werden aber sehr sehr langsam.
Ich habe R vor kurzem neu installiert (4.0.3), vorher (R 4.0.2) habe ich die gleiche Prozedur durchgeführt, und es hatte wie angedacht funktioniert.

Ich verwende R im Terminal auf einem Ubuntu 20.04

Bei folgendem Code ist die Auslastung bei 100%:

Code: Alles auswählen

library(fields)

for (i in 1:100000){
  q1<-Tps(matrix(runif(300),100,3),runif(100))
  print(i)
}

Danke für jede Hilfe!

[EDi]

Kannst du die sessionInfo() teilen? Welches BLAS wird genutzt?

Das könnte dir deine Frage beantworten: https://cran.r-project.org/web/packages ... index.html

Ich vermute aber, dass diese Strategie performanzmäßig nicht aufgehen wird (Bauchgefühl ohne zu wissen was in Tpl() gerechnet wird).
Probiers mal aus und lass uns die Unterschiede wissen....

Übrigens (das hab ich selbst gestestet): IntelMKL kann für bestimmte Operationen schon bissl was rauskitzeln (im Vergleich zum Standardblas).
Das kann ja recht einfach mal ausprobieren.

Oder halt einfach Rechenpower beim Cloudprovider deines Vertrauens mieten...

[T3stversion]

Hallo EDi,

sehr vielen Dank für die Antwort! Das von dir vorgeschlagene Package funktioniert wie es soll, es reduziert die Anzahl genutzter Threads, hier auf einen einzelnen.

Zur Performance: Eine einzelne Instanz braucht für 1.000 Zeitschritte ca. 35 Minuten. Als alle Threads überflüssiger Weise ausgelastet waren, haben 12 Instanzen für die 1.000 Zeitschritte ca. je 4 Stunden gebraucht. Das lohnt sich natürlich nicht besonders, v.A. kann ich den Rechner nicht für andere Sachen nutzen.
Jetzt, wo jede Instanz einen einzelnen Thread nutzt, braucht eine einzelne bei 1.000 Zeitschritten 25 Minuten, wenn 12 parallel laufen, braucht jede Instanz ca. 30 Minuten, da sie sich verschiedene Ressourcen trotzdem teilen müssen (ich denke vor allem die Speicherkanäle werden da limitieren).
Die IntelMKL werd ich mal ausprobieren, hab nur gelesen, dass die auf Zen-Architektur ausgebremst wird.

Wie auch immer, das Problem ist gelöst, danke dir!

[Athomas]

Interessantes Phänomen, ich habe dazu etwas auf meinem eigenen Rechner

Code: Alles auswählen

R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3

herumexperimentiert.

Ich gehe davon aus, dass Deine "private" Parallelisierung sehr viel effektiver (inhaltlich unabhängig?) durchführbar ist als das, was die LA-Bibliothek zu verarbeiten hat. Von daher ist es schon mal gut, möglichst viel Power auf die effektive Parallelisierung zu setzen...

Der andere Aspekt ist, dass Du die Kiste natürlich rettungslos überbeanspruchst, wenn jede von mehreren Instanzen die volle CPU-Power für sich reklamiert...

Ich habe auf meinem Rechner (20 Cores, 40 Threads) ein einfaches Beispiel (Invertierung von 200 1000 x 1000 Matrizen) gerechnet - das aller Wahrscheinlichkeit nach noch besser zu parallelisieren ist als das, was Du da treibst !

Dabei wurde mein "bestes" Ergebnis (geringste verstrichene Zeit) für blas_set_num_threads(1) und 20 zur Parallelverarbeitung registrierten Kernen erzielt (6,1 sec.), während das Pendant zu Deiner Anfangseinstellung (BLAS "volle Pulle", Parallelisierung = Anzahl verfügbarer Kerne) 290,4 sec. brauchte!