• Welcome to SC4 Devotion Forum Archives.

Slow performance in Simulator Z

Started by shlarin, May 06, 2009, 03:58:19 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

shlarin

I've been using the March 2009 version of NAM on simulator Z and I have a region with a population of about 1,800,000.  It's structured with a central city on a 4x4 tile containing about 800,000 residents and 900,000 commercial (the vast majority of the region's commercial is in this center city.)  I have a very extensive subway network but a meager monorail (just one North-South and one East-West line running through the central city.)

Up until about a population of about 1,500,000 in the region, the simulator ran at an acceptable speed but now, it's been drastically slower.  Running the central city at the fastest speed setting, it takes about 5-10 minutes for roughly 2 sim months to pass by in game.  Usually, the simulator will run for about 1 minute for every 2 sim months then stop for a long time.  My other surrounding cities don't suffer from this problem but they're mostly residential and depend on this central city for jobs.

I'll post this region whenever I have the chance but I'm curious if this sort of slow performance is typical and expected.  My machine is a Core 2 Duo 2.4Ghz with 1 Gb of ram (and no, I don't hear the hard drive much when the simulation slows which rules out a memory problem.)

z

#1
No need to post your region; I can pretty much tell you what's happening.

First of all, what you're reporting is somewhat unusual, and in fact, I haven't heard of a slowdown as extreme as yours.  But significant slowdowns do happen occasionally, and there is an explanation for them.  Fortunately, there's a fix as well.

Simulator Z uses a pathfinding heuristic of around .005797, which is the ideal number for SC4, and is usually referred to as "perfect pathfinding."  Normally, as you lower this constant, CPU consumption increases somewhat exponentially.  But as you approach the ideal value, if the other parameters in the simulator are set properly (as they are in Simulator Z), the exponential terms tend to become more linear, and ideally disappear completely.  Measurements of Simulator Z have shown that a heuristic of .005797 consumes no more CPU time, on average, than a heuristic of .009, which produces much less accurate pathfinding.

Unfortunately, the key phrase there is "on average."  And while this applies to the vast majority of cities, there are still some cities where at least part of the exponential behavior still remains.  I've found it impossible to predict ahead of time which ones these are, but they do share two characteristics in common:  They have relatively large populations (always over a million), and they have many transit routes, typically including an extensive subway system.  The simulator has to find the best routes for each and every Sim, and with so many routes available, this can take a while.  The worst case occurs in cities in which there are many routes that are equivalent, with similar congestion, and the simulator has to take a long time finding out which route is fastest (even by a little bit).

There are two possible solutions here:  reduce the population, or reduce the number of route combinations.  Generally, only the second solution is feasible.  But generally it is quite feasible, and solves the problem nicely, with no side effects.  Generally, the solution that works best most of the time is to tear down a fair proportion of your subway routes.  This even speeds up the vanilla Maxis simulator.  (Too many subway lines will actually crash the  Maxis simulator when you try to save the game - very frustrating.)  However, as large numbers of subway lines are often necessary in other simulators for effective commuting, the effectiveness of Simulator Z's pathfinder makes large numbers of subway lines unnecessary.  Furthermore, if you look at your monthly costs, you'll notice that these lines are very expensive in Simulator Z, as they are in the real world.  So tear a number of them down, speed up your game, and save some simoleons while you're at it.  Please post what you find in this thread.  And for future questions about Simulator Z, please use the NAM Traffic Simulator Z Help thread.  Thanks!  :)

shlarin

I guess it's worth mentioning that I'm running SC4 in Linux (using an emulator.)  All of my cities run fine except for large central one.

I have about 5-6 subway lines running North-South and another 5-6 running east-west in almost straight lines.  There are also diagonal lines connecting the corners of this grid of subways.  So my network (located on a 4km x 4km map) looks something like:

___________
|X|X|X|X|X|
___________
|X|X|X|X|X|
___________
|X|X|X|X|X|
___________
|X|X|X|X|X|
___________
|X|X|X|X|X|
___________

I might consider removing some of the redundant subway lines (esp the diagonals) though many of my lines, esp near the edges, are already yellow, orange, or red even when running on Ultra.

z

Ah - you're running on an emulator.  I was wondering why you had such an extreme slowdown when using up-to-date hardware.

Normally, an emulator works reasonably well for most programs, as the amount of time spent in I/O (such as disk access) is very large compared to the amount of time running the emulator, and disk access takes the same amount of time whether you're running the emulator or in native mode.  But you mentioned you don't notice much disk activity when the simulator is running, and this is because the simulator is essentially CPU bound.  Unfortunately, for CPU bound processes, the role of the emulator becomes far more significant, and depending on the emulator, the program may easily run only at a fraction of its normal speed.  To really get around this problem, the solution would be to dual-boot using a separate native Windows system.

But then there's the question of why this city runs so much slower than the others.  Part of it is population; this is clearly the most populous city, and the number of possible traffic patterns for all the Sims put together grows faster than linear as the population increases, partially because you have to add more transportation infrastructure to handle your extra population.  But you have fewer subway lines that I thought you did when you said "extensive", and if the capacities are maxed out in the Ultra simulator, tearing down the subways is unlikely to help.  In fact, red in the congestion view for the subways in the Ultra simulator (assuming its red during both commute periods) means two things:  your subway line is carrying well over 100,000 Sims per day, and the congestion has caused the subway speed to drop into the realm of car and bus speeds.  This may actually be causing the simulator to work harder (and longer), as there are now many transportation routes of similar speed, and it tries very hard to find the best one.  You may actually get a performance improvement in your city by building more subway lines, placing the new lines near the most congested ones.  You may have to repeat this process a few times, but ultimately you want to get to a point where most lines show green in the congestion view, and there might be a little yellow here and there.  This may make finding the fastest route easier for the simulator, which would definitely speed it up.  Or you could try installing other rapid transit; GLR-in-Avenue and Tram-in-Road are good ways of doing this without taking up extra real estate.  And the trams run about as fast as the subways, and Simulator Z makes excellent use of them.  You could also try adding both subway lines and tram lines.

If this doesn't do the trick, then the emulator is just too much of an obstacle for what you're trying to do.  You could either try a dual boot solution, as I mentioned above, or use smaller city tiles.  Raising the pathfinding heuristic in the simulator would help a little bit, but not very much, and you would find your cities running much more poorly if you did that.  So you'd have a big loss for a little gain.  Therefore, I don't recommend going that route.

Pharaon-Kheops

#4
Wine Is Not an Emulator !!!  $%Grinno$%

Edit : Please refrain to dig out such old thread, especially with not so much value in your comment ~Wouanagaine~
"to be is to do" - Kant
"to do is to be" - Sartre
"to be or not to be" - Shakespeare
"to be do be do" - Sinatra