[11.10] Performance

[Carl]

Performance seems markedly worse in 11.10 (32-bit) compared to 11.9. On the saves I've uploaded recently I can average 16-18x fastforward speed in 11.9. In 11.10 this is down to about 4-5x fastforward. (This is reflected on other maps, too.)


As for the 64-bit version, this currently gives an "application unable to start" error (0xc000007b). Are any new dlls required?

[jamespetts]

Hmm - will look into the performance issue.

As to the 64-bit version not starting, can you try downloading the 64-bit version of the redistributable here and seeing whether it works after that?

[asaphxiix]

there is a 64 bit version? or did you just mean running the game on win 8 64 bit?

[jamespetts]

There is a single-threaded 64-bit Windows version available for the first time with 11.10 (in the .zip file with the Windows binaries). There has been a 64-bit version available for Linux for a long time.

Further work is required to make the 64-bit version for Windows compatible with multi-threading.

[asaphxiix]

great! I've installed the redistributable, but still it doesn't work. Perhaps I should uninstall?

[jamespetts]

I have now fixed the performance error on the 11.x branch.

As to the 64-bit executable, what error do you get, and which version of the redistributable did you install?

[asaphxiix]

the one you linked to, 2012.3
unable to start, code 0xc000007b

[Sarlock]

I'm getting the same error with the 64 bit version, just downloaded and installed it 5 minutes ago.  32 bit is fine.  2012.3 distributable was used as well.

[jamespetts]

Might I ask both of you to try deleting the two .dll files  that come with the .zip file (msvcr110.dll and msvcp110.dll) after installing the redistributatble and see whether that works? If that does not work, I suggest that you try the steps recommended here to see whether they help.

[Sarlock]

Doesn't seem to make a difference, still getting the same error.  I installed the distributable, moved the 5 DLL files mentioned in the web link to the System32 folder and also to the Simutrans-Ex folder.  I removed them from the Simutrans-Ex folder and it immediately asked for them in order to run.

http://msoos.wordpress.com/2010/09/11/0xc000007b-error-solution/

It's a bit over my head but clearly it's something fairly simple.

[jamespetts]

Hmm - very odd. The trouble is, since it works for me, a dependency walker is unlikely to help...

[Sarlock]

Must be something that you have set up or installed on your end that we don't have on ours... trouble is figuring out what it is.

[Junna]

Yep, the 64 version does not work for me either (win7).

[jamespetts]

Junna - have you tried the steps recommended in the post to which I linked?

[ӔO]

64bit version works fine with me.
win7

32bit version feels faster, however.


maybe there are some dependencies on Visual studio C++ or .net framework?
my computer has those installed.

[jamespetts]

Hmm - the redistributable should satisfy those, so it's odd that it's not working for people.

As for feeling faster, I suspect that that's the multi-threading of the graphics that is currently not working in the x64 version.

[prissi]

64bit will be always slower, as it has larger data structures for many elements (like pointers) and thus requires more memory and hence will have more frequent cache misses. Simutrans is not that mathematical intensive that the additional register can make up for the bloating of the memory use. Also it increase some 16/32 byte structures, which is not very nice for cache alignment.

Furthermore, it does not use hand-optimized assembler, which only exist in 32 bit code (but likely the old MSVC compilation did not use it either).

[Sarlock]

Probably the only tangible benefit is the extra memory that becomes available.

[jamespetts]

In my somewhat approximate tests, I cannot spot a noticeable difference in performance between 32 and 64-bit Windows builds, although there might well be subtle differences.

However, there are still some performance issues present (equally in 64 and 32-bit versions) even after my performance issue fix causing intermittent slowdowns in fast forward mode, but only in release builds. The odd thing is that reverting each change between 11.9 and 11.10 manually and individually shows no difference in performance, so I cannot quite understand what is causing this.

[jamespetts]

For those still having trouble getting the 64-bit version to run, try the following:

(1) download and install the 64-bit redistributable (available here) if you have not already done so - make sure that it is the "VSU3\vcredist_x64.exe" file, or else it will be the 32-bit version (if you cannot remember precisely which one that you downloaded, download and install it again); and
(2) delete the following files from your ~/simutrans directory:
(a) msvcp110.dll;
(b) msvcp100.dll; and
(c) msvcr110.dll.

These are the 32-bit versions and might well clash.

If that does not work, then further download and install the redistributable package for the 64-bit version of Visual Studio 2010.

I should be grateful if people could let me know their results.

[Sarlock]

Did all of the above and no change (I had installed both earlier today, reinstalled just now to make sure).  Here is what the folder looks like:



32 bit version runs fine still.

[jamespetts]

Hmm. Very odd. Can you download the 64-bit version of Dependency Walker and run it on Simutrans-Experimental-x64 and post a screenshot of the results that you get?

[Sarlock]

Seems to immediately encounter a problem with a few missing DLL's.



I'll start querying each of the issues and see what I come up with, though this is fairly beyond my skill for the most part.  I'll specifically look in to the MSVCP/R 110 32/64 bit issue.  Figured it was fixed with the new install and removal of the old DLL's.  It's pulling them from windows/system32

[Sarlock]

I've finally got it working.  It's definitely an issue with MSVCP110/MSVCR110.  I put the new files into the Simutrans-Experimental folder and it worked fine.  But then, of course, the 32 bit version won't work unless I move the old ones back there.  They might each need their own folder so that they can each have the right DLL's.  Might be easiest to just supply two different sets of binaries.

EDIT:  It seems that somehow after installing and uninstalling several times it decided to put the right files in to windows/system32 for the 64 bit version.  When I copy the 32 bit version of the DLL's back in to the Simutrans-Experimental folder now both 32 and 64 bit versions work fine.  The 64 bit version pulls the DLLs from elsewhere while the 32 bit version pulls them from that folder.

[jamespetts]

Hmm - odd. What happened when you removed the .dlls from the Simutrans-Experimental folder entirely?

[Sarlock]

It seems that the MSV files in my windows/system32 folder are now the 64 bit versions.  I can leave the 32 bit MSV files in the Sim-Exp folder and the 64 bit version will pull from the windows/system32 folder and the 32 bit version will pull those.  Both versions are working fine now but I can't exactly explain what final step suddenly made everything work fine.

[jamespetts]

What did Dependency Walker show before as to where the 32-bit and 64-bit .dlls were?

[Sarlock]

The DLLs in windows/system32 were still the 32 bit versions and it was trying to load those and failing because they weren't the 64 bit versions.  After uninstalling and reinstalling a couple of times the files in windows/system32 were then the 64 bit versions and it seemed to work fine.  I can't explain what step actually produced the fix, I started doing lots of different little things.  At least we know it's directly related to those two files.

[Markohs]

Didn't know about depends.exe, I had allways wished a equivalent to unix "ldd", thanks for pointing me to that program.

And that dll dependency it's aproblem visual studio drags, I've had problems distributing binaries compiled with VS too, mingw it's better for that.

EDIT: Btw, depends.exe also shows me missing dll errors, but that program starts just fine on my system, same Dll's. I guess those must be optional dependencies for backwards compatibility, or a mess in our systems with installed redistributable packages. But it works.