Oops, I forgot to commit some small change I made. Now the repository is up to date. It should be relatively straightforward to build from there, just use latest Premake4 to generate yourself makefiles.

Do you need extra build instructions? I can explain it more, but in short, you need to do "premake4 gmake" or something like that in the support folder, and it will generate makefiles which should build the library straight away.

Thanks for the reply!

I've managed to build Turbostroi, but the mod seems to be missing a file:


Also, here are a few key things I had to do before the library compiled under Ubuntu 14.04:


1) Fetch the repo with command:
$ git clone --recursive https://github.com/PhoenixBlack/gm_turbostroi
2) The code requires premake 4.4 beta. Premake 4.3 from the OS repository will not work.
3) Compilation fails at source/gm_turbostroi.cpp:291, need to add explicit void* cast to threadSimulation:
SIMC_THREAD_ID thread = SIMC_Thread_Create((void *)threadSimulation,userdata);
4) In file support/premake4.lua:13 replace the path with the one you have on your system:
targetdir ("/home/$YOUR_USER_NAME/.local/share/Steam/SteamApps/common/GarrysMod/garrysmod/lua/bin")
5) In file support/premake4.lua:68 replace "lua51" with "luajit-5.1":
links { "simc", "luajit-5.1" } --"tier0",
You also need to install package libluajit-5.1-dev.
6) compile it with line:
$ premake4 gmake; cd gmake; make CFLAGS=-fPIC
7) Change the name of the built library from libgmsv_turbostroi_win32.so to gmsv_turbostroi_win32.dll

First of all, you're getting that lua error because the file is supposed to be called something like gmsv_turbostroi_linux.dll or whatever.

1) Yes, you need Premake 4.4 beta, or Premake 4.5 which they were supposed to release ages ago.
2) Just clone the repository entirely, "git clone --recursive <url>" and it will fetch everything that's needed as a subrepository.
3) I will fix that in the source code, it's a minor difference between compilers
4) That is indeed something you have to change
5) You're supposed to be using LuaJIT, not Lua 5.1.0. Hence it requires "lua5.1".

Hi,

Publicado originalmente por Black Phoenix:

First of all, you're getting that lua error because the file is supposed to be called something like gmsv_turbostroi_linux.dll or whatever.

Hmm,
I may be wrong as I know nothing about modmaking, but isn't this the code that handles loading turbostroi? I don't see any mentions of gmsv_turbostroi_linux.dll:

I tried naming it gmsv_turbostroi_linux.dll and gmsv_turbostroi_linux.so as you suggested, but, surely enough, GMod cannot even find the library:

Also note that the error I gave in my previous message says it's missing turbostroi.lua, not the binary library itself (unless these two issues are somehow related).

1)...2)...3)...4)...5)...

These were just notes for myself or anyone else who would want to go the distance again, but thanks for commenting. Didn't know about --recursive. One remark though:

5) You're supposed to be using LuaJIT, not Lua 5.1.0. Hence it requires "lua5.1".

Then the linux version of the library would be called "luajit-5.1", not "lua51", at least in Ubuntu.

Okay, I guess I got it. The file should actually be called gmsv_turbostroi_linux.dll, but your code (see snippet above) only checks for the windows version and assumes that turbostroi does not exist if it doesn't find it.
If you remove or expand the check, the library actually loads, but there are no chassis on the cars which makes me think that there's something wrong with the library I built. Maybe I'll look more into it later.
May I ask if you've checked that the Linux version actually works or you're only assuming it will work since you didn't use platform-dependent code?

"May I ask if you've checked that the Linux version actually works or you're only assuming it will work since you didn't use platform-dependent code?" I'm afraid it's only the latter. I tested the threading stuff under linux, but not tested the actual turbostroi DLL from linux, hence there is no OS check.

Welp, I managed to compile and run it, so rest assured it actually works. The problem was that premake4 built a 64-bit binary while GMod is a 32-bit application requiring 32-bit modules. Since premake ignored the --platform=x32 option, I had to add these ugly lines to premake4.lua to force it to compile in 32 bit (surely there's got to be a cleaner way, but I don't know premake):

The sad thing is that the simulation feels more jittery than without turbostroi. The average framerate probably got a bit better, but it hick-ups to 0 every second or so, so the movement becomes even jerkier than before.

Both of my cpu cores are loaded, so I would assume my laptop is just not powerful enough to handle all the shining glory of soviet underground trains.

Out of curiosity, what is the current performance bottleneck in this mod/simulation? Surely there must be areas for improvement.

It should not be jittery, nor it should load up the cores so much. How many trains are you spawning?

The main bottleneck is GMOD running Lua and not switching to JIT execution despite apparently running LuaJIT. All the formal indications show it must be running code as JIT, but execution times indicate it's still good old interpreter.

If you don't account for simulation itself (e.g. turbostroi is active and running), main bottleneck is sharing all the data about the train with client and just... being an entity. Plus pneumatics calculations to a lesser extent. AI trains do nothing of this, and you can have only up to about 100 of them.

Secondary but more noticeable bottleneck is GC, when there is a larger amount of trains, things tend to lock up from time to time because GMOD is doing GC, usually not related to trains themselves, but to wiremod and such. I tried to eliminate all points where tables are created in the train code serverside, and I'll re-attempt this again soon to make sure, but I can't fix other mods.

Third, there is havok physics which just gives up at a certain trains count and becomes too slow and laggy.

Thanks for the expanded explanation.

Publicado originalmente por Black Phoenix:

It should not be jittery, nor it should load up the cores so much. How many trains are you spawning?

It's a bit jittery even if I simply load the map without spawning anything. If I place a stub or a corrupted library in place of turbostroi, the mod starts spitting errors into console (as expected), but the map does not lag (I'd say the FPS increases two or threefold, from 20-30 to 60, this jittering disappears, though some surfaces and track elements become glitchy or invisible). I thought that simulation of the rail system alone without any subway cars is supposed to take quite a lot of resources.

Hmm, perhaps my integrated HD4000 videocard is to blame more than anything.

Publicado originalmente por Black Phoenix:

The main bottleneck is GMOD running Lua and not switching to JIT execution despite apparently running LuaJIT. All the formal indications show it must be running code as JIT, but execution times indicate it's still good old interpreter.

I see, so Turbostroi should partially fix that in regards to your mod when compiled against luajit

I tried to compile linux version of Turbostroi and use it on my server , and it is more laggy/choppy than not using it.

Hello! Can somebody post link to compiled binary? I tried to compile it, but too few know about it, and nothing has turned. I would be very grateful.

so is there turbostroi for linux compiled and working? i don't have linux on my pc. and that's why i need a working one, beacose the host is linux based

I found my old workspace and rebuilt Turbostroi with a higher optimization level (O3 vs O0), but haven't tested it: <removed>
The old (slower, but confirmed working) Linux library that I got a year ago is here: <removed>

Copy the library to ~/.local/share/Steam/SteamApps/common/GarrysMod/garrysmod/lua/bin (or whatever path you have on the system) and *hopefully* it should work.
Do not rename it, it is supposed to end with "win32.dll" despite being a shared Linux library.
Before using the library, make sure none of the dependencies such as libluajit are missing with the ldd command.

(It would still be most advisable to compile it yourself instead of putting trust into things that strangers give you on the Internet, though!)

P.S. Keep in mind that from what I gather from this thread no one has ever got any speedup by using Turbostroi on Linux, though it still seems unclear whether there is a problem with the builds, or people who tried running it just had performance bottlenecks elsewhere (such as an integrated GPU, like in my case).

Update: Rebuilt Turbostroi with higher optimization, updated the link.

I'm also successfully compiled (using undercut notes in this thread, with some corrections like i was need install 32 bit version luajit using "libluajit-5.1-dev:i386" on x64 ubuntu), and actually i can say it "works", but somewhy one train = 100% load at one core. So there is everything work ok until
number of trains exceed 5-6, then everything start to lag. Tested on 4 x 4 core Opteron 8389 @2.9 ghz. Without turbostroi lags happens even with 2 trains.

So with this test i can actually confirm that library working on linux, but there is some bug or so what causes 100% load to core for what created thread from turbostroi. Have no idea whats wrong. Or this is normal?

EDIT: after testing also on windows i reailized that actually linux version of library is working wrong and don't give proper performance boost, because on my local machine (phenom 1090t) i'm getting ~8 trains with turbostroi on windows with 6 cores (with running game itself).

Use this: https://github.com/kosmik641/gm_turbostroi/releases