Systemanforderungen - Reicht mein Rechner?

Ein kleiner Anhaltspunkt kann diese Seite sein:
http://www.game-debate.com/gam…32&game=Transport%20Fever
Dort kann man seine Specs eintragen und die werden mit den veröffentlichen Anforderungen verglichen. Dazu muss man natürlich ungefähr wissen was man in seinem Rechner verbaut hat

Hä warum hat meine Graka 143%?

Zitat von Shinji

Würde er garnicht da er die Kraft nicht auf die Strasse bingen kann und zudem wohl eher das Fahrzeug zerreissen würde.

wenn mann natürlich nur hohl vollgas gibt sicher.. easy mit gefüühl..

Ich mache mir erstmal keine Sorgen
Aber ich bin wirklich mal auf das Lategame gespannt, ob wir dort wieder Performance Probleme bekommen werden

Die Frage ist nicht "ob" sondern "ab wann" - jeder Rechner hat nunmal nur eine begrenzte Rechenleistung und das Spiel wird mit jedem Einwohner mehr Berechnungen benötigen. Zudem war TF soweit ich noch weis eine SingleCore Anwendung wodurch die heutigen hochleistungs CPUs ihre Leistung nicht ausspielen können und genauso "langsam" sind die wie die kleinen Brüder mit 1/4 der Kerne. Bin gespannt ob sie das beim Nachfolger verbessert haben.

Das ist nicht ganz richtig. TF lief ab einen bestimmten Update über 2 Kerne, was die Performance vor allem im Lategame schon ernorm gesteigert hat.

Also wenn ich spiele hab ich auf einem i7(4+4 Kerne) durchgehen eine Auslastung von 12-14% das sind 12,5% für einen Kern bei TF und der Rest(1-2%) für das restliche System.

Zitat von Shinji

Also wenn ich spiele hab ich auf einem i7(4+4 Kerne) durchgehen eine Auslastung von 12-14% das sind 12,5% für einen Kern bei TF und der Rest(1-2%) für das restliche System.

das kann ich von den Prozenten her bestätigen. Allerdings wenn ich im Taskmanager die Kerne in der Anzeige aufsplitte dann haben immer mindestens 2 der 8 kerne immer etwas zu tun mit TF.

Aber jeder nicht mehr als das sie in der Summe wieder 100% ergeben = einem Kern. Es wird vom System einfach die anfallende Arbeit gleichmässig auf alle Verfügbaren Kerne verteilt - soweit sogut - nur kann der 2. Kern eben nicht weiter rechnen ohne die Ergebnise des ersten Kerns wodurch letztendlich immer nur ein Kern an TF rumrechnet = SingleCore-Anwendung.
Eine solche Mehr-Kern Unterstützung muss/sollte man schon zu Beging der Programplanung festlegen da ein nachträgliches einbauen meist darin endet das man den ganzen Code neuschreibt.

Liesse sich einfach überprüfen: Man kann im BIOS/UEFI alle Kerne bis auf einen auschalten und schauen wie sich dies auf das Spiel auswirkt. Das problem mit den Prozentzahlen ist, dass man keine kontinuierliche überwachung hat. Es gibt nur einen bis zwei datenpunkte pro Sekunde. Zudem wird da munter die anzahle Kerne verdoppelt dank Hyperthreading. Also auf diese Daten würde ich nicht unbedingt vertrauen!

Du kannst selbst im(unter Windows) mitgeliefertem Taskmanager für jeden Prozess einstellen welchen der Kerne er benutzen darf - bei mir 0-7(i7 4+4 - 4x echter 4x HT halt). Normalerweise sind die Kerne 0-2-4-6 die echten und 1-3-5-7 die HT bei Intel unter Windows. Den Hacken nur bei einem Kern rein und schon geht dieser auf 100% hoch und die anderen "langweilen" sich vor sich hin(kann man auch im Laufenem Betrieb machen).

Und die Performance bleibt gleich, wenn TF nur auf einem Kern läuft?

Ich konnte da keine Unterschiede feststellen bisher(100% auf einem Kern) - allerdings hab ich seit dem DLC auch keine 20k Leute Karte mehr zur Verfügung, was an der Verarbeitung aber auch keinen Unterschied machen sollte. Sollte mich aber auch Wundern wenn ein weiterer Kern erst ab einer gewissen Belastung zugeschaltet werden würde.

In den FAQ steht dazu follgendes...

Zitat von UG

Q: Ist das Spiel für Late-Game Performance optimiert?

A: Ja! Mehrere neue Algorithmen optimieren die nötige Anzahl von
Berechnungen. Zusätzlich sorgt Multi-Core-Unterstützung für ein gutes
Spielerlebnis, selbst bei grossen Szenen.

Alles anzeigen

@Shinji Interessant! So viel ich weiss werden Threads in C++ einfach an den nächsten freien Kern vergeben, das heisst in deinem fall, alle Threads müssen in serie von einem Kern bewälltigt werden. Ich nehme an dass es im late-game dann jedoch probleme geben wird, wenn die rechenzeit einiger Threads mit der Anzahl Bewohner zunimmt.

Genau das ist doch der Punkt zB. bei den Rucklern am Ende der Monate wenn jeder einzelne Sim neu berechnet wird - beim Start des Spieles ist es noch wenig was berechnet werden muss - je nach CPU Leistung noch in weniger als der spürbaren Verzögerung - sobald die Möglichkeiten der Strecken und die Anzahl der Sim zunimmt Potenzieren sich die Möglichkeiten welche vom Kern durchgerechnet werden was natürlich mit der Zeit jede CPU an ihre Grenzen bringen wird.
Genau hier setzt dann die Multi-Core Unterstützung an bei der man überlegen muss was man nicht für das Hauptprogramm benötigt und einzlen als paralleler Lauf durch die CPU schicken kann ohne das das Hauptprogram stoppen muss weil das Ausgelagerte halt noch nicht fertig berechnet wurde --> in dem Fall hätte man die bekannten - und von allen geliebten - Monatsruckler.

Zitat von chrigulix

@Shinji Interessant! So viel ich weiss werden Threads in C++ einfach an den nächsten freien Kern vergeben, das heisst in deinem fall, alle Threads müssen in serie von einem Kern bewälltigt werden. Ich nehme an dass es im late-game dann jedoch probleme geben wird, wenn die rechenzeit einiger Threads mit der Anzahl Bewohner zunimmt.

Naja

Grundsätzlich hast du keine grosse Kontrolle wann welcher Thread abgearbeitet wird: Im System laufen immer viel mehr Prozesse und Threads als dir physische Kerne zur Verfügung stehen. Am Ende entscheidet das Betriebsystem welcher Thread jetzt wie viel Laufzeit bekommt. Kurz gesagt: Aus C++ erzeugst du einfach Threads, irgendwann später bekommt dein Thread einen Zeitschlitz in welchem er arbeiten kann. Dann wird dein Thread wieder unterbrochen und der nächste Thread bekommt einen Zeitschlitz in welchem er arbeiten kann, etc. Bei mehreren Kernen können dann mehrere Threads parallel arbeiten. In welcher Reihenfolge deine Threads gestartet und abgearbeitet werden hast du nicht unter Kontrolle. Du kannst dem System höchstens Hinweise geben welcher Thread mit einer höheren Priorität behandelt werden soll, aber auch dort hast du keine Garantie wie das vom System genau umgesetzt wird.

Hier ist sonst Lesestoff dazu: https://msdn.microsoft.com/en-…op/ms685096(v=vs.85).aspx

Und hier sonst ein kleines Beispiel: Es werden nacheinander 10 Threads erzeugt und gestartet, die Ausgabe kann aber völlig wirr durcheinander kommen (obwohl die Threads nacheinander gestartet wurden):

// Example program
#include <iostream>
#include <string>
#include <thread>
#include <set>
#include <memory>
#include <sstream>
using namespace std;
int main()
{
    // create threads
    set<shared_ptr<thread>> threads;
    for(int i = 0; i < 10; ++i)
    {
        struct Func
        {
            int i;
            void operator()()
            {
                stringstream ss;
                ss << "I'm thread nr " << i << endl;
                cout << ss.str();
            }
        };
        Func f = { i };
        shared_ptr<thread> pT = make_shared<thread>(f);
        threads.insert(pT);
    }
    // wait for completion
    for(set<shared_ptr<thread>>::const_iterator it = threads.begin(); it != threads.end(); ++it)
    {
        shared_ptr<thread> pT = *it;
        pT->join();
    }
}

Gibt dann als Ausgabe:

1. Durchgang:

I'm thread nr 3
I'm thread nr 2
I'm thread nr 1
I'm thread nr 5
I'm thread nr 6
I'm thread nr 0
I'm thread nr 4
I'm thread nr 7
I'm thread nr 8
I'm thread nr 9

Und im zweiten:

I'm thread nr 2
I'm thread nr 0
I'm thread nr 3
I'm thread nr 8
I'm thread nr 6
I'm thread nr 1
I'm thread nr 7
I'm thread nr 4
I'm thread nr 9
I'm thread nr 5

Yup, kannst froh sein, dass jeder Thread-Output auf einer seperaten Zeile gelandet ist und nicht nur willkürlicher Zaheln und Buchstaben salat entstand. Das starten eines Thread hat ja so ca. 30ms overhead vom Scheduler des Betriebssystems, darum ging das bei deinem Code nicht schief.

@chriguleix: Nein, deshalb schreibt jeder Thread seinen Output zuerst in den stringstream und dann wird der komplette String "in einem Rutsch" an cout übergeben.

Spart man sich den stringstream und macht direkt so etwas:

cout << "I'm thread << i << endl;

kommen die Ausgaben wirr durcheinander.

Mit dem join am Schluss ist sichergestellt dass die threads terminieren bevor main beendet. Ansonsten würde man früher oder später in ein direktes abort() laufen, da dass thread objekt zerstört wird während der thread noch läuft, was gemäss standard zu einem direkten abort() führt (ausser man ruft vorher ein detach() auf).

Edit: Habs noch kontrolliert: Ja, cout sind (meistens) threadsicher. siehe: http://en.cppreference.com/w/cpp/io/cout:

Zitat

Unless sync_with_stdio(false) has been issued, it is safe to concurrently access these objects from multiple threads for both formatted and unformatted output.

Ähm.. string cout ok keine Ahnung

Ich weiss nur dass mein Lategame vor dem damaligen Patch zur Dualcorenutzung von Trainfever wesentlich schlechter lief als nach dem Patch. Ergo hat es etwas bewirkt.