[11.10] Runway Length Calculation

[Sarlock]

I was toying around with the demo game and tried to add a couple of airplanes for fun and noticed some difficulty getting them to use the runways.

I made a test map and sure enough, I ran in to problems.  It seems that every plane requires a runway length that is double what it states.  For example, the Airbus A318 requires a runway length of 2,000m but actually needs a runway of 4,000m built (16 tiles).  A runway of 15 tiles long will not work.

Set up with default config of 250m/tile.



If I add one more runway tile to this, the plane will land and takeoff fine.

[waerth]

I believe default config is 125 m per tile so you would need 16 tiles for a 2000 meter runway. That would mean that indeed you would need to add 1 to your 15 tile runway.

[jamespetts]

You can confirm what the scale is by going to the minimap and selecting "show map scale".

[Sarlock]

Correct.

simuconf in the main folder is meters_per_tile = 250 but I see now that pak.Britain supercedes that at meters_per_tile = 125.  Thank you for pointing this out   Pretty much makes airplanes useless except on a very long map.

[jamespetts]

Correct.

simuconf in the main folder is meters_per_tile = 250 but I see now that pak.Britain supercedes that at meters_per_tile = 125.  Thank you for pointing this out   Pretty much makes airplanes useless except on a very long map.

...which is the intention: air travel is only used in reality for long distance journeys.

[ӔO]

There are Regional airlines/commuter airplanes/air taxis, which are a US phenomenon, what with poor intercity railway infrastructure, cheap tickets and modestly rich people.

[jamespetts]

How far do they fly?

[waerth]

I believe the shortest hop is from Miami to a city 50 kilometers away, forgot the name .....

But with a 64 bits version that you are working on sir James ....... we could allow larger maps

[Sarlock]

You can fly from Vancouver to Victoria here which is a 64km trip.  About 20 flights a day.  Faster (but not cheaper) than the ferry (ferry takes 90 minutes to cross plus the associated driving on either end).

https://www.google.ca/flights/?hl=en#search;f=YVR;t=YYJ;q=vancouver+to+victoria+air;d=2013-09-18;r=2013-09-22

EDIT:  Actually, it's $160 to take the ferry round trip with a single passenger in a car.  Pretty much the same cost... and loading/unloading times are similar to air travel.  Only advantage is that you get to have your car on the other end.

[jamespetts]

Ahh, it's not quite that simple: it would require changing some of the fundamental architecture of the code, which is possible in theory, but would be quite complicated. Larger maps - at least, larger maps with more than a few isolated areas of activity (towns and industries) would exert a very large performance demand on computers, and the architectural change necessary to allow larger maps would also greatly increase memory consumption for all sizes of maps.

I should add, incidentally, that the runway lengths required are all to scale, so it should be no less possible to have shorter distance trips in Simutrans than in real life.

[Sarlock]

It's probably more of a pakset calibration than anything for when plane travel becomes economical.  In the example I provided between Vancouver and Victoria, air travel becomes a viable choice for such a short distance because the alternative mode of travel (car ferry) is slower.

I'm interested to see the performance impact of Carl's map once it is complete with all of the convoys.  It's a good barometer to use to gauge what Simutrans-Ex is capable of performance-wise.  Doubling the map size he used would generate 4x the data and would probably make the computer grind to a halt.

In another 5 years, however...

[Carl]

A quick comment on larger maps. In a previous discussion, Kieron noted that storing labels in a 32-bit value -- which is currently the limiting factor on map size -- is a memory-saving device. The alternative, storing a pointer for every tile, would consume 64MB more on a maximum size map. By current standards (and especially if we get 64-bit working properly), 64MB of memory is fairly negligible. Perhaps it is worth considering whether this is worth pursuing. I suppose that this is not a project that Experimental would want to undertake in isolation from Standard, however, so maybe this suggestion is better suited to a wider discussion.


Of course, this doesn't alter the fact that a well-populated huge map will be far too CPU-intensive to do very much with at the present time. But as Sarlock intimates, this is something that will change with the development of faster CPUs.

[jamespetts]

This is an interesting discussion. Firstly, I should note that Carl's map actually is less CPU-intensive than the Bridgewater-Brunel server map: in version 11.9, it will fast-forward at 30-40x on my computer, compared to 13-14x for the Bridgewater-Brunel map (11.10 introduced a performance related bug that made this slower, which I have addressed in the 11.x branch).

However, the towns on Carl's map are based (approximately) on their real life sizes, whereas the towns in the Bridgewater-Brunel game have developed over more than 200 years of play, and developed in circumstances where a bug (a fix to which, written by Neroden, will be available in the next major release) caused towns to grow far too rapidly.

The Bridgewater-Brunel map was also started in Pak128.Britain-Ex 0.8.4, meaning that it has a scale of 250m/tile, rather than the default for version 0.9.0 of 125m/tile. Reducing the tile scale of the map means that one should start with the same number of towns for a map twice as large (in tiles). Given that it is towns that cause most of the CPU usage (mainly indirectly by providing demand for transport that players then fill with things that use the CPU), it should certainly be possible to have considerably larger maps than the current Bridgewater-Brunel server map within the performance window of current computers. That map is, however, a good way off the maximum size of a Simutrans map as things currently stand.

As for increases in CPU speed, it is an interesting question how much faster that they will get until people eventually work out how to make a practical quantum computer (which is probably still a fairly long way off yet; and, when people do, we could rewrite Simutrans in Javascript if we wanted and still have it run a map with 20m/tile the real size of the USA many times faster than Simutrans runs a modest sized map now; but I digress). We are not all that far off the quantum tunnelling limit for CPUs, and the strategy for a good while now for increasing computational speed has been to increase the number of processor cores rather than just to make each one faster; the trouble is with this that this requires applications to be written specifically for parallel or concurrent computing, and, given the way that Simutrans uses network code, this is not practicable, as there is no way to keep things synchronised whilst using parallel or (especially) concurrent algorithms for most things (parallel algorithms are used for loading/saving, and there is an element of concurrency in the graphics in multi-threaded builds, but these do not need to be synchronised in the same way).

[Sarlock]

I would imagine that the bulk of the processing time in Simutrans is reading/writing to memory.  We're probably still several speed doublings yet from reaching a plateau, before new technology makes the next leap.

[Carl]

This is an interesting discussion. Firstly, I should note that Carl's map actually is less CPU-intensive than the Bridgewater-Brunel server map: in version 11.9, it will fast-forward at 30-40x on my computer, compared to 13-14x for the Bridgewater-Brunel map (11.10 introduced a performance related bug that made this slower, which I have addressed in the 11.x branch).

However, the towns on Carl's map are based (approximately) on their real life sizes, whereas the towns in the Bridgewater-Brunel game have developed over more than 200 years of play, and developed in circumstances where a bug (a fix to which, written by Neroden, will be available in the next major release) caused towns to grow far too rapidly.

A couple of other things worth noting. First, towns are quite often a little smaller on the map than their real life size, especially when they sprawl a long way beyond what will be covered by the coverage of the rail network. (There is only so much mindless clicking a man can do in the name of eye candy! ). Also, with a few exceptions, towns and villages not served by the rail network aren't built at all. Furthermore, city growth is more or less disabled on this map. These things together go some way to alleviating the CPU load.

James: you mentioned that towns account for most CPU usage. I wanted to ask for a clarification on this. Does CPU usage scale with population, or merely with the amount of buildings? If there were two maps with the same population, but one had (say) twice the amount of buildings (i.e. much less dense population), would the second map consume significantly more CPU power?

[jamespetts]

James: you mentioned that towns account for most CPU usage. I wanted to ask for a clarification on this. Does CPU usage scale with population, or merely with the amount of buildings? If there were two maps with the same population, but one had (say) twice the amount of buildings (i.e. much less dense population), would the second map consume significantly more CPU power?

Although towns do contribute directly to CPU usage (the more buildings that there are, the more times that the CPU-intensive passenger generation code has to be stepped in any given period), that is relatively slight compared to the indirect effect: the more demand for transport that there is, the more transport that a player will build, and it is player transport that accounts for most CPU usage in a developed game.

[ӔO]

If the calculations require multiple repetitions, gpgpu would be better suited with its multiple cores, rather than a dual or quad cpu.

[jamespetts]

I am not familliar with GPGPU, but the issue with multi-threading is the requirement that each player in a multi-player game be exactly synchronised with each other player; for critical calculations, this is not practical in a multi-threaded environment, as the sequence in which the various calculations are completed (and therefore in which one thread interrupts another with the result) depends on variables such as the number of physical CPUs in a user's system, the speed of those CPUs, and what else is running on them at the time, and that sequence determines the sequence in which things occur during the game, and therefore must be synchronised between all playing computers. It is hard to see how this would be different if the multi-threading used GPUs instead of CPUs.

[ӔO]

The multithreading aspect, and its flaws, remains the same, but cpu workload can be drastically reduced by offloading it to gpu.
If the work is strictly arithmetic, that is.

[jamespetts]

Most Simutrans algorithms are a mix of arithmetic and logic, so this is unlikely to help in any event, it seems.