Issues w/ Larger Cities?

[Jazzmaster 716]

It doesn't really improve performance as much as it improves stability, I believe. Placing the entire load on one core isn't something I'm keen on; the fans blow a bit hard whenever I play SC4 on this notebook.

SC4 can only use one core. My laptop has an i7 720qm, each core is clocked at 1.6 GHz.

Disabling two of the cores can force the OS to clock the cores to around or over 2 GHz.

I'm not concerned about heat as the most I ever got with SC4 and TF2 running at the same time was high 70 C.

Oh, I know. And the heat isn't really an issue for me either, as I have two large vents in the rear of this computer that push the heat out quite nicely. Just wish it didn't have to all be on one core, but it's simply not possible. Oh well, right?

[A Nonny Moose 8,261]

It doesn't really improve performance as much as it improves stability, I believe. Placing the entire load on one core isn't something I'm keen on; the fans blow a bit hard whenever I play SC4 on this notebook.

SC4 can only use one core. My laptop has an i7 720qm, each core is clocked at 1.6 GHz.

Disabling two of the cores can force the OS to clock the cores to around or over 2 GHz.

I'm not concerned about heat as the most I ever got with SC4 and TF2 running at the same time was high 70 C.

Oh, I know. And the heat isn't really an issue for me either, as I have two large vents in the rear of this computer that push the heat out quite nicely. Just wish it didn't have to all be on one core, but it's simply not possible. Oh well, right?

Don't wish for things. You might get them.

What improvement do you think you can make on a simulation program that spends most of its time in one subprocess, namely the traffic path finder. Single threading is what I would use if I was writing this new. The GPU does all the multi-threading you need if it is used properly. It runs asynchronously with the rest of the program.

[Jazzmaster 716]

I suppose the only improvement I would make on a simulation game that spends most of its time in one subprocess, is to make it spend most of its time in this one subprocess without crashing so easily.

[PBGV103 729]

How about using one thread exclusively for calculations, like the clock, expenses, population, etc. and a second thread just for loading the image files and things like that? Doesn't that make sense?

[Loney 22]

How about using one thread exclusively for calculations, like the clock, expenses, population, etc. and a second thread just for loading the image files and things like that? Doesn't that make sense?

I would prefer splitting up the threads and assign them to a small specific task, great for processors with many slow cores and GPU might able to pickup the load of the small threads. The only issue is that it might increase the chance of a deadlock, two threads relying on each other but also competing for resources, and that would increase freeze-ups.

I know a friend who accidentally coded his custom program to spawn thousands of threads that were dependent on each other regardless of the load placed on the program. Small wonder why there were so many freeze-ups.

  Edited October 10, 2011 by Loney  

[A Nonny Moose 8,261]

There is a required technique in multi-threading called "critical section coding" in which a semaphore is set so that a process in this section of code cannot be pre-empted by another part of the same program. This facilitates inter-process communication.

As a process enters the critical section it must attempt to set the semaphore. If the semaphore is already set by another process, the process trying to enter must wait for the process already in the critical section to exit, resetting the semaphore. Examples are updating a critical queue or a graphics frame buffer.

The critical code must be bullet proof and fast. This kind of code is often written in assembly language to avoid as many overheads as possible. It has to be small, and is often interrupt inhibited as well. A failure in this area of code will generally cause the watch-dog timer of the system to declare a panic if too much time is spent in such code.

If there is no watch-dog timer, a careless programmer can hang the whole system.