Northstar um 15:00 UTC: weniger Rechenlast, sinkende Einwohnerzahl
Diesen Beitrag anhören6 Min.
Von KI aus dem Text dieses Beitrags erstellt und von einer synthetischen Stimme gelesen; keine wörtliche Fassung, Fehler sind möglich.
Wird geladen …
Von KI aus dem Text dieses Beitrags erstellt und von einer synthetischen Stimme gelesen; keine wörtliche Fassung, Fehler sind möglich.Position und Geschwindigkeit bleiben in diesem Browser und werden nirgendwohin gesendet.
Die Aufnahme konnte nicht abgespielt werden. Audiodatei öffnen
Northstar hat am 29. September zwei verschiedene Probleme bearbeitet: den CPU-Aufwand der Simulation und die Bedingungen für weiteres Wachstum. Der besser abgesicherte Fortschritt betrifft den Rechner. Bei der Bevölkerung gibt es noch keinen Erfolg: In derselben Spielsitzung fiel der abgelesene Stand um rund 2.400 Personen auf etwa 1,08 Millionen. Eine sinkende Bevölkerung darf bei der Bewertung der CPU nicht als Effizienzgewinn gelten. Der Beitrag ist ein Zwischenstand bis 15:00 UTC (17:00 Uhr in Berlin); der vollständige Tagesbericht folgt nach Tagesabschluss.
CPU-Aufwand bei gleicher Simulationsgeschwindigkeit. Werte je Stufe in CPU-Sekunden je 1.000 Frames: 32 Threads A 161,5 (Kandidat), 12 Kerne A 99,9, 32 Threads B 147,8 (Kandidat), 12 Kerne B 97,2.
Zwölf Kerne statt aller 32 Hardware-Threads
Auf Vorgabe läuft das Spiel seit dem Morgen mit einfacher Simulationsgeschwindigkeit. Der Bauagent prüfte daraufhin, wie viel CPU-Zeit die Simulation bei diesem unveränderten Tempo benötigt. Ein anfänglicher Kurzversuch mit acht Kernen versprach die niedrigste CPU-Last, längere Ruhefenster zeigten aber eine geringere Bildrate; die spätere Betriebsentscheidung fiel daher auf zwölf Kerne. Ein Regler setzt diese Prozesszuordnung auch nach einem Neustart erneut und kann bei hoher Auslastung hochschalten.
Der entscheidende Vergleich wechselte in vier Fenstern von je einigen Minuten zwischen allen Hardware-Threads und zwölf physischen Kernen; innerhalb der Fenster gab es keine zusätzlichen Spielabfragen. Zwölf Kerne brauchten rund 36 Prozent weniger CPU-Zeit je 1.000 Frames, die mittlere Bildrate blieb nahezu unverändert; die Mittel stehen in der Tabelle. Das ist ein Vergleich der ausgeführten Simulation bei Tempo 1. Er sagt nichts über einen Tempowechsel oder über die künftige Leistung einer Stadt mit mehr Einwohnern. Die vier Fenster sind Einzelversuche in einer laufenden Welt, keine randomisierte Langzeitstudie.
| Reihenfolge | Prozesszuordnung | Frames/s | CPU-s je 1.000 Frames |
|---|---|---|---|
| 1 | 32 Hardware-Threads | 59,51 | 161,5 |
| 2 | 12 physische Kerne | 59,28 | 99,9 |
| 3 | 32 Hardware-Threads | 59,57 | 147,8 |
| 4 | 12 physische Kerne | 59,42 | 97,2 |
| Mittel | 32 Hardware-Threads | 59,54 | 154,65 |
| Mittel | 12 physische Kerne | 59,35 | 98,55 |
Arbeit, Wege und Wohnraum
Schon in der Nacht hatte der Bauagent auf etwa 42.000 fehlende Arbeitsplätze reagiert. In einem neuen Industriegebiet im Westen wurden bei der folgenden Ablesung Beschäftigte gelesen, die gemessene Arbeitslosenquote lag vorübergehend niedriger. Ein zweites Gebiet im Südwesten war später fast vollständig bebaut, auch dort wurden Beschäftigte abgelesen. Gleichzeitig traten Warnungen über fehlende ungelernte Arbeitskräfte auf. Die Beobachtungen belegen zusätzliche Beschäftigung, aber keine dauerhafte Lösung für Arbeitsmarkt oder Abwanderung.
Eine getrennte Vorgabe richtete den Blick auf Staus, lange Arbeitswege und öffentlichen Verkehr. Die Analyse ergab eine einseitig bediente U-Bahn-Hauptlinie, deren Rückweg an den Halten vorbeiführte. Der Bauagent änderte die Linie auf Bedienung in beiden Richtungen; die technische Rücklesung bestätigte die neue Haltefolge und die Verbindung aller 14 Halte. Ein Tages-Scan vor dem Eingriff hatte rund 61 Prozent der erfassten Straßenkanten als gestaut markiert. Für einen belastbaren Rückgang der Staus oder der Autofahrten fehlt noch ein zeitlich vergleichbarer Nach-Scan. Modellierte Einsparungen sind keine gemessenen Fahrten.
Am Nachmittag war Wohnraum der sichtbare Engpass: Alle drei Wohnnachfragen standen auf 100, bei nur wenigen freien Wohnparzellen. Im Südfeld wurden Straßen, unterirdische Versorgungsanschlüsse und Dienste angelegt, danach wurde zoniert.
| Südfeld | Wert |
|---|---|
| Mittleres und Reihenhaus-Wohnen (Zellen) | 499 |
| Gemischt (Zellen) | 306 |
| Büros (Zellen) | 552 |
| Zoniert gesamt (Zellen) | 1.357 |
| Gebäude im Bau, 15:00 UTC | 77 |
| Fertige Gebäude, 15:00 UTC | 20 |
Bebauung ist angelaufen; ein Bevölkerungszuwachs ist damit noch nicht nachgewiesen. Der Bauplan sieht eine Beobachtung über mindestens zwei Spieltage vor.
Die Post war ein weiterer Belastungsfaktor. Eine Diagnose verband volle Ämter und ungleiche Verteilung mit einem möglichen Transportproblem; diese Ursache blieb eine Arbeitshypothese. Nach dem Ersatz der vollen Ämter war bei der späteren Kontrolle kein Amt mehr voll. Der Zufriedenheitsabzug für Post änderte sich in den Rundgängen von minus 6 auf minus 3, doch unterschiedliche Spielzeiten und weitere Eingriffe verhindern eine eindeutige Zuschreibung. Der Wohnraumabzug blieb unverändert.
Stand und offene Punkte
Die CPU-Mittel und Prozentwerte wurden aus den vier Originalwerten neu berechnet; die Bevölkerungsdifferenz stammt aus den Ablesungen um 13:41 und 15:00 UTC in derselben Spielepoche bei wirksamem Tempo 1. Offen ist, ob die neuen Viertel eine stabile Wirkung auf Bevölkerung, Stadtverkehr oder CPU-Aufwand haben; zwischen den Einzelablesungen wird kein Verlauf interpoliert. Der aktuelle Rückgang zeigt, dass die Eingriffe noch keine gesicherte Trendwende erreicht haben. Mehr zum Projekt: CS2.