[Request] Feedback on multithreaded simulation

[zerver]

It does scale to > 4 cores, but only ~50% of the sim has been threaded, so forget about linear scaling. It can be > 100% faster under some circumstances though.

There is only one pathing thread at the moment, but this may change.

[Forboding Angel]

Hopefully this log will be more informative. There weren't any super serious lua breaks. Minimap notify widget and shootnow (custom widget for my commander's emp weapon).

infolog.txt

(40.08 KiB) Downloaded 18 times

[zerver]

I could not find the "minimap notify" widget in Evo 4.7, but for the other widget:

http://springrts.com/mantis/view.php?id=3315

The bug is not MTsim-related, but thanks for testing/reporting it anyway.

[Forboding Angel]

Tbh the way that is handled needs to be redone completely, but I don't know of anything that automatically causes an explosion upon a keypress in spring.

[Google_Frog]

Crash at about the same place.

Your crashes are deep inside Lua. Do develop builds crash in the same way?
http://springrts.com/dl/buildbot/defaul ... ortable.7z

Still crashes with Spring 91.0.1-397-g4d4d23c MTsim.

Crash seems to be unrelated to MTsim. It occurs in dev as well.

[Google_Frog]

I was able to run MTsim with a workaround for the crash bug in dev.

Saktoth reported unusable CPU usage. Did not say anything else useful.

[Deadnight Warrior]

Some crash reports, this time I used http://springrts.com/dl/buildbot/defaul ... ortable.7z

http://pastebin.com/iLRHjLmG
http://pastebin.com/4k3Qi2FU

[zerver]

Some crash reports

Better?
http://springrts.com/dl/buildbot/defaul ... ortable.7z

[Anarchid]

How can i triez this with lin^x?

[zerver]

You checkout the MTsim branch and compile...

[smoth]

Zerver which build is the current stable build?

[zerver]

Should be this one, although I have not tried it.

http://springrts.com/dl/buildbot/defaul ... ortable.7z

[smoth]

thanks, dl'd

[smoth]

So far so good, it seems to have fixed the wierd ass rendering bug in the last released mt spring.

i don't see really all that much improvment in fps though. at around 200 units I still am dropped to like 100fps.

hmm according to the infolog...

[f=0000000] [Threading] Multithreading is disabled because the game or system appears incompatible
[f=0000000] [Threading] MultiThreadCount > 1 in the settings will forcefully enable multithreading

huh? what does that mean? what is incompatible?

[Deadnight Warrior]

[f=0000000] [Threading] Multithreading is disabled because the game or system appears incompatible
[f=0000000] [Threading] MultiThreadCount > 1 in the settings will forcefully enable multithreading

huh? what does that mean? what is incompatible?

In your /gamedata/modrules.lua there's a "system" subtable. If you don't have it, make one, it should contain luaThreadingModel=n, where 2<n<7 in order to have multithreaded LUA. Example here.
Some info about LUA threading models.

[zerver]

I don't see really all that much improvment in fps though. at around 200 units I still am dropped to like 100fps.

This thread is about multithreaded simulation, and that has a very minor impact on the FPS. Instead you will be able to play a bigger game with more units. So what you should compare is the CPU load of MTsim vs a normal spring version from the develop branch. Please note that these two are incompatible sync wise, which makes it tricky to use a demo for benchmarking.

[Beherith]

I was wondering if there is a pseudo 'save game' mechanic that could be used to generate test cases from replays. Like if I could run a replay, fast forward to 30 minutes, hit save, and it would save units and their orders.

[gajop]

I was wondering if there is a pseudo 'save game' mechanic that could be used to generate test cases from replays. Like if I could run a replay, fast forward to 30 minutes, hit save, and it would save units and their orders.

sure, but what makes replays special?
same thing could be done in normal games as well, you just need a save-game system (also probably need features, projectiles and heightmap as well)

[zerver]

True. For testing purposes, any 'simple' demo (containing few commands such as /give 1000 xxx followed by some initial orders) is unlikely to desync enough to affect the CPU load to any significant degree.

[zwzsg]

I was wondering if there is a pseudo 'save game' mechanic that could be used to generate test cases from replays. Like if I could run a replay, fast forward to 30 minutes, hit save, and it would save units and their orders.

Yes?

Never tried it in MT though.


Oh wait, from replay you said. Then not as it is because I made it a synced gadget so it could see enemies units even if not speccing. Theorically the save code could be moved into a widget, but in practice the whole thing is prolly too complicated to cleanly split without harm.

Is it really that bad if the test case is staged instead of taken from a genuine multiplayer game?