ich habe mal wieder eine Frage.

In meinem numerischen Code habe ich nun mal mit Arrays und Schleifen zu tun. Nun geht es mir um einen optimalen Zugriff.

struct A
{
  int ni;
  int nj;
  double x;
};

A a[iMax];
...
for(int i=0; i!=iMax; ++i)
{
  fkt(a[i].ni, a[i].nj, a[i].x);
}

for(int i=0; i!=iMax; ++i)
{
  A  *pA = &a[i];
  fkt(pA->ni, pA->nj, pA->x);
}

Bringt mir die 2. Variante Vorteile bzgl. Geschwindigkeit oder kann ich auch ohne Bedenken die 1. Variante nehmen da der Compiler das ohnehin optimiert?

Das Beispiel ist halt stark auf die Frage reduziert. Somit ist das nicht immer machbar auch weil es sich um gewachsenen Codes, zu Teil auch aus FORTRAN77 übersetzte handelt.

A* a_end = a+iMax;
for (A* pA=a; pA!=a_end; ++pA)
    fkt(pA->ni, pA->nj, pA->x);

Das ist das gleiche, wie:

for (auto pA=std::begin(a); pA!=std::end(a); ++pA)
    fkt(pA->ni, ->nj, pA->x);

und das ist das gleiche wie:

for (auto& pA : a)
    fkt(pA.ni, pA.nj, pA.x);

Wie man hierbei sieht, ist die beste Lösung identisch mit der übersichtlichsten.

for(int i=0; i!=iMax; ++i)
{
  A  *pA = &a[i];
  fkt(pA->ni, pA->nj, pA->x);
}

for(int i=0; i!=iMax; ++i)
{
  A  *pA = a++;
  fkt(pA->ni, pA->nj, pA->x);
}

oder

A* a = ...;
A* a_end = a + iMax;
while(a != a_end)
{
  A  *pa = a++;
  fkt(pa->ni, pa->nj, pa->x);
}

Ich werde erstmal den Code weiter bearbeiten wie bisher und nur ganz vorsichtig Änderungen in Angriff nehmen. Die Varianten kann ich dann ja in verschiedenen Simulationen laufen lassen und messen ob es Unterschiede gibt.

Blitz++ schaue ich mir mal an, bin aber eher skeptisch ob ich damit arbeiten werde. Im Zweifel ist eine lauffähige Version wichtiger als der mögliche Gewinn - wie gesagt es handelt sich um alte Codes aus Fortran Zeiten die übersetzt habe bzw. noch daran arbeite.

Die Varianten kann ich dann ja in verschiedenen Simulationen laufen lassen und messen ob es Unterschiede gibt.

Vergiss nicht, die Compileroptimierung auf das bestmögliche einzustellen und gegebenenfalls auch SSE, SSE2 oder so anzugeben oder entsprechende Prozessortypen (z.B. core2) einzustellen.
Im Allgemeinen gilt aber, dass der gesamt Code erstmal so übersichtlich wie möglich geschrieben wird und wenn alles funktioniert, bestimmt man mit dem Profiler die Engpässe und optimiert diese von Hand auf das Maximum, aber vorher nicht.

Im Allgemeinen gilt aber, dass der gesamt Code erstmal so übersichtlich wie möglich geschrieben wird und wenn alles funktioniert, bestimmt man mit dem Profiler die Engpässe und optimiert diese von Hand auf das Maximum, aber vorher nicht.

Nö, das ist mir zu stark. Man soll Performance von Anfang an mit im Auge haben.

bestimmt man mit dem Profiler die Engpässe und optimiert diese von Hand auf das Maximum

Und wenn du ein ineffizientes Design gewählt hast?
Oder bestimmte Algorithmen/Methoden, die langsam sind, und von denen die Struktur deines Programmes abhängt?

Ich denke, die Faustregel ist doch, all das, was austauschbar ist, nicht im Vorfeld zu optimieren?

bestimmt man mit dem Profiler die Engpässe und optimiert diese von Hand auf das Maximum

Und wenn du ein ineffizientes Design gewählt hast?

Effizientes Design gehört zur Grundlage des Programms und nicht zur abschließenden Optimierung.

Effizientes Design gehört zur Grundlage des Programms

Wo kommt jetzt auf einmal diese Ausnahme her? Du hast geschrieben

Im Allgemeinen gilt aber, dass der gesamt Code erstmal so übersichtlich wie möglich geschrieben wird

Nö, das ist mir zu stark.

Wo kommt jetzt auf einmal diese Ausnahme her? Du hast geschrieben

Im Allgemeinen gilt aber, dass der gesamt Code erstmal so übersichtlich wie möglich geschrieben wird

Ich finde die Aussage von Marthog absolut korrekt.

Im Allgemeinen gilt:
- Das Design so effizient wie möglich
- Die Implementation so kurz/einfach wie möglich
- Im Profiler nachgewiesene Engpässe optimieren

(Natürlich im Allgemeinen, manchmal lohnt sich schon im Voraus zu micro-optimieren, manchmal ist auch ein effizientes Design schnuppe)

Im Allgemeinen gilt:
- Das Design so effizient wie möglich
- Die Implementation so kurz/einfach wie möglich
- Im Profiler nachgewiesene Engpässe optimieren

Die Punkte widersprechen sich aber. Es geht nicht um Mikrooptimierungen (Ja, die Ausgangsfrage war eine Frage nach einer Mikrooptimierung, aber das ist sicher nicht das, was volkard und Sone meinen). Das Design sollte von Anfang an so effizient wie möglich sein, wozu Überlegungen zählen, was überhaupt effizient ist. Dies zieht dann eventuell aber eine nicht ganz einfache Implementierung nach sich. Ein schlechtes Design kannst du mit dem Profiler so sehr optimieren wie du willst, es wird dadurch nicht gut, außer du veränderst es komplett. Wenn du am Ende alles komplett umschreiben musst, dann wünscht du dir, du hättest von vornherein an Effizienz gedacht.

Die Punkte widersprechen sich aber.

Ein universeller Ratschlag ist immer widersprüchlich.

Es gibt aber Spielraum, was Design und was Implementation ist. Der Code in den Funktionen kann Implementation sein. Die Wahl des Algorithmus kann Implementation sein. Der ganze Parser (z.B.) kann Implementation sein. Die Strukturen zum Datenaustausch sollten generisch genug sein, mit verschiedenen Implementierungen ohne grobe Änderung klarzukommen.

1. Das Design so effizient wie möglich
2. Die Implementierung dieses Designs so kurz/einfach wie möglich (d.h. so einfach wie es geht ohne das effiziente Designs zu verändern)
3. Im Profiler nachgewiesene Engpässe optimieren

Damit es sinnvoll bleibt setzt das natürlich vorauss dass das "Design" relativ high-level ist, und keine sinnlosen, voreiligen und aufwendigen Optimierungen vorsieht/erfordert.

Es gibt aber Spielraum, was Design und was Implementation ist. Der Code in den Funktionen kann Implementation sein. Die Wahl des Algorithmus kann Implementation sein. Der ganze Parser (z.B.) kann Implementation sein. Die Strukturen zum Datenaustausch sollten generisch genug sein, mit verschiedenen Implementierungen ohne grobe Änderung klarzukommen.

Das ist ein richtiger, aber sehr allgemeiner Vorschlag. Aber von immer nur Abstrahieren passiert nichts. Irgendwann muss man konkret werden und Code schreiben, der auch wirklich etwas tut. Dann kann und sollte man auch mal im Voraus nachdenken, wie eine gute Implementierung aussieht.

codee schrieb:

Es gibt aber Spielraum, was Design und was Implementation ist. Der Code in den Funktionen kann Implementation sein. Die Wahl des Algorithmus kann Implementation sein. Der ganze Parser (z.B.) kann Implementation sein. Die Strukturen zum Datenaustausch sollten generisch genug sein, mit verschiedenen Implementierungen ohne grobe Änderung klarzukommen.

Das ist ein richtiger, aber sehr allgemeiner Vorschlag. Aber von immer nur Abstrahieren passiert nichts. Irgendwann muss man konkret werden und Code schreiben, der auch wirklich etwas tut. Dann kann und sollte man auch mal im Voraus nachdenken, wie eine gute Implementierung aussieht.

Hab ich das missverständlich geschrieben? Implementation = Quick and dirty, Gegenteil von Abstraktion.

Abhängig vom Grad der Abstraktion ist halt mehr oder weniger kurz/einfach.