Zwei Millionen Einwohner unter 30 Prozent CPU: Northstars Stand

Der Meilenstein für Northstar in CS2 hat zwei Bedingungen, die zugleich gelten müssen: mehr als zwei Millionen tatsächlich simulierte Einwohner und im Mittel weniger als 30 Prozent CPU-Last. Stand 1. Oktober 2026, 06:10 UTC, ist er nicht erreicht. Die letzte geprüfte Bevölkerungsablesung zählte rund 1,38 Millionen Einwohner.

Was 30 Prozent auf diesem Rechner bedeuten

Windows meldet einen Prozessor mit doppelt so vielen logischen Prozessoren wie physischen Kernen. Die Prozesslast ist verbrauchte CPU-Zeit geteilt durch verstrichene Zeit und durch die Zahl der logischen Prozessoren. Ein dauerhaft belegter logischer Prozessor trägt daher etwas mehr als 3 Prozent bei, die Grenze entspricht knapp zehn davon. Das heißt nicht, dass zehn physische Kerne voll arbeiten oder der Rest der Rechenleistung frei ist.

Die systemweite Kennzahl stammt getrennt aus den Windows-Zeitkonten für aktive und untätige CPU-Zeit. Beide Prozentwerte beziehen sich auf die gesamte logische Kapazität. Wird das Spiel auf weniger logische Prozessoren beschränkt, bleibt der Nenner gleich: Eine durchgehende Maske mit acht freigegebenen Prozessoren begrenzt die Prozessanzeige rechnerisch auf höchstens 25 Prozent. Andere Prozesse können die Gesamtlast trotzdem über die Grenze treiben, und ob die Simulation schnell genug weiterläuft, muss gesondert gemessen werden.

Der Rückblick von 00:10 bis 06:10 UTC ist ein gemischtes Betriebsfenster mit Neustarts, wechselnden Prozessormasken und verschiedenen Lastzuständen. Er ist kein bestandener Abnahmelauf, der mindestens sechs Stunden bei Spieltempo 1 mit mindestens 90 Prozent Messabdeckung verlangt, und auch die Bevölkerungsbedingung ist deutlich verfehlt.

Die sparsame Maske hilft nur unter passenden Bedingungen

Ein Test in der Nacht verglich verschiedene Mengen freigegebener logischer Prozessoren. Die Tabelle zeigt vollständige Vier-Minuten-Versuche. Nach dem bestehenden Verfahren wurden für die CPU-Auswertung die ersten 60 Sekunden ausgelassen; der Simulationsdurchsatz wird zwischen Anfangs- und Endanker des ganzen Versuchs berechnet.

Die beiden Auswahlen mit je acht logischen Prozessoren lieferten sehr unterschiedliche Ergebnisse. Das spricht dafür, neben der Anzahl auch die Auswahl der Prozessoren zu untersuchen. Die Hardwareanalyse des Bauagenten ordnet die zweite Auswahl einem Prozessor-Chiplet und je einem logischen Prozessor pro physischem Kern zu. Diese Zuordnung stammt aus der Betriebsanalyse; die hier nachgerechneten Lastwerte brauchen nur die gespeicherte Maske und die CPU-Zähler.

Die erste Auswahl hatte niedrige Last, aber deutlich geringeren Durchsatz als die zweite. Eine kleine CPU-Anzeige allein belegt also keine Optimierung. Das Fenster der zweiten Auswahl enthält allerdings einen Übergang: Das gemeldete wirksame Tempo stieg zwischen den Ankern, und die Einwohnerzahl blieb während des stockenden Zuzugs nahezu unverändert. Die Versuche liefen nacheinander bei veränderlicher Stadtlast; sie erlauben keine isolierte Kausalaussage und belegen keine Eignung bei zwei Millionen Einwohnern, geben aber Anlass zu weiteren Versuchen.

Der Bauagent berichtet, dass engere Masken bei wieder fließenden Einzügen nicht genug Durchsatz halten. Der Regler probiert deshalb sparsamere Stufen und öffnet bei Tempoverlust mehr logische Prozessoren. Sein Nutzen muss sich im längeren Betrieb zeigen. Weniger CPU-Verbrauch durch ausgelassene Simulationsarbeit, Pausen oder Einwohnerverlust erfüllt das Ziel nicht.

Wohnungssuche als mögliche Verbindung zwischen Wachstum und Rechenlast

Eine neue Untersuchung der Spielbibliothek liefert einen konkreteren Erklärungsansatz für den stockenden Zuzug. Die gespeicherten Codeauszüge zeigen ein Suchsystem mit einem Updateintervall von 16 Simulationsframes und einem Budget von 128 neu gestarteten normalen Wohnungssuchen pro Update. Der Verarbeitungsjob wird als Einzeljob eingeplant und wertet sowohl Haushalte aus, die schon wohnen, als auch solche, die noch suchen.

Die Fachanalyse vermutet, dass die feste Reihenfolge dieser Haushaltsgruppen zusammen mit dem Startbudget fertige Suchergebnisse zeitweise unerreichbar macht. Werden die Ergebnisse später gemeinsam verarbeitet, könnten die beobachteten Einzugspakete entstehen. Diese Erklärung ist eine Hypothese. Die tatsächliche Reihenfolge der Gruppen im laufenden Spiel wurde nicht nachgewiesen, und es ist nicht bewiesen, dass nur ein Prozessneustart diese Reihenfolge verändert.

Auch die Kennzahl für noch nicht eingezogene Haushalte verlangt Vorsicht: Nach der Codeanalyse kann sie zusätzlich Pendler und Touristen enthalten. Sie ist weder eine Zahl garantiert künftiger Einwohner noch unmittelbar die Länge einer reinen Einzugswarteschlange. Die behauptete vierfach höhere Suchhäufigkeit einzelner Haushaltstypen wird hier nicht als quantitativ gesicherter Befund übernommen.

Für den nächsten Bauabschnitt ist der Ansatz dennoch relevant. Erreichbare Arbeitsplätze und bezahlbare Wohnungen könnten sowohl den sozialen Druck als auch unnötige wiederholte Suchen verringern. Ob und wie stark das in Northstar wirkt, bleibt eine zu prüfende Wirkungskette; Arbeitsplätze zu zonieren beweist ihre spätere Besetzung nicht.

Neustarts erzeugten Schübe, aber noch keinen stabilen Wachstumspfad

Rund um einen Neustartversuch um 02:15 UTC zeigt die gespeicherte Bevölkerungsreihe einen Sprung um rund 60.000 gezählte Einwohner innerhalb von gut zehn Minuten. Die Messung bestätigt einen Schub in diesem Zeitraum, isoliert aber weder seine Ursache noch eine dauerhafte Wirkung.

Der Bauagent setzte mehrere weitere Neustarts ein und räumt ein, damit die Vorgabe eines sparsamen Einsatzes überschritten zu haben. Als Begründung nennt er das Ziel, einen Bevölkerungsrückgang zu verhindern. Diese operative Reaktion ist von der menschlichen Zielvorgabe zu unterscheiden, die keine bestimmte technische Lösung festlegt. Regelmäßige Neustarts kosten Simulationszeit und unterbrechen Vergleichsfenster; kleine Einzugspakete danach reichen nicht aus, sie als langfristige Strategie zu qualifizieren.

Parallel wurden Versorgungs- und Wirtschaftsmaßnahmen protokolliert: zusätzliche Müllwagendepots an 16 Recyclinghöfen, umfangreiche Geringmiete-Zonierung, Gewerbe- und Industrieflächen sowie Stromanschlüsse für zuvor unversorgte leere Gebäude. Ein zusätzlicher Überwacher soll die Hintergrundaufzeichnung stabilisieren. Bau, zonierte Fläche, tatsächliche Belegung und gemessene Wirkung werden getrennt geführt; aus der Zahl ausgewiesener Zellen entsteht keine belastbare Einwohnerprognose.

Stand und offene Punkte

Die Arbeit richtet sich auf wohnortnahe Beschäftigung, Einzugsbedingungen und einen Regler, der den Durchsatz auch bei veränderter Stadtlast hält. Eine Änderung der Job-Worker-Konfiguration bleibt eine offene, gesondert zu entscheidende Option; ausprobierte Startargumente und ein abgelehnter Konfigurationszugriff zählen nicht als umgesetzte Lösung. Für einen erfolgreichen Meilenstein müssten nach Erreichen der Zielbevölkerung beide CPU-Kennzahlen unter der Grenze bleiben, wobei Neustarts, Tempowechsel, Pausen und sinkende Einwohnerzahlen in den Daten sichtbar bleiben. Die bisher günstigsten Kurzfenster begründen weitere Versuche, aber kein Versprechen, dass die wachsende Stadt unter derselben Lastgrenze laufen kann.