Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Proposed high-level design goal: performance target

Started by Matthew, January 23, 2021, 06:26:18 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


In recent weeks, the join times and lag on the Bridgewater-Brunel server have 'swung between the sublime and the ridiculous' (= changed between very good and very bad).

Now that we have good performance, I am very keen that we keep it and reflect on how things got so bad for so long. It seems to me that this was partly due to misunderstandings: it was not adequately recognized that memory bandwidth and usage had become the main performance bottleneck. And it was partly because James and other coders have been adding new features on a regular basis, which is a really great problem to have!  ;D

But at the moment, the high-level design goals of the project make no reference to performance. I think that is a mistake, because poor performance means many, maybe all, of the benefits listed in that document become unattainable and unappreciated.

I propose that it should be not only a design goal, but a design rule, that the game should be coded so that the Bridgewater-Brunel game never exceeds ~7.5GiB, so that it never goes into swap space. This is a measurable, achievable design goal that brings immediate and obvious benefits.

I can think of three objections to this change.

Firstly, it is rude of a non-coder to impose burdens and limits on the coders who generously give their time and energy to the project. There is a lot of truth in that, but this is only a proposal; it will be up to coders to decide whether you wish to limit yourselves in this way.

Secondly, it is selfish, because I am a Bridgewater-Brunel player and I am limiting the whole community so that I can have fun. That is also a fair point, but I think it should be recognized that B-B is Sim-Ex pushed to its performance limits. If B-B has poor performance, then the experience of other players is likely to be even worse, either because their large/compex maps are unplayable or because their map sizes and complexity are limited.

Thirdly, that it it is wrong in principle to base the general development of Sim-Ex on a single server. This is a good point in theory, but I think it falls down in practice for three reasons. As mentioned above, B-B is very demanding in terms of memory bandwidth and usage. For a long time I only used single-player mode, mainly for personal reasons, but partly because B-B's memory requirements were unaffordable. So it is a good test of the principal bottleneck. In addition, B-B is by far the most active multiplayer game on the listserver. Maybe there is a hidden community of Sim-Ex multiplayers in Japan, but I think it's fair to say that if B-B performance is poor, a large percentage of the active playerbase has problems. Finally, I think that this particular chicken has long since flown the coop (= this argument is not good because we already break it). The most recent and obvious example is that when B-B upgraded to Ubuntu 20.04, the official releases dropped support for almost all other Linux versions. I think (and I said at the time) that it was a sensible use of James' time to upgrade B-B to 20.04. But the system requirements of the whole project were based on the needs of that one server and nothing else. I could give other examples, but I think that one is sufficient.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese


There is a real ambiguity here: do you mean the Bridgewater-Brunel saved game from to-day, or any conceivable future such game? It is possible in principle to target a particular level of memory usage for a particular saved game, but not for an unspecified hypothetical saved game; and there is no certainty that the Bridgewater-Brunel server will run games of exactly this size in the future; indeed, it will be almost impossible to make sure that it does, especially as city growth algorithms change over time. Even a bug fix might have a massive effect on memory usage: the bug fix to private car routing had this effect, and a bug fix to city growth could also have a similar effect, albeit more gradually. Also, there is no certainty that the hardware specifications of the Bridgewater-Brunel server will remain unchanged over time.

Rather than aiming for a specific level of memory usage, it would make more sense to try to ensure a reasonable level of performance on whatever the main servers for online games are at the relevant time, in so far as this is realistic. One of the purposes of the Bridgewater-Brunel server has precisely been to work out just what size of game can yield a reasonable level of performance over the long-term. This is extremely hard to test when a game can take 1-2 years to reach the present day.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.