Kurze frage zu einem Spielprogramier problem

Meine Erfahrungen zum Thema Assembler: Zum einen haben Compiler sehr viele Tuningmöglichkeiten, die man zum Teil aber explizit aktivieren muss (der Intel Compiler geht da übrigens ab wie Schmitz Katze, da kommen andere Compiler nicht dran). Zum anderen, um einen hochoptimierenden Compiler mit Assembler zu schlagen, bedarf es sehr viel Erfahrung. Nicht umsonst gibt es Leute, die sich auf so etwas spezialisieren. Besonders im HPC-Umfeld gibt es da einige Leute, die machen echt krude Sachen um noch den letzten Pfurz Performance aus dem Cluster zu kitzeln ;-)
 
Eines frage ich mich nur, wie sind unendliche Schleifen möglich, da Assembler soweit ich weiß keine eigenen Schleifen besitzt.
 
Ich glaube der TO weiß nicht genau was eine CPU Architektur ist...

Edit: Wenn du VS hast kannst du dir den Assembler Output anschauen.. Das sagt glaube ich mehr aus als jetzt zu erklären was JMP Befehle sind..
 
Naja, es gibt viele Dinge, die du aus Hochsprachen kennst, die aber in Assembler nicht direkt existieren.

Zum einen sagt mir diese Aussage, dass der Compiler wohl besseren Code produzieren würde (nicht böse gemeint). Zum anderen gibt es bereits innerhalb der Hochsprache selbst Dinge, die Auswirkungen auf die Performance haben - bevor der Compiler seine Finger dran bekommt. Beispielsweise kannst du durch ungünstige Schleifen auf Arrays sogenannten Cache Thrashing erzeugen, was die Performance tief in den Keller bringt, da es sich hierbei meist um speichergebundene Probleme handelt (also die Geschwindigkeit direkt von der verfügbaren Speicherbandbreite abängt). Das sind zum Beispiel so Sachen wie Vektoraddition oder AXPY.

Das Optimieren des Assembly Codes ist also die letzte Stufe einer langen Latte von möglichen Optimierungen. Wenn du da vorher schon Mist gebaut hast, wirst du das untenrum nicht mehr retten können.
 
Naja, es gibt viele Dinge, die du aus Hochsprachen kennst, die aber in Assembler nicht direkt existieren.

Zum einen sagt mir diese Aussage, dass der Compiler wohl besseren Code produzieren würde (nicht böse gemeint). Zum anderen gibt es bereits innerhalb der Hochsprache selbst Dinge, die Auswirkungen auf die Performance haben - bevor der Compiler seine Finger dran bekommt. Beispielsweise kannst du durch ungünstige Schleifen auf Arrays sogenannten Cache Thrashing erzeugen, was die Performance tief in den Keller bringt, da es sich hierbei meist um speichergebundene Probleme handelt.

Das weiß ich, Assembler ist fast Maschinen Code, daher gibt es sehr vieles nicht, oder nur indirekt. Zudem muss man alles selbst machen z.B. Die Variablen in den Speicher schreiben.

Das es nicht böse gemeint glaube ich dir auch so, da Anfängercode nun mal nicht optimal ist, gerade bei Assembler kann jeder Fehler fatale Folgen haben.
Mache ich irgend etwas "falsch"? Der Stack hat ja nur 8 MB, jedoch kann ich mühelos Vektoren habe die insgesamt weit über 100 MB groß sind, jedoch gebe ich nicht an, dass ein neues Objekt eines Vektors im Heap gespeichert werden.

Werden Vektoren also immer auf dem Heap erzeugt? :huh:
 
Aber ist es nicht theoretisch möglich C++ mit Lisp zu Kombinieren, also "C++L" :ugly:
gute frage. aber rein theoretisch: wieso nich. mir fällt in bezug auf logische programmiersprachen nur die beispiel-anwendung als ki ein. damit war aber glaube eher prolog gemeint. aber im endeffekt kann man ja auch problemlos sql mit c usw verbinden. und sql ist nun bei weitem auch keine imperative sprache ^^ zählz glaube auch zur 4th generation language oder (c usw zur 3rd...)? wie war das? maschinen code war erste, dann asambler, dann die hochsprachen, dann die logischen allgemein? oder eher genereller formuliert? also es ging im kernpunkt eher darum, dass der "code" näher ans gesprochene wort kommt mit jeder generation. aus 0en und 1en wird jpnz bla bla wird ne for schleife (ausm arm gezaubert) wird "gib mir alle daten zu..." ^^ achne, sql zählte zu den descriptiven sprachen *glaub* sag nicht WIE ein problem gelöst wird, dag WAS du möchtest, das wie passiert intern von ganz allein. also hätten wir imperative, logische und descriptive? das wird ja langsam kompliziert ><

edit:
Mache ich irgend etwas "falsch"? Der Stack hat ja nur 8 MB, jedoch kann ich mühelos Vektoren habe die insgesamt weit über 100 MB groß sind, jedoch gebe ich nicht an, dass ein neues Objekt eines Vektors im Heap gespeichert werden.

Werden Vektoren also immer auf dem Heap erzeugt? :huh:
soweit ich weiß (ich sollte den mist eigentlich grad büffeln :ugly: ) sind heap und stack die dynamischen bereiche des speichers eines prozesses. aufm stack wird eher "interner" kram gespeichert (zeugs fürn sheduler), während der heap wohl für die ganzen variablen is. aber wie gesagt, ich bin noch beim büffeln, aber irgendwie sowas stand da ^^
 
soweit ich weiß (ich sollte den mist eigentlich grad büffeln :ugly: ) sind heap und stack die dynamischen bereiche des speichers eines prozesses. aufm stack wird eher "interner" kram gespeichert (zeugs fürn sheduler), während der heap wohl für die ganzen variablen is. aber wie gesagt, ich bin noch beim büffeln, aber irgendwie sowas stand da ^^
Ja, das kommt in etwa hin.

Dynamischer Speicher wird in C und C++ nur verwendet, wenn du das als Entwickler explizit tust (malloc in C, new in C++). Globale statische Daten, deren Größe zur Compilezeit feststehen, werden im sogenannten Datensegment des Programms abgelegt - und das kann durchaus größer als 8 MB sein. Lokale Variablen, die innerhalb einer Funktion nicht-statisch deklariert werden, werden allerdings auf dem Stack angelegt.

Edit:
Will nicht Mark Zuckerberg eine Programmiersprache entwickeln, mit der Zitat: "Jeder Programmieren kann"?
Naja, es gibt durchaus Sprachen, die sehr einfach sind, bspw. Python. Wer das nicht rafft, kommt auch mit den anderen Sprachen nicht klar.
 
habs sogar fix gefunden, siehe anhang ^^ btw wird scheinbar der komplette adressraum (bei 32bit also die ganzen 4gig) in diese bereiche aufgeteilt - gilt wohl also prozessübergreifend.
 

Anhänge

  • bs_script_adressraum.png
    bs_script_adressraum.png
    38,5 KB · Aufrufe: 41
Soweit ich weiß, kann unter 32 Bit 1 Prozess die 4 GB nutzen, jedoch bleibt wegen fehlender Adressbits nichts mehr für die andern übrig.
 
rein theoretisch, ja. er kann ja adressen mit 32 bit ansprechen - also eben diese 4gig. jedoch bekommen andere prozesse ja auch speicher zugesprochen und auslagerung auf sekundärspeicher (platte ^^ - virtueller speicher bla) gibts auch noch. uund win limitiert(e - also die 32bit systeme) auf max 2gig je prozess.
 
Nein. Moderne OS nutzen das Konzept des virtuellen Speichers und Paging. Prinzipiell verfügt jede 32 Bit Anwendung über ihren eigenen Adressraum von 4 GB, wobei das in der Praxis natürlich nicht alles nutzbar ist. AFAIK ist bei 32 Bit Windows sogar bei 2 GB Schicht im Schacht, sofern die Anwendung nicht Large Address Aware ist (dann 3 GB bei 32 Bit bzw. volle 4 GB bei 64 Bit/WOW64). Das ist ein relativ komplexes Thema, um das jetzt noch zu dieser Uhrzeit in Textform erläutern zu können :D
 
Ich nutze lieber Linux als Windows, unter Linux hat man keine Begrenzung das maximalem Speichers auf 192 GB (Win 7 ab Proffesional).
 
Da verstehst du mich falsch. Ich spreche von 32-Bit Anwendungen, da ist auch bei Linux mit 4 GB das Maximum erreicht. Was ich meinte, unter Windows 32-Bit kann eine 32-Bit Anwendung out of the box keine vollen 4 GB Speicher nutzen, da ist meist bei 2 GB Schluss. Die Anwendung muss mit Support für große Addressen kompiliert werden, um mehr nutzen zu können (mal wieder Legacy-Kram aus alten Tagen). Jedenfalls ist dieses Flag auch bei 64-Bit Windows erforderlich, sonst bekommt die 32-Bit Anwendung auch da nur 2 GB. Bei echten 64-Bit Anwendung besteht dieses Limit nicht.

Abgesehen davon, was Paging und virtuellen Speicher angeht, das funktioniert auch so unter Linux. Das wird nämlich zum Teil von der Hardware vorgegeben.
 
Ok, danke für die Aufklärung.

Solche "Diskussionen" bringen mich weiter, man kann schließlich kein Haus bauen, wenn man keine Grube ausgräbt.
Je exakter die Grube ist, desto besser. :daumen:
 
Das ist wohl war, zumal Paging bei der Spieleentwicklung durchaus ein Problem werden kann. Ausgelagerter Speicher muss nämlich von der Platte wieder in den RAM geladen werden und das bedeutet lange Wartezeiten.
 
Das kenne ich von meinem System zu gut 1GB RAM @217 MHz (DDR 400 Slots auf dem Board), jedoch immer noch schneller als die Platte.
Die Aufgabe für Performance ist so wenig wie Möglich den Speicher bewegen. Da der Speicher langsam ist.
 
Zurück