class Enemy; /*Der normale Gegner . Besitzt ausserdem eine Funktion namens 
               "ManageEnemy" . Diese Funktion enthählt die KI des Gegners*/

void Levels::Level1() /*Diese Funktion ist ein Teil der Hauptschleife .Ausserdem
                        Gehört sie einer Klasse an damit die Instanzen von Enemy
                        Nicht nach der Funktion zerstört werden . Nehmen wir 
                        einfach an dass 20 Instanzen existieren*/
{
/*

Dieser Teil ist uninteressant

*/
For(int j=0;j<20;j++)
{
if(Enemy[j].Alive/*Ein Bool der angibt ob der Gegner lebt*/)
{
Enemy[j].ManageEnemy();
}
}
}

Jetzt ist mir aber letztens eine neue Methode eingefallen um die Gegner zu verwalten . Hierbei sind in der Klasse Levels keine Instanzen sondern Pointer namens "PEnemy" :

int Levels::Level1()
{
/*

Dieser Teil ist uninteressant

*/
for(int j=0;j<20;j++)
{
if(PEnemy[j]!=NULL)
{
if(PEnemy[j]->ManageEnemy/*Gibt diesmal nen Wert in Form eines Bools zurück der
                            angibt ob der Gegner gestorben ist*/)
{
delete PEnemy[j];
PEnemy[j] = 0;
}
}
}
}

Jetzt wollte ich wissen was ihr unter welchen Bedingungen besser findet .

Ich könnte mir allerdings massig Methoden vorstellen, die noch besser als die erste Methode sind, aber dazu müsste man genaueres über dein Modell wissen. Da du anscheinend nichts mehr mit den toten Gegnern machst, käme so ziemlich jede Art von Datenstruktur in Frage, aus der man Elemente löschen kann, also unter anderem so ziemlich jede der Containerklassen der Standardbibliothek.

Wenn das Alive oft wechselt, waere es evtl. eine Idee sich zu merken bis zu welchem Index die lebenden Gegner sind und wenn einer stirbt/wiederbelebt wird einfach zwei Eintraege im vector zu tauschen.

Andererseits ist bei 20 Elementen solche Optimierung pure Zeitverschwendung, so langsame Rechner gibts heut ja gar nicht mehr.

Ich koennte mir das schon vorstellen, denn die Pointer liegen hintereinander im Speicher, die Alive flags hingegen nicht.

Ich bin mir jetzt nicht ganz sicher aber ich halte die erste Lösung für schneller.
Bei der Anzahl der Gegner müssten doch auch die Alive flags optimal im Speicher liegen, ist immerhin ein Array von Enemies[] und das Alive flag ist ein member von enemies.
Vielleicht passt das Enemies[] Array sogar in eine processor line aber mindestens in eine Cache Line. Ein Pointer würde da nur eine unnötige weitere Indirektion bedeuteten, weil der Content auf den der Speicher zeigt mit größerer Wahrscheinlichkeit nicht im Cache und nicht auf einer Prozessorline liegt.

Oder habe ich irgendwo einen Denkfehler?

TGGC schrieb:

Ich koennte mir das schon vorstellen, denn die Pointer liegen hintereinander im Speicher, die Alive flags hingegen nicht.

Ich bin mir jetzt nicht ganz sicher aber ich halte die erste Lösung für schneller.

Hier wahrscheinlich ja. Aber generell kann diese Form der Datenlokalität in Extremfällen durchaus relevant werden in Hochleistungsanwendungen. Aber dann gibt es viel bessere Wege dies in C++ zu kapseln.

Auf den Designfehler der zweiten Methode, dass die Level-Klasse auf einmal Speicher verwalten muss (und dies auch noch äußerst schlecht implementiert) gehe ich mal nicht näher ein.

Vielleicht passt das Enemies[] Array sogar in eine processor line aber mindestens in eine Cache Line. Ein Pointer würde da nur eine unnötige weitere Indirektion bedeuteten, weil der Content auf den der Speicher zeigt mit größerer Wahrscheinlichkeit nicht im Cache und nicht auf einer Prozessorline liegt.

Was ist bitte eine Prozessorline, und was meinst du wie gross eine Cache Line ist?

Ruvi schrieb:

Vielleicht passt das Enemies[] Array sogar in eine processor line aber mindestens in eine Cache Line. Ein Pointer würde da nur eine unnötige weitere Indirektion bedeuteten, weil der Content auf den der Speicher zeigt mit größerer Wahrscheinlichkeit nicht im Cache und nicht auf einer Prozessorline liegt.

Was ist bitte eine Prozessorline, und was meinst du wie gross eine Cache Line ist?

Also nach meinem Verständnis (vielleicht irre ich mich gut möglich) ist eine Cache Line größer als, dass was der Prozessor mit einem Happen verarbeiten kann und deswegen wird die Cache-Line mit offset gejoint und "Prozessor line" wär für mich persönlich die Menge an Daten die der Prozessor in einem Happen verarbeiten kann. Ich glaube das ist die Register size aber ich bin mir da jetzt nicht ganz sicher, so tief stecke ich nicht drinn.

Vielleicht ist das falsch oder ich habe mich falsch ausgedrückt hier mal eine korrigierte Fassung die genereller gehalten ist:

Vielleicht passt das Enemies[] Array sogar in eine cache line aber höchstwahrscheinlich ist es im Cache. Ein Pointer würde da nur eine unnötige weitere Indirektion bedeuteten, weil der Content auf den der Speicher zeigt nicht in einer Cache line liegt und mit größerer Wahrscheinlichkeit nicht im Cache.

"premature optimization is evil"

Oder:
`Rules of Optimization:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it yet.

Rule 3: profile before optimizing`

Und zum original Poster: Fang doch erst mal an, den Code richtig zu formatieren. Ich wundere mich, dass hier so viele Leute trotzdem den Code lesen. Ich schaue mir so etwas erst gar nicht an.

Hallo! Ihr diskutiert über Optimierung, solange das Programm noch nicht mal da ist. Leute, schreibt doch erst mal das Programm, so wie es soll.

QFT.

@Ruvi:
Wir wissen weder wie gross eine "Prozessorline" noch ein Cacheline noch eine enemy Klasse beim OP ist und auch nicht wieviel zwischen zwei Durchlaeufen passiert was den Cache wieder leeren kann. Wieviele Objekte von den 20 alive sind, wissen wir auch nicht. Wie soll man da also ausschliessen, das eine Methode der 2 schneller ist?

QFT.
@Ruvi:
Wir wissen weder wie gross eine "Prozessorline" noch ein Cacheline noch eine enemy Klasse beim OP ist und auch nicht wieviel zwischen zwei Durchlaeufen passiert was den Cache wieder leeren kann. Wieviele Objekte von den 20 alive sind, wissen wir auch nicht. Wie soll man da also ausschliessen, das eine Methode der 2 schneller ist?

Ganz klar zählt natürlich measure first aber, es gab ein Artikel und 1 Vortrag von Herb Sutter die mich was Pointer in Container/Datenstrukturen angeht ein wenig wachgerüttelt haben und die Quintessenz dessen war, dass "->" in modernen Prozessor Architekturen eine sehr teure Operation ist und man sie nicht ohne Not verwenden sollte.

Der Artikel:
http://gameprogrammingpatterns.com/data-locality.html

und auch diesem Vortrag von Herb Sutter:
http://channel9.msdn.com/Events/Build/2014/2-661
Zwischen 23,30min und 41,05min.

Ganz klar zählt natürlich measure first aber, es gab ein Artikel und 1 Vortrag von Herb Sutter die mich was Pointer in Container/Datenstrukturen angeht ein wenig wachgerüttelt haben und die Quintessenz dessen war, dass "->" in modernen Prozessor Architekturen eine sehr teure Operation ist und man sie nicht ohne Not verwenden sollte.

Der Artikel:
http://gameprogrammingpatterns.com/data-locality.html

und auch diesem Vortrag von Herb Sutter:
http://channel9.msdn.com/Events/Build/2014/2-661
Zwischen 23,30min und 41,05min.

Hat der original Poster irgendwas von Performance gesagt? Ist das irgendwie von Bedeutung? Ist die Stelle, die hier angefragt wird Performancekritisch? Wir wissen es nicht. Daher sollte man das so programmieren, dass es lesbar und gut wartbar ist. Und sich auf keinen Fall irgendwelche Gedanken um Performance machen. Schon die Erwähnung von Performance führt die Leute zu leicht zu unnötig unleserlichen Code. Also lass es einfach.

Back2Topic:

@TE:
Leider hast Du den Rest deiner Architektur nicht näher erläutert aber wie SeppJ schon geschrieben hat gibt es da sicherlich Optimierungspotenzial.

Was den Code angeht den ich sehe würde ich wie SeppJ schon geschrieben hat einen STL::Container verwenden, du hast dort eigentlich freie Auswahl.

Ich würde an deiner Stelle auch RAII verwenden (und damit

unique_ptr<Enemy> ptr;

) um deinen Speicher zu verwalten.
Es ist seit dem neuen Standard äußerst untypisch native Pointer memory "ownen" zu lassen.
Der Speicher würde in dem Moment freigegeben in dem du das Objekt aus deinem Container löschst und der Destruktor des SmartPointers aufgerufen wird.

Ansonsten würde ich persönlich ranged based for oder Schleifen mit Iteratoren - int basierten Schleifen vorziehen.