Data.table: R-Entwicklungsänderung; R-API innerhalb paralleler Regionen

Erstellt am 30. Nov. 2018 · 4Kommentare · Quelle: Rdatatable/data.table

Luke Tierney hat mich wegen eines Speicherproblems in R-devel kontaktiert. Die Tests werden sowohl für CRAN als auch für Travis / Appveyor bestanden, aber die Speichernutzung ist in einigen Fällen höher. Nach wie vor schaltet sich der Müllsammler aus.
Ich bin mir nicht sicher, wann genau die R-Entwicklung vorgenommen wurde, aber irgendwann im letzten Monat oder so. Es kann sein, dass die R-Devel-Änderung das neue Speicherproblem verursacht oder dass die R-Devel-Änderung das bereits bestehende Problem aufdeckt (möglicherweise sogar bei data.table-release bei R-release). In jedem Fall muss es behoben werden.

Luke schrieb:

I distilled the issue in 'constellation' down to the attached file
from the examples. If I run this the memory usage is much bigger than
previously and the gc() output is garbled. It's a
multi-threading issue again; everything looks fine with
OMP_NUM_THREADS=1. With mutlipe threads you are
calling DATAPTR from threads other than the main one and that creates
a race on setting the R_GCEnabled flag, so eventually it is getting
stuck on off. I instrumented the places where the GC is disabled and
tracked this as the first one from a thread other than the main one:

#4  0x00007ffff78ba9d5 in DATAPTR (x=x@entry=0x1167458)
     at ../../../R/src/include/Rinlinedfuns.h:106
#5  0x00007fffea02c4c8 in subsetVectorRaw (target=0x4529590, source=0x1167458,
     idx=0x4175210, any0orNA=FALSE) at subset.c:44
#6  0x00007fffea02c7a6 in subsetDT (x=<optimized out>, rows=<optimized out>,
     cols=<optimized out>) at subset.c:272

Angesichts von Lukes Details ist es einfach, das Problem im Code zu erkennen, ohne es reproduzieren zu müssen. Die gesamte R-API-Nutzung muss außerhalb aller parallelen Regionen erfolgen, wie zuvor von Luke angefordert. Ich habe das letzte Mal aufgrund von Zeitdruck verzögert, und jetzt muss es angegangen werden. Das letzte Mal habe ich nur den ersten Schritt gemacht, um sicherzustellen, dass DATAPTR in parallelen Regionen kein ALTREP erhält.

Dies garantiert eine beschleunigte Veröffentlichung von 1.12.0, nicht zuletzt, weil dies Auswirkungen auf Luke hat.

$ grep "omp.*parallel" *.c

[x] subset.c
[x] reorder.c
[x] fwrite.c
[x] fread.c
[x] fsort.c
[x] fordern.c
[x] zwischen.c

$ grep ALTREP *.c

[x] zwischen.c.
[x] fsort.c
[x] reorder.c
[x] wrappers.c

R-devel bug

Quelle

mattdowle

❤3

Hilfreichster Kommentar

Es ist großartig von Luke, all die harte Arbeit zu leisten, um die Ursache zu identifizieren! 💯

MichaelChirico am 30. Nov. 2018

👍5

Alle 4 Kommentare

Es ist großartig von Luke, all die harte Arbeit zu leisten, um die Ursache zu identifizieren! 💯

MichaelChirico am 30. Nov. 2018

👍5

Ich bin gerade dabei, mit Luke zu bestätigen, dass es behoben ist, bevor ich schließe ...

mattdowle am 7. Dez. 2018

Bestätigt behoben. Vielen Dank an @ltierney für seine Hilfe.

Der Vollständigkeit halber für den Fall, dass wir zurückverweisen müssen ...
Ich konnte das wie folgt kompilierte Problem mit R-devel nicht reproduzieren. (Ich musste bestätigen, dass ich das Problem mit 1.11.8 reproduzieren konnte, bevor ich bestätigen konnte, dass 1.11.9 es behebt.)

./configure --without-recommended-packages --disable-byte-compiled-packages --enable-strict-barrier CC="gcc -fsanitize=address -fno-sanitize=float-divide-by-zero -fno-omit-frame-pointer" CFLAGS="-O0 -g -Wall -pedantic"

sogar mit dem Drehbuch, das Luke zur Verfügung stellte:

library(data.table)
library(constellation)
temp <- as.data.table(vitals[VARIABLE == "TEMPERATURE"])
pulse <- as.data.table(vitals[VARIABLE == "PULSE"])
resp <- as.data.table(vitals[VARIABLE == "RESPIRATORY_RATE"])
temp[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
  format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
pulse[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
  format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
resp[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
  format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
gc()
for (i in 1:10) {
  cat("i=",i,"\n")
  b1 <- bundle(temp, pulse, resp,
    bundle_names = c("PLATELETS", "INR"), window_hours_pre = 24,
    window_hours_post = c(6, 6), join_key = "PAT_ID",
    time_var = "RECORDED_TIME", event_name = "CREATININE", mult = "all")
}
gc()

Im Großen und Ganzen habe ich R-devel einfacher wie folgt neu kompiliert, immer noch mit --enable-strict-barrier was das Wichtigste ist:
./configure --without-recommended-packages --enable-strict-barrier
Die Konstellation und all ihre Abhängigkeiten und Daten wurden neu installiert. Tabelle 1.11.8, und diesmal schlägt Lukes Skript korrekt fehl:

Fatal error: Wrong thread calling 'RunFinalizers'

Das Installieren von data.table-dev (1.11.9) in dieser R-Entwicklung und das erneute Ausführen funktionieren einwandfrei. Die erneute Installation von data.table 1.11.8 schlägt erneut fehl. Es ist also tatsächlich durch 1.11.9 behoben. In meiner ursprünglichen R-Devel-Kompilierung hat möglicherweise 1.11.8 funktioniert (Deaktivieren des Byte-Compilers, -00, ASAN usw.). Auf jeden Fall wurde eine einfachere R-Entwicklungskompilierung benötigt, die es wert war, ausprobiert zu werden.

@jangorecki Wenn es die Zeit erlaubt, wäre es großartig, --enable-strict-barrier zu der in CI-Pipelines verwendeten R-Entwicklung hinzuzufügen. Ich weiß nicht, ob Sie R-Devel für CI-Pipelines kompilieren oder nicht.

mattdowle am 10. Dez. 2018

@mattdowle ja ich kompiliere R-devel täglich, werde dieses Flag dort hinzufügen. Hinzugefügt, um in # 3147 nicht zu vergessen

jangorecki am 11. Dez. 2018

👍1

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Data.table: R-Entwicklungsänderung; R-API innerhalb paralleler Regionen

Hilfreichster Kommentar

Alle 4 Kommentare

Verwandte Themen