Die Art und Weise, wie Sie im Snippet anzeigen, erweitert die internen Arrays der Sparse-Domäne bei jeder Operation +=
. Wie du vorgeschlagen hast; Irgendwie puffern die gelesenen Indizes und fügen sie dann in großen Mengen hinzu, was auf Grund mehrerer Optimierungen zum Hinzufügen eines Arrays von Indizes definitiv besser ist.
Sie können in ähnlicher Weise eine +=
sie, wenn der rechten Seite ein Array ist:
spsDom += arrayOfIndices;
Diese Überlastung der +=
Operator auf sparse Domänen tatsächlich bulkAdd
die Hauptmasse zusätzlich Methode aufrufen. Die Methode selbst verfügt über mehrere Flags, mit denen Sie in einigen Fällen möglicherweise noch mehr Leistung erzielen können. Beachten Sie, dass die +=
Überlastung die Methode bulkAdd
auf die "sicherste" Art und Weise aufruft. dh das Array von Indizes kann in zufälliger Reihenfolge sein, kann Duplikate usw. enthalten. Wenn Sie Arrays (in Ihren Fällen Indizes, die Sie aus der Datei lesen) erfüllen einige Anforderungen (Sind sie bestellt? Gibt es Duplikate? Müssen Sie die Eingabe beibehalten Array?), können Sie direkt bulkAdd
verwenden und mehrere Optimierungs-Flags übergeben.
Siehe http://chapel.cray.com/docs/latest/builtins/internal/ChapelArray.html#ChapelArray.bulkAdd für die Dokumentation von bulkAdd
.
Edit: ein Ausschnitt auf dem in Rede stehende Gebäude:
var dnsDom = {1..n_dims, 1..n_dims};
var spsDom: sparse subdomain(dnsDom);
//create an index buffer
config const indexBufferSize = 100;
var indexBufferDom: {0..#indexBufferSize};
var indexBuffer: [indexBufferDom] 2*int;
var count = 0;
for line in file_reader.lines() {
indexBuffer[count] = (line[1]:int, line[2]:int);
count += 1;
// bulk add indices if the buffer is full
if count == indexBufferSize {
spsDom.bulkAdd(indexBuffer, dataSorted=true,
preserveInds=false,
isUnique=true);
count = 0;
}
}
// dump the final buffer that is (most likely) partially filled
spsDom.bulkAdd(indexBuffer[0..#count], dataSorted=true,
preserveInds=false,
isUnique=true);
Ich habe es nicht getestet, aber ich denke, das sollte die grundlegenden idea.The Fahnen an den bulkAdd weitergegeben erfassen sollte zur Folge haben in der besten Leistung. Dies hängt natürlich davon ab, dass der Eingabepuffer sortiert ist und keine Duplikate enthält. Beachten Sie auch, dass der anfängliche BulkAdd viel schneller ist als der nachfolgende. Und sie werden wahrscheinlich langsamer werden, da die Methode die bestehenden Indizes durchforsten und gegebenenfalls verschieben muss. Ein größerer Puffer kann also eine bessere Leistung liefern.
Wie in >>> https://stackoverflow.com/q/45172614 gefragt wurde, würde es Ihnen etwas ausmachen, ein paar Details zur Verfügung zu stellen? Wenn ein quantitatives Maß für die Effizienz ein TimeDOMAIN-Wert ist, haben Sie die 'Timer.start() -Einstellung Ihrer Basisimplementierung gemessen; ...; Timer.stop() 'um eine solche Grundlinie zu zitieren, um sie zu vergleichen? Wenn ein quantitatives Maß ein "memory footprint" oder ein anderes Kriterium ist, würden Sie das bitte angeben, so dass andere Ihre Erwartungen bezüglich der Metriken dieser Effizienz teilen können? Vielen Dank. (Wäre super wenn du noch die ** 'repr (I) + repr (V)' ** für deine vorherige Frage posten könntest. Danke.) – user3666197
Nicht ignorierend, ich habe direkt mit dem Chapel Team gearbeitet um ein paar zu bekommen von diesen Dingen sortiert. Ich beabsichtige, w/bessere Antworten bald zu aktualisieren –
Großer Schritt, Brian. Situationen in kombinierten [PTIME, PSPACE] oder [EXPTIME, EXPSPACE] Double-Trouble-Ecken, die sich nahe an den physischen Grenzen der Zoo-Komplexität befinden, sind immer eine Herausforderung. Jeder Kompromiss in einer Dimension ist offensichtlich sehr teuer, wenn nicht gar unmöglich, in der anderen dieser zwei hauptsächlichen Turing SEQ-Verarbeitungsdimensionen. Danke für eine Notiz, wird auf Updates warten. – user3666197