loop optimieren

camper

Hast du evtl. ein vollständiges Testprogramm für diese Funktion? Dann könntest du das in Gänze posten (http://rafb.net/paste/ & co.) damit wir eigene Experimente anstellen können. Bloßes Draufschauen hilft bei solchen Microoptimierungen leider oft nicht.

Helium

OK, ich habe schon ewig nicht mehr mit der gcc rumgespielt, aber wenn ich mich recht entsinne ist es ganz sinnvoll -march zu verwenden.

Wenn ihr aus dem Code noch mehr als 10% rausholt, bekommt ihr nen virtuellen Keks.

Nephelauxetic

camper schrieb:

Hast du evtl. ein vollständiges Testprogramm für diese Funktion? Dann könntest du das in Gänze posten (http://rafb.net/paste/ & co.) damit wir eigene Experimente anstellen können. Bloßes Draufschauen hilft bei solchen Microoptimierungen leider oft nicht.

Ich kann dir den Code per Mail schicken. Das Problem ist das du ganze Bibliothek (fuer Objekte wie topo, conf etc.) einfach riesig ist. Zudem wuerd ich den Code in dieser Form nur ungern ins Netz stellen.

Helium schrieb:

aber wenn ich mich recht entsinne ist es ganz sinnvoll -march zu verwenden.

Ja in der Regel schon. Hier bringt es nichts.

Ben04 schrieb:

Skaliert also recht gut mit n wenn die Laufzeit von ... nicht von i abhängt.

Ausser in den trivialsten Faellen hat man das aber nie.

LG
Neph

Walli

Das hat man sogar erstaunlich oft. Oder war das nur auf dein Programm bezogen?

Nephelauxetic

Walli schrieb:

Das hat man sogar erstaunlich oft. Oder war das nur auf dein Programm bezogen?

Nein allgemein. Kann sein dass ich aber bis jetzt einfach nur Pech hatte dass ich noch nie eines dieser schoenen Daten-parallelen Lehrbuchbeispiele in der Praxis hatte.

Aber das ist hier OT.

Nephelauxetic

abc.w schrieb:

-ffast-math -fno-rtti

Das bringt fast 10% auf dem ganzen Programm Dies liegt aber am fast-math. no-rtti hat keinen Effekt.

abc.w

Nephelauxetic schrieb:

Dies liegt aber am fast-math. no-rtti hat keinen Effekt.

-fno-rtti durfte sich laut gcc manual u.U. auf den Speicherverbrauch auswirken. -ffast-math bewirkt u.a. dass bei Berechnungen keine bedingten Sprungbefehle generiert werden. Damit spart man wahrscheinlich CPU-Takte. Optimal wäre, überhaupt keine Sprünge im Code zu haben, keine Schleifen, keine if-s, keine switches, am besten nur lauter nops Vielleicht lohnt es sich doch, die verschachtelte Schleife in deiner Funktion irgendwie zu beseitigen. Das ist halt nur problematisch, weil nun ja, Algorithmus umdenken und so was, ist nicht trivial , kompliziert und man muss sich dabei anstrengen Aber damit hättest Du dann num_solvent_atoms mal was weiss ich wieviele Takte noch mal gespart. Und mit Sicherheit deinen Schein oder Prüfungsnote bekommen.

camper

pleevsevsi@farifluset.mailexpire.com

Die Wirkung der Optimierungsoptionen ist leider recht unzuverlässig, interessant vielleicht auch Acovea

Evtl bringt es hier etwas, ein wenig mit --param max-reload-search-insns=x herumzuspielen mit großen x (geht wahrscheinlich auf Kosten der Compilierzeit). In der Regel basiert die Suche nach den besten Optionen auf trial&error.

Und konnte noch viel aus dem Code rausgeholt werden?

by the hammer