Nvidea 970 Preisrückerstattung

Seit wann ist TF Prozessorlastig?
Habe ich das was verpasst?
TF nutz nur 1,5 kerne soweit ich mich erinnere.

Genau das ist das Problem, anfänglich sogar nur 1 Kern. Darum die Performance Probleme...
Es wird sehr viel berechnet in Train Fever, wenn das nicht CPU lastig ist.

Zitat von DarkMo

Ein Spiel das seinen Rechenaufwand auf 4 Kerne verteilen kann hat also 4fache Leistung zur Verfügung. Bei ner 3GHz CPU bräuchte man also für die gleiche Leistung auf nur einem Kern eine 12GHz CPU

Grüß das Milchmädchen von mir.

Gut, vielleicht kann man jetzt nicht einfach die GHz addieren, genausowenig wie beim Speicher bzw. anderen Komponenten. Aber nur weil jetzt die Rechnung nicht 1:1 aufgeht, heißt das nicht, dass der Gedankengang dahinter nicht stimmt.
Würde TF alle 4 Kerne (oder wie viele man auch haben mag) ausnutzen, würde es sicher schneller laufen und es wäre meine CPU1 wohl nicht auf dauer-100% beim spielen.

Aber belassen wir das Ganze. TPF machts ja lt. FAQ besser, also werden wir uns nicht mehr lange damit herumschlagen.

Zitat von YstlDystl

TPF machts ja lt. FAQ besser, also werden wir uns nicht mehr lange damit herumschlagen.

Darauf hoffe ich sehr, da meine Karten nach über 1000 Jahren InGame-Spielzeit doch nur noch eingeschränkt spielbar sind...

Das Milchmädchen und die Männer

Milchmädchen sind keine Mädchen für eine Nacht. Sie sind Mädchen für ein Jahr, nämlich das berüchtigte Mannjahr.

Was macht das Mannjahr so berüchtigt? Wenn ein Mann ein Jahr braucht, um eine Aufgabe zu bewältigen, so schaffen es zwölf Männer nicht in einem Monat. Sie brauchen länger als einen Monat dafür. Das liegt daran, dass sie sich koordinieren müssen. Sie müssen sich immer wieder absprechen, die Arbeit verteilen und des öfteren muss einer auf den anderen warten.

So, jetzt hören bitte alle auf zu grinsen. Ob zwölf Männer ein Milchmädchen besser zufrieden stellen können, als es einer vermag, steht hier nicht zur Diskussion. Dieses ist eine ernsthafte Abhandlung in einem anständigen Forum.

Wenden wir uns nun wieder mit voller Aufmerksamkeit dem eigentlichen Problem zu. Früher war alles besser. Die Prozessoren wurden immer schneller, deren Takt stieg unaufhaltsam. Für den Programmierer war das sehr bequem. Er musste nichts tun, sein Programm lief einfach schneller.

Doch kurz nach der Jahrtausendwende war es mit all der Herrlichkeit vorbei. Der Takt ließ sich nicht einfach weiter steigern. Auch die Effizienz pro Takt stieß bald an ihre Grenzen. Eine weitere Steigerung der Rechenleistung war nur über das hinzufügen weiterer Rechenkerne möglich.

Passenderweise gab es zu dieser Zeit einen Boom von Anwendungen für Prozessoren mit mehreren Kernen. Immer mehr Menschen nutzten das Internet immer intensiver. Die Webserver mussten immer mehr Seiten möglichst gleichzeitig ausliefern. Auch erlebten Digitalkameras ihren Durchbruch. Die Bilder wollen bearbeitet werden. Diese Aufgabe lässt sich wunderbar auf viele Kerne verteilen, ebenso wie das erzeugen künstlicher Bilder mittels Raytracing und anderer Verfahren.

Jedoch lässt sich nicht jede Aufgabe parallelisieren. Ja, auch ein Milchmädchen hätte ein Problem mit zwölf Männern gleichzeitig. Und jetzt darf ich wieder um Ruhe bitten. Eine Aufgabe lässt sich dann gut parallelisieren, wenn sie sich in unabhängige Teilaufgaben zerlegen lässt. Dann kann jede Teilaufgabe mit maximaler Geschwindigkeit bearbeitet werden. Zum Schluss fügt man alle einzelnen Ergebnisse zu einem zusammen. Hängen aber einzelne Teilaufgaben von einander ab, so müssen sie synchronisiert werden. Das kostet Zeit. Das ist nicht effizient.

Ein Weg, Teilaufgaben unabhängig von einander zu gestalten, ist es, State zu vermeiden. State ist die Bezeichnung dafür, wenn sich ein Programm etwas merken muss. Den Teil eines Programms, der eine Teilaufgabe unabhängig von anderen bearbeitet, nennt man Thread. Wenn ein Thread den State verändert, mit dem auch ein anderer Thread arbeitet, dann haben beide unterschiedliche Daten. Einer hat die richtigen, der andere hat die falschen. So kommt es zu einem falschen Ergebnis, gerne auch mal zum Absturz oder in Netzwerkspielen zur Meldung, dass es Probleme mit der Synchronisation gibt. Die threads müsen sich also absprechen, wer was bearbeitet. Gegebenenfalls muss einer warten, bis ein anderer den State bearbeitet hat. Das ist dann nicht mehr parallel. Hier fängt der zweite Thread erst an, wenn der erste fertig ist. Das nennt man sequentiell. Es wird dabei nur ein Kern genutzt.

Schafft man es, State zu vermeiden, so können die Threads parallel an den Teilaufgaben rechnen. Es wird sich ja nichts gemerkt, auf das ein anderer warten müsste. Leider ist State das wesentliche Merkmal klassischer, imperativer und objektorientierter Programmierung. Ein Objekt ist State mit zugehörigen Funktionen, die diesen State verändern. Die Lösung kommt aus dem Bereich der funktionalen Programmierung. Dort gibt es keinen State. Alles ist eine Funktion. Funktionen ohne State sind immer unabhängig von einander. Sie können auf mehreren Kernen parallel laufen.

Aber wie merkt man sich etwas, wenn man nur Funktionen hat? Gar nicht! Werte merkt man sich nicht, man generiert bzw. berechnet sie jedes mal aufs Neue, wenn sie gebraucht werden. Das klingt jetzt sehr ineffizient. Im einfachsten Fall liefert eine Funktion einen konstanten Wert oder berechnet etwas aus konstanten Werten. Das lässt sich sehr effizient umsetzen. Bei komplexen Berechnungen ist es nicht sinnvoll. Hier muss man Funktionen mit möglichst wenig State kombinieren. Das führte erst zur Entwicklung funktionaler Programmiersprachen, die mit Objekten umgehen können und in den letzten Jahren zu funktionalen Erweiterungen objektorientierter Programmiersprachen allen voran C++ und Java.

Auch helfen Bibliotheken von Funktionen den Programmierern bei der Anpassung ihrer Programme auf mehrere Kerne. Das Zauberwort heißt Streams. Das sind von einander unabhängige Datenströme. Schwierig bleibt es aber weiterhin, den nötigen State in unabhängige Teile zu zerlegen, auf die man dann die Streams ansetzen. kann.

Zitat von fjb

So, jetzt hören bitte alle auf zu grinsen... ...Dieses ist eine ernsthafte Abhandlung in einem anständigen Forum.

So, so....

..

Eine gute und vor allem verständliche Erklärung der Problematik; auch für uneingeweihte.

Zitat von fjb

Das Milchmädchen und die Männer

Eine echt wunderschöne Ausführung!

Aber...

Zitat von fjb

Ja, auch ein Milchmädchen hätte ein Problem mit zwölf Männern gleichzeitig.

...das kann gar nicht sein! Das weibliche Geschlecht ist doch angeblich Multitasking-fähig.

Und...

Zitat von fjb

Die Lösung kommt aus dem Bereich der fuktionalen Programmierung

Die Art der Programmierung kenne ich noch nicht - klingt aber sehr interessant.
Wo kann ich ein Seminar buchen?

WTF - SCNR...

SSE und AVX sind ein weiteres Zauberwort.

Zitat von Tom

Wo kann ich ein Seminar buchen?

Da Du den Fehler gefunden hast, nehme ich Dir diese Mühe ab. Den Fehler habe ich dank Dir korrigiert.

Zitat von Mr_Tattarisuo

SSE und AVX

Das sind Vektor-Einheiten. Die gab es seit spätestens den 80erjahren des letzten Jahrhunderts in Großrechnern. Heute sind sie selbst in Mikrocontrollern enthalten. Sie haben ihre Hauptanwendung in der Numerik, sind aber auch auch für Spiele ganz brauchbar. Mit ihrer Hilfe kann man Rechenoperationen auf ein Array von Zahlen anwenden. Das geschieht sehr effizient, zumindest teilweise parallelisiert und spart dem Programmierer das ineffiziente Iterieren über das Array.