Irgendwie verwende ich OMP falsch. Die Laufzeit verschlechtert sich etwa um den Faktor 50.
(Mit OMP hat die Funktion über den gesammten Programmverlauf etwa 50 Sekunden gebraucht, ohne OMP knapp 1 Sekunde...)
Irgendwie verwende ich OMP falsch. Die Laufzeit verschlechtert sich etwa um den Faktor 50.
(Mit OMP hat die Funktion über den gesammten Programmverlauf etwa 50 Sekunden gebraucht, ohne OMP knapp 1 Sekunde...)
Die Matrix in einen Vektor zu speichern hatte auch nicht den gewünschten Effekt . Beide Male etwa 45 sec. gebraucht, dabei insgesamt jeweils 1 508 296 mal aufgerufen.
Laut den Papern, die man so im Netz findet, ist das Problem immer schwierig und es gibt einige heuristische(?) Verfahren, die sich mit suboptimalen Lösungen zufrieden geben. Z.B. der LLL-Algorithmus.
Vllt. wäre zu überdenken, ob die Beschleunigung einen die daraus resultierenden Nachteile in Kauf nehmen lässt.
Aber ohne weitere Infos/Recherchen ist für Außenstehende nicht entscheidbar, was eine gute Lösung wäre. Theoretisch könnte man ja auch die Berechnung mit CUDA oder OpenCL (beiden selber nie benutzt) auf die GPU auslagern.
Kostet leider Lebenszeit
LLL verwende ich ja schon vorher, um die Gitterbasis zu reduzieren. Genauer gesagt den BKZ-Algorithmus. Mit der dadurch entstandenen neuen Gitterbasis erstelle ich mittes der Nearest Plane Methode sehr viele kurze Gittervektoren in der Hoffnung, zwei solche Vektoren zu finden, deren Differenzvektor noch kürzer ist.
1 Sekunde Laufzeit ist jetzt für ein komplexes mathematisches Problem eigentlich völlig akzeptabel. Wenn man an einer ordentlich frühen Stelle parallelisiert, kann man bestimmt noch was rausholen, hängt aber dann sehr davon ab, wie gut die Parallelisierungsverwaltung ist. Von sowas hab ich aber überhaupt keine Ahnung. Ich weiß nur, dass die Parallelisierung im ABAP ne Katastrophe ist, weil sie jedem Prozess festen Speicher und CPU zuteilt...
Naja, da bist du bei maximum 5 GB/s (fuer n=400 bei 45s / 1.5M Aufrufe). Fuer einen einzelnen Thread ist das garnicht soo schlecht (auf nem modernen System bekommst du so 10-15 GB/s mit einem Thread, 20-40 GB/s insgesamt).Zitat von alpha civ
Ich wuerde empfehlen, auch mal zu ueberpruefen ob die Speicherallokation von err/temp ein Problem ist. Bei 30 us pro Aufruf kann das schon sein.
Wie rufst du die Funktion insgesamt auf. Hast du Chancen aussenrum zu parallelisieren?
EDIT: ABAP, mein Beileid!
Achtung Spoiler:
Programmierer bei SAP halt
ABAP 7.4 ist aber echt schon gut, und man kann mittlerweile auch Datenbanknäher programmieren. Ärgerlich ist halt die R3-Struktur, die z.B. eine dynamischere Parallelisierung verhindert, kann ja sein, dass ich nur viel Prozessorleistung brauche und wenig Speicherplatz, wenn ich mir dafür 5 Prozesse kralle, ist aber der Speicher für all diese Prozesse blockiert...
Das ist doch lustig:
https://twitter.com/futurepaul/statu...118848/photo/1
Verstand op nul, frituur op 180.
![Avatar von [VK]](image.php?s=fcb8330f401269be3cd244e75bf5df1b&u=14495&dateline=1671385653 "Avatar von [VK]")
Kurze Frage zum Theam Vererbung:
Bsp:
Cat ist Abgeleitet von Mammal
Cat c;
Mammal a = c;
Hierbei gehen ja die Extrainformationen von Cat c beim kopieren zu Mammal a verloren, sobald c nicht mehr im Scope ist...
Wie sieht es bei Pointern aus?
Mammal* c = new Cat();
Cat* b = static_cast<Cat*>(c);
Das geht ja, da keine Informationen beim Pointerkopieren verloren gehen. Man kann also weiterhin einfach auf alle Infos zugreifen.
Jetzt die Frage: Ist das ganze überhaupt sinnvoll? Gibt es eine Möglichkeit zu erfahren ob Mammal überhaupt Cat ist? Gibt's eine Alternative die sinnvoller ist?
Mir geht es halt um sowas:
Ich hab vector<Mammal*> und möchte da drübergehen und für jedes davon zbs sound() oder sowas ausgeben das halt von jeder abgeleiteten Klasse anders implementiert wird, aber bei allen vorhanden ist. Wenn ich das ganze als Mammal aufrufe wird ja die Mammal Methode aufgerufen, und nicht die der Subklasse.
Hmm, wenn ich richtig sehe ist das ganze Thema von virtual Methoden oder? Aber das Problem dürfte ja auch bei nicht virtuellen Methoden auftreten...
Edit: Ja, das Thema virtual stimmt
Geändert von [VK] (05. Juni 2014 um 08:44 Uhr)
Wenn man bei Vererbung Polymorphie erlauben will, braucht man auch zwingend einen virtuellen Destruktor, selbst wenn es sonst nicht nötig wäre, einen zu implementieren (weil man keine rohen Zeiger als Attribute hat). Sonst wird bei vererbten Klassen nur der Destruktor der Basisklasse aufgerufen.
Noch ein interessanter Aspekt der Vererbung: es wird intern eine neue Tabelle angelegt, in der Pointer zu den vererbten Klassen angelegt werden (um eben die virtuellen Funktionen zu durchlaufen). Das wird natürlich sehr unschön, wenn man platzsparend programmieren möchte. Noch schlimmer wirds hier mit Templates. Aber das ist ein anderes Thema
Beides weiß ich inzwischen. Mein Problem war das es in Java im Grunde ein impliziertes Standardverhalten ist und ich daher angenommen hatte das war auch in c++ so...
Die anderen beiden Themen kenn ich inzwischen auch.
In Java hat man keine Zeiger,, im Gegensatz zu C++. Hier muss man eben den Unterschied zwischen Werten und Zeigern bei der Vererbung beachten.
Bitte mir solchen Pauschalaussagen vorsichtig sein. In Java ist alles ein Zeiger, wenn auch nicht im Code so ersichtlich.
Berechtigungen
Zitieren
