Northstar at 15:00 UTC: less CPU work, a falling population
Listen to this post6 min
Created by AI from the text of this post and read by a synthetic voice; not a word-for-word version, and it may contain errors.
Loading…
Created by AI from the text of this post and read by a synthetic voice; not a word-for-word version, and it may contain errors.Position and speed stay in this browser and are sent nowhere.
The recording could not be played. Open the audio file
Northstar worked on two separate problems on 29 September: the CPU cost of the simulation and the conditions for further growth. The better-supported progress concerns the computer. The population has not improved: in the same game session the reading fell by around 2,400 people, to about 1.08 million. A falling population must not be counted as an efficiency gain when judging the CPU figures. This is an interim status up to 15:00 UTC (17:00 in Berlin); the full daily report follows after the day closes.
CPU Load at the Same Simulation Speed. Values per step in CPU seconds per 1,000 frames: 32 Threads A 161.5 (candidate), 12 Kerne A 99.9, 32 Threads B 147.8 (candidate), 12 Kerne B 97.2.
Twelve cores instead of all 32 hardware threads
On instruction, the game has run at normal simulation speed since the morning. The building agent then checked how much CPU time the simulation needs at this unchanged speed. A short initial trial with eight cores promised the lowest CPU load, but longer idle windows showed a lower frame rate, so the later operating decision was twelve cores. A controller re-applies this process assignment after a restart and can switch up under high load.
The deciding comparison alternated between all hardware threads and twelve physical cores over four windows of a few minutes each, with no additional game queries inside the windows. Twelve cores needed around 36 percent less CPU time per 1,000 frames, while the mean frame rate was nearly unchanged; the means are in the table. This compares the simulation as executed at speed 1. It says nothing about a change of speed or about the future performance of a city with more residents. The four windows are single trials in a running world, not a randomised long-term study.
| Order | Process assignment | Frames/s | CPU-s per 1,000 frames |
|---|---|---|---|
| 1 | 32 hardware threads | 59.51 | 161.5 |
| 2 | 12 physical cores | 59.28 | 99.9 |
| 3 | 32 hardware threads | 59.57 | 147.8 |
| 4 | 12 physical cores | 59.42 | 97.2 |
| Mean | 32 hardware threads | 59.54 | 154.65 |
| Mean | 12 physical cores | 59.35 | 98.55 |
Jobs, routes and housing
During the night the building agent had responded to about 42,000 missing jobs. In a new industrial area in the west, employees were read at the next reading, and the measured unemployment rate was temporarily lower. A second area in the southwest was later nearly fully built, and employees were read there as well. Warnings about missing unskilled workers appeared at the same time. These observations show additional employment, not a lasting solution for the labour market or for people leaving.
A separate instruction turned attention to congestion, long commutes and public transport. The analysis found a main metro line served in one direction only, its return trip passing the stops by. The building agent changed the line to serve both directions; the technical read-back confirmed the new stop sequence and the connection of all 14 stops. A daily scan before the change had marked around 61 percent of the recorded road segments as congested. A comparable scan after the change is still missing, so no reliable drop in congestion or car trips can be stated. Modelled savings are not measured trips.
In the afternoon housing was the visible bottleneck: all three housing demands stood at 100, with few vacant residential parcels. In the south field, roads, underground utility connections and services were laid out, and zoning followed.
| South field | Value |
|---|---|
| Medium and row-house residential (cells) | 499 |
| Mixed (cells) | 306 |
| Offices (cells) | 552 |
| Total zoned (cells) | 1,357 |
| Buildings under construction, 15:00 UTC | 77 |
| Finished buildings, 15:00 UTC | 20 |
Construction has started; a population increase is not yet shown. The build plan calls for observation over at least two game days.
Mail was a further burden. A diagnosis linked full post offices and uneven distribution to a possible transport problem; that cause remained a working hypothesis. After the full offices were replaced, no office was full at the later check. The mail satisfaction penalty changed from minus 6 to minus 3 across the walkthroughs, but differing game times and other interventions prevent a clear attribution. The housing penalty stayed unchanged.
Status and open points
The CPU means and percentages were recomputed from the four original values; the population difference comes from readings at 13:41 and 15:00 UTC in the same game epoch at effective speed 1. Whether the new districts have a stable effect on population, city traffic or CPU cost is still open, and no trend is interpolated between the individual readings. The current decline shows that the city interventions have not yet produced a secured turnaround. More on the project: CS2.