Multi-core support please!

[2457]

actually 2 engine 2 transmission and 2 clutch powering the same thing IS reality.
lotta DIY tractors used to do this.
check it out:
http://www.youtube.com/watch?v=_AmMeixh_LQ

not to mention, its a verry good arrangment.
anyhow...


at least, if there are enough cores available,
witch is nowdays quite common, as instead of double core, quad cores are getting more than popular,
ship, airplane, and RV/rail PF may have theyr own cores.
least that is something...

so i understand train pathfinding is hard to do multi-core, as calculations depend on eatch other.
if there was enough cores, could one of them check and filter pathfinding dependencies, so the rest of the cores can do the tasks that do not interfer ? (or given a quad core, make that 2 cores findling with it) ?
would that increase performance quad-cores?

[Eddi]

you could try making ship, train and road (except onto level crossings) movement use one core each. everything else creates a HUGE administrative overhead, which is likely to eat up almost all of the speed improvements you might get. and then you touched maybe 20% of the game and sped that one up by possibly 30%, making an overall 6% speed increase of the game, but lots of potential desyncs.

[Transportman]

you could try making ship, train and road (except onto level crossings) movement use one core each.

But don't you get issues at stations then, with cargo loading and unloading?

[kutagh]

you could try making ship, train and road (except onto level crossings) movement use one core each.

But don't you get issues at stations then, with cargo loading and unloading?

If you do those in a sequential manner before calculating routes, by iterating over all stations and handling the loading/unloading aspect there, that should allow you to do it multithreaded. Whether it is worth it is another question entirely and should be viewed as a test case.

[YNM]

you could try making ship, train and road (except onto level crossings) movement use one core each. everything else creates a HUGE administrative overhead, which is likely to eat up almost all of the speed improvements you might get. and then you touched maybe 20% of the game and sped that one up by possibly 30%, making an overall 6% speed increase of the game, but lots of potential desyncs.

Hmm, well, 6 cores (includes the existing ones).

Yes, I think there might be desyncs, but after all, trains and road vehicles don't run on water tiles and ships don't run on rails (apart from IH).

[Rubidium]

Vehicle movement still updates the same set of collision and location caches. For every vehicle (part) you will update these caches for each (sub) move they make, which in short means on average about once every tick. Fast vehicles are moved several times a tick, slow vehicles once every few ticks. In any case, this means lots and lots of locking/unlocking calls.

[Eddi]

that probably shouldn't be done by locking the cache, but rather by making sure the update function is atomic/thread safe. (assuming there's one phase where only updates to the cache are done, and another phase where the crash detection is done)

[Baldy's Boss]

Is the "near future" referred to when this thread started in 2008 coming to a close yet?

[Dave]

No, in short.

[AdolfoRojo]

OpenTTD won't support multiple cores in the near future, as that will create lots of problems (mostly with multiplayer desyncs);

About the 200 plane limit, go to "configure patches" -> "vehicles" and set "Max aircraft per player" higher.

Today 24 July/2015: seven years later...
My conclution: Is a shame that game dont have multicore support, (and today don't work in that) this is the future in computers. OpenTTD was condemned to die does not suit multi-core process.
Plase consider idea.

Thank You.

[Mister_X]

The most steps should be executed sequentially, but some could be executed parallel. For example, all ships could execute the path finding part parallel instead of sequential, because there are no dependencies between ships.
But trains are dependent to other trains, and a lot of code for moving trains should be rewritten to make it usable for threads. (For example: Signal states and track reservations at junctions should be handled by the junctions self instead by trains.)

[AdolfoRojo]

The most steps should be executed sequentially, but some could be executed parallel. For example, all ships could execute the path finding part parallel instead of sequential, because there are no dependencies between ships.
But trains are dependent to other trains, and a lot of code for moving trains should be rewritten to make it usable for threads. (For example: Signal states and track reservations at junctions should be handled by the junctions self instead by trains.)

Yeah. And the airplane can ejecuted in parallel.
For reduced resourses, you can eliminated unnecesary signals in trains (finally reduced a lot of code).
Worth a try!

[Mister_X]

Yeah. And the airplane can executed in parallel.
For reduced resources, you can eliminated unnecessary signals in trains (finally reduced a lot of code).
Worth a try!

As long as most programmers never want to program multi core, this part of code will never be multi core because no one want to give support on it. (And it stays an never ending story.)

[Expresso]

OpenTTD won't support multiple cores in the near future, as that will create lots of problems (mostly with multiplayer desyncs);

About the 200 plane limit, go to "configure patches" -> "vehicles" and set "Max aircraft per player" higher.

Today 24 July/2015: seven years later...
My conclution: Is a shame that game dont have multicore support, (and today don't work in that) this is the future in computers. OpenTTD was condemned to die does not suit multi-core process.

You have been brainwashed by the marketing machines of the processor manufacturers. Just because a game doesn't support multiple threads, doesn't mean it stops being fun all of a sudden. And last time I checked fun is what matters more to a game to be fun then the amount of threads it manages to generate.

OpenTTD uses a separate thread for cargo distribution, but I'm sure you do not mean that.

I have not seen a game (closed or open source) which supports the amount of modification openttd does. In OpenTTD NOTHING is constant and EVERYTHING is open to change... and keep in mind the maps can be HUGE.

In that regard I'm quite appreciative of the openttd devs that they manage to make the game run fast, even at higher map sizes, and features being added over time.

But if you want to modify the rest of openttd to run everything at the same time, without loosing stability or performance, go right ahead. OpenTTD is an open source project and everybody is free to make changes to it. That includes you too.

[Phreeze]

in 2015 you have computers that give a blablubb about performance needs ^^ i have never stuffed up a 4k map,but evenon full 1024 maps, the cpu is nearly not used^^

[leifbk]

On my five year old Linux system with a 2.8 GHz i7 Quad and 6 GB RAM, OTTD runs comfortably in one thread; the load is barely noticeable. But then, I've only got a few hundred vehicles on a 256x512 map.

The original TTD was designed to run on a 20 MHz 386 with a few Megabytes of RAM, I believe. Even if OTTD is a reimplementation written in C++ while the original was written in assembler, it's no resource hog. You might of course hit the wall with a huge map and thousands of vehicles, but I don't think that is the normal way of playing the game. On the contrary, I guess that most people appreciate the challenge of a rather small map. Even a 512x512 size map tends to get boring in my experience, it's just more of the same. Too much mechanical routine work and too few chances to sit back and just watch the traffic.

[Eddi]

The original TTD was designed to run on a 20 MHz 386 with a few Megabytes of RAM, I believe.

Let me tell you from personal experience, that this was totally not the case. after like 10 years of game time, you maxed out the 80 trains with 1 engine+5 wagons each, and the ticks took like 2 seconds. that is 0.5fps. you should have had a 60 MHz 486 to play the game at a reasonable speed.

[leifbk]

The original TTD was designed to run on a 20 MHz 386 with a few Megabytes of RAM, I believe.

Let me tell you from personal experience, that this was totally not the case. after like 10 years of game time, you maxed out the 80 trains with 1 engine+5 wagons each, and the ticks took like 2 seconds. that is 0.5fps. you should have had a 60 MHz 486 to play the game at a reasonable speed.

OK, I stand corrected

A 60 MHz 486 was actually what I had at the time I purchased the game on a 3½ inch floppy, about 1995. I didn't have that machine for long before I replaced it with a 133 MHz Pentium.

[kamnet]

From what I've read in recent discussions, the bottleneck is not the single core processing, but the fact that video driver support has moved from hardware to software. Your newest PC likely has a built-in video card with mostly software driving the video, where your PC from 10 years ago had all of that working on a separate hardware video card.

[Mister_X]

Since the original game, a lot of game limits are improved.
The supported screen resolution of 640x480 is increased up to a HD resolution and above.
The maximum number of vehicles are increased from 500 to 20.000.
Number of network players are increased to 15 and all traffic is fully synchronized.

And of course the many bug fixes and improvements like pre-and path-signals, path finding algorithms, bigger stations and support to load extra grf-files.

The most improvements will cost more CPU power. For example, we could use 15 x 20.000 = 300.000 vehicles in one map and that's 6000 times more than the 500 vehicles in the original version.

For the original version, we needed 60 MHz for 500 vehicles. So for 300.000 vehicles, we need at least a CPU speed of 60x6000 = 360.000 MHz = 360 GHz !
This calculation is a little but overstated of course, but I want to explain here that due to all improvements now and in the future the game needs more and more CPU speed to run this game.