I have been doing a little ancillary work on merging the latest version of Standard into Experimental (Bernd Gabriel has done the bulk of the work), and I have looked into multithreading. From what I understand it, this is used for graphics, loading/saving and map rotating, is that correct?
If that is so, am I right in thinking that there is little point in having a multithreaded network server? My Bridgewater-Brunel (http://www.bridgewater-brunel.me.uk) server currently uses only a single core, for which I pay less than were I to use multiple cores. Multithreading might make a difference to saving/loading, I suppose, but that does not seem to be a worthwhile reason alone to upgrade to another core, especially when I am told that more savings can be made by switching from bzip2 to ordinary zip files for saving/loading.
It works as you say, it's not worth to pay for a additional core in a network server.
The load/save multithreading is limited to two threads. One for file i/o+compress/decompress, and one for serializing the game objects. Rotation and graphics can use more if compiled as such, but not important for a server.
Using two threads for loading results in 54% faster for bz2, 15% gzip, 2% binary.
Saving is 6% bz2, 44% gzip, -4% binary.
bz2 is ~8x slower than gzip for Simutrans saves, so definitely a bigger factor. Single threaded you do give up the 44% faster gzip saves, but it should be taking <10 secs to save gzip anyways.
Useful information, thank you! One possible means of achieving this efficiency is to have a server running two cores and two games, which would make use of the additional core when loading/saving, borrowing from the other running game, but this would only be useful if neither game runs at anywhere near 100% CPU - so of marginal utility, probably.