Jump to content

Recommended Posts

Maybe there is some way to get arma's practical CPU use limit increased, if is: anyone know it ?


(point of theme is: execute anything with it mainly leading to increase of CPU load instead of slowing:

_ the rendering (client) (FPS),

_ or commands execution speed (server),

_ or the arma's scheduler  

)

Alot of thanks to lex__1 for great issue showing videos

On 21.08.2017 at 7:50 AM, lex__1 said:

Any theory should be tested in practice..

 

(not sure if the problems appeared because of

_ programming junk accumulation (during work on server accumulating: not needeable processes, junk in memory..)

or _ slow execution (amount of instances of systems running on server increasing with amount of content on the map)

On 22.08.2017 at 8:25 PM, lex__1 said:

There are six players on the server, the game has already been going on for more than five hours (the second game day *). I just went into the game, on the server, trying to capture the second city.

 

 

Multithreading:


Anyone know way to create asynchronous task ? (execute anything out of main "executing instance")


Explanation:

Spoiler

 

On 19.08.2017 at 11:45 PM, ezcoo said:

CPU usage alone doesn't tell about the performance:

you can create a meaningless loop that makes the CPU usage to reach 100 %,

while naturally bringing no benefit in terms of performance.

 

No you can't: it is indication of problem (meaningful processes can't busy CPU because they stacked in 1 thread's queue),

you can see it by executing:"


for'_n'from 0 to 1000 do{addMissionEventHandler['EachFrame',{for'_n'from 0 to 10 do{_n=9999*9999/9999*9999/9999}}]}

(what makes 1000 tasks without actions needed to synchronise with other processes and usage of arma's scheduler,
result is: FPS going down, CPU load-no changes at all.)"

(original post: https://feedback.bistudio.com/T59083#1639538)

 

Description:

Spoiler

When you running script unscheduled arma will combine it with other scripts|processes in 1 thread for procession by CPU, and keep all commands executing in 1 queue

but if |script|part of script| do not have commands which would affect other game's processes (like: changing global variable)

it could be executed even in own "CPU' thread",

 

Suggestion for Arma 3 (i'm starting versioning from 0, so it is ready :) ):

Ticket: https://feedback.bistudio.com/T126559

Suggestion: https://yadi.sk/i/WP3VM07b3MS886 v0.4 (i welcome issues,inconsistency finding)

(can be viewed in most browsers without downloading (click on the showed file page))

(this addition is mainly directed on opening opportunities to create much more complex scripts of certain types for Arma 3,

and from other side increasing the overall performance of commands execution)

 

Workarounds:

While Arma 3 do not natively support multithreading it does support usage of .dll extensions, dedmen stated that the Intercept library have modules for usage of multithreading and their workability been proven in parts of ACE3, like advanced ballistic system.

 

 

Still hope for any ideas, workarounds

Will highly appreciate any responses, suggestions, tests, notes, thinks,.., especially from dev. team.
Thanks for attention.

 

Edited by Ilias48rus
*suggestion v0.4*
  • Like 2

Share this post


Link to post
Share on other sites

So this is a tough question, as I'm not sure exactly what you mean, but here it goes.

 

There are two ways to call a function. call and spawn. 

 

Let's say you have a simple function:

CM_simpleHint =
{
     hintSilent "A hint!";
};

 

There are two ways we could run this function. The first is call:

 

[] call CM_simpleHint;

 

In this manner, the script would run, however the game would essentially stop until it is done. I think this is what you mean. Because of this, certain things are a bit different. 1) You cannot suspend the script with sleep or waitUntil functions. If you could, the script could easily and indefinately freeze the game. Second, while loops are limited to 10,000 iterations for the same reason. A while loop halts the script until it is done, meaning that if a while loop is in a called function, it halts the game until it is done. That said, a called script is run much faster than its spawned cousin, and can also return a value. For example: _randoVar = [] call CM_funcAlwaysReturnsTrue would be the same as _randoVar = true, provided true is what the function returns. The function can return anything.

 

Next is spawn:

 

[] spawn CM_simpleHint

 

A spawned script will not stop the game, it will run along side any other script. You can suspend this script as well for as long as you would like, and while loops are not capped. The disadvantage is that it will be slower, and you cannot return a value from the script in the same way as you can with call. _randoVar = [] spawn CM_funcAlwaysReturnsTrue would NOT equal true, instead _randoVar would be the scripts handle, for usage with commands like scriptDone.

 

Additionally, you can run things via an FSM. FSM's are much the same as call, except they do not halt the game and run along side. They are their own topic in and of themselves, however, and are more suited for constantly looping tasks and AI stuff. I can help you with these as well if you think they would fit your need.

 

Finally, whether called or spawned, any script can slow down game performance if written ineffeciently or with errors.

Share this post


Link to post
Share on other sites

Well, that is how call works, fairly certain I'm not mistaken on that bit. I suppose I'm not certain exactly what you mean. Call is unscheduled, which essentially just means that it is a priority to the engine, so it will be run immediately as opposed to in line with the scheduler. It will, however, delay scheduled items until it is done, which I think is what you want to avoid... maybe?

Share this post


Link to post
Share on other sites
4 hours ago, rga_noris said:

..

|call| continuing script (where it executed) regardless scheduled or unscheduled it was, if script runned scheduled using call will continue it scheduled.

  • Like 1

Share this post


Link to post
Share on other sites

#680 (rus.)

Quote

vlad333000 said 19 Aug 2017 - 15:30:
can be difficult to realize: simultaneous access to same dataset from different threads, and synchronization of different threads

Now commands for running sent to a system in which they arranges in queues for the CPU threads ?,

additional system (to which commands of 'separate' scripts will be sent) or enlarge current system {for commands of 'separate' scripts being passed though other set of actions) for:
_ organization of additional threads:
__ in the option |1|: on basis of analysis of _requiring organization commands, CPU usage and the system 's variables_ forming appropriate amount of 'separate' threads for CPU
__ in option |2| on the basis of information about _it's arma's thread (code on execution) and the requested action (parameters set for 'formThread' command|block)_ forming the threads.
(return result:
_ |1| depending on whether the system capable to create CPU threads which does not require to delay rendering,
_ |2|
__ if delaying rendering: same way as it is now, just considering 'separate' code as 1 command
__ without delaying of rendering: same, just the result will need to go trough same|similar scheme which present now for result correlation with executed command(provided by scheduler))

.

Quote

vlad333000 said 19 Aug 2017 - 15:30:
where and for what to use?

all _sets of commands that does not require synchronization with other ones_ can run separately using different CPU threads instead of increasing length of 1 thread (what leads to longer execution)

 

note:

in unsheduled enviroement skripter do not know in what order commands will be executed, so the only change in program's external behavior is that when the scripts are run simultaneously using shared data (ex.: global variables,..).there is a very small chance that they will overwrite each other 's result (example:

//'result'=(first 'not local' command in the code)
//a=1;
CPU thread0: task{_a=a+1}result{a=_a}
CPU thread1: task{_a=a+1}result{a=_a}
//currently in next frame is guaranteed a==3 (guies);
//will be a small chance that |a| will ==2;

),
_ in |1| this is possible to solve by comparison of codes's 'results' (when they affecting same datasets(in example above: |a|) they can be executed only together(in 1 CPU thread));

_ but actually it is another advantage to |2| (no need to solve it) (if skripter decides whether to use this method of execution, he can take it into account)

  • Like 1

Share this post


Link to post
Share on other sites

Slightly off topic, but |1| is _there any reason why_ you're |writing| like this or is your keyboard (spitting out _random |keypresses?,

 

Cheers;

Share this post


Link to post
Share on other sites
5 minutes ago, Grumpy Old Man said:

Slightly off topic, but |1| is _there any reason why_ you're |writing| like this or is your keyboard (spitting out _random |keypresses?,

 

Cheers;

Writing using the marks for you,for would be easier to read (to correctly understand parts of sentences)

  • Like 1

Share this post


Link to post
Share on other sites
21 hours ago, rga_noris said:

Well, that is how call works, fairly certain I'm not mistaken on that bit. I suppose I'm not certain exactly what you mean. Call is unscheduled, which essentially just means that it is a priority to the engine, so it will be run immediately as opposed to in line with the scheduler. It will, however, delay scheduled items until it is done, which I think is what you want to avoid... maybe?

 

I think he just wants to run scheduled execution in its own CPU threads so that scripts would use more processing power instead of slowing down the main thread of the game. The issue is that the RV engine doesn't support it.

  • Like 1

Share this post


Link to post
Share on other sites
34 minutes ago, ezcoo said:

I think he just wants to run scheduled execution in its own CPU threads so that scripts would use more processing power instead of slowing down the main thread of the game. The issue is that the RV engine doesn't support it.

Yes, kind of (not "scheduled", 'scheduler' in arma is system which merging tasks in 1 commands queue and executing |1 command per frame|(not certainly sure)),

and its not something like requiring to rewrite half of engine, same as multicore threading support(which was added to game in ~2015y. as i remember) it requiring some implementations to CPU thread forming cycle and some to commands conversion cycles.

  • Like 1

Share this post


Link to post
Share on other sites

Also want to bit enlarge the theme by adding question:

Maybe there is some way to get arma use more CPU, anyone know it ?

  • Like 1

Share this post


Link to post
Share on other sites
3 minutes ago, Ilias48rus said:

Also want to bit enlarge the theme by adding question:

Maybe there is some way to get arma use more CPU, anyone know it ?

 

If it was easy, it would have been done already. Also CPU usage alone doesn't tell about the performance: you can create a meaningless loop that uses all available free CPU power and makes the CPU usage to reach 100 %, while naturally bringing no benefit in terms of performance.

 

RV engine is ancient and it behaves accordingly. I guess we need to just wait for the Enfusion engine and hope that it has built-in support for solvable multithreading issues like this.

Share this post


Link to post
Share on other sites
40 minutes ago, ezcoo said:

If it was easy, it would have been done already. Also CPU usage alone doesn't tell about the performance: you can create a meaningless loop that uses all available free CPU power and makes the CPU usage to reach 100 %, while naturally bringing no benefit in terms of performance.

Thats the point: you can't, it is indication of problem (normal processes(important loops..) can busy CPU because they stacked in 1|few threads's queries), you can see it by executing:"

for'_n'from 0 to 1000 do{addMissionEventHandler['EachFrame',{for'_n'from 0 to 10 do{9999*9999/9999*9999/9999}}]}

(what makes 1000 tasks without: actions needed to synchronise with other processes and usage of arma's scheduler;,
result is: FPS going down, CPU load-no changes at all.)"

(https://feedback.bistudio.com/T59083#1639538)

,

i didn't said its "easy", and there is plenty other things what should be done (guies all can't be implemented at once),

and guies  the problem,possible solutions  wasn't noted because currently arma handling ~enough for proposed gameplaying and players do not paying attention on it's potential to handle more,work better, which hided by things like this one

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Ilias48rus said:

Thats the point: you can't, it is indication of problem (normal processes(important loops..) can busy CPU because they stacked in 1|few threads's queries), you can see it by executing:"


for'_n'from 0 to 1000 do{addMissionEventHandler['EachFrame',{for'_n'from 0 to 10 do{9999*9999/9999*9999/9999}}]}

(what makes 1000 tasks without: actions needed to synchronise with other processes and usage of arma's scheduler;,
result is: FPS going down, CPU load-no changes at all.)"

(https://feedback.bistudio.com/T59083#1639538)

,

i didn't said its "easy", and there is plenty other things what should be done (guies all can't be implemented at once),

and guies  the problem,possible solutions  wasn't noted because currently arma handling ~enough for proposed gameplaying and players do not paying attention on it's potential to handle more,work better, which hided by things like this one

 

Totally noob with CPUs things but, on my mind, an "on each framed" code like yours could have some implication on GPU instead of CPU.

So the question is: is your code worthy as CPU test? (not sure to have the right words in English; I hope you catch the idea).

 

I have an I7 7700K , probably not so much cooled. The only apps which gives me some hard crashes for CPU overheating is ... Arma.

I know I'd buy a water-cooled vent for the CPU.

Share this post


Link to post
Share on other sites
Just now, pierremgi said:

 

"on each framed", as any other code are executed by CPU, it connected to Graphics or GPU only in terms of pausing game's simulation (so the rendering) until all "onEachFrame" instances finished.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, pierremgi said:

I have an I7 7700K , probably not so much cooled. The only apps which gives me some hard crashes for CPU overheating is ... Arma.

I know I'd buy a water-cooled vent for the CPU.

 

Did you OC it?

At what temperatures do these crashes occur?

Prime not giving you thermal issues?

Do you use the stock cooler or a custom one?

Sounds aweful having temperature caused crashes mid game, no other game doing this?

Running an air cooled (noctua dh14) 4770k @4.6ghz on 1.20V next to a gtx 1080 (which isn't the coolest card in terms of temperature) with a medium case, so it's pretty stuffed in there with all cables, DSP cards etc.

In arma 3 all on ultra, 200%SS, no AA and I never come anywhere close to critical temperatures.

 

12 hours ago, Ilias48rus said:

Writing using the marks for you,for would be easier to read (to correctly understand parts of sentences)

Well it doesn't help, heh.

 

On top of the usual code performance tweaks (which can be speed increases of more than 30% in most cases) there's not much you can do to improve arma 3s CPU usage apart from using the appropriate command line parameters upon launch.

As said by @ezcoo BI would have done this already, if it was easy or worthwile to integrate.

The 64bit executable is a good example, I know of no other game dev that adds a 64bit executable for a 4 year old game long past its prime.

Increased memory usage but caused issues across the board for some people (if you believe random forum posts).

 

Cheers

Share this post


Link to post
Share on other sites
14 hours ago, das attorney said:

This is gold !!  Go for it !

Thank you

9 hours ago, Grumpy Old Man said:

Well it doesn't help, heh.

) , without it anyway worse

9 hours ago, Grumpy Old Man said:

On top of the usual code performance tweaks (which can be speed increases of more than 30% in most cases) there's not much you can do to improve arma 3s CPU usage apart from using the appropriate command line parameters upon launch.

all i writing always using as low resources as technically possible, can't write some things because the program will not handle it, thanks for answer

9 hours ago, Grumpy Old Man said:

As said by @ezcoo BI would have done this already, if it was easy or worthwile to integrate.

The 64bit executable is a good example, I know of no other game dev that adds a 64bit executable for a 4 year old game long past its prime.

Increased memory usage but caused issues across the board for some people (if you believe random forum posts).

While i can't say why it not worthwhile to integrate and noone else vindicated why..

As i said the room for implementation can be not obviously visible, with not low influence of:

Quote

guies  the problem,possible solutions  wasn't noted because currently arma handling ~enough for proposed gameplaying and players do not paying attention on it's potential to handle more,work better, which hided by things like this one

 

(rewriting the suggestion)

Share this post


Link to post
Share on other sites

CBA may have some functions you want that can help you to write some type of async system: Link

Though i am not sure what your end goal is. As far as i know you either run it unscheduled (in which case the simulation halts entirely until your function is done) or run it scheduled and run into the max 3ms per frame issue.
There are no real threads for scripting in ArmA3, it seems like all our scripting commands end up in the main loop somewhere (no matter how you call them) and you will never max out more than 1 core with scripting alone.

If you have some reaaaally CPU intensive calculations you could theoretically do those outside of the game and return the results, but only if you can first gather all the data you need from the game.

 

Note: I may be wrong, it has been a while :) 

 

Share this post


Link to post
Share on other sites
10 minutes ago, NeMeSiS said:

There are no real threads for scripting in ArmA3, it seems like all our scripting commands end up in the main loop somewhere (no matter how you call them) and you will never max out more than 1 core with scripting alone. 

as i already said, and

the suggestion is to fix this,

the goal is to show the issue and for now get around it (already know some (not good enough, but still) ways (will post bit later))

 

(still writing, now working with possible solutions for same time "wrire" from 1 and "read" from another thread requests to same memory ceil, overal ~50% done)

Share this post


Link to post
Share on other sites

Please ignore this post :) 

Edited by NeMeSiS
I cant read

Share this post


Link to post
Share on other sites
3 minutes ago, NeMeSiS said:

Im pretty sure the devs can come up with their own solution for this but never thought it was worth dedicating more resources to this. :p 

Trying to lower amount of needeable for it resources, thats the point :) 

Share this post


Link to post
Share on other sites
41 minutes ago, NeMeSiS said:

 

Im pretty sure the devs can come up with their own solution for this but never thought it was worth dedicating more resources to this. :p 

At one time, they also wrote about the impossibility to change the treatment of Arma3 to RAM. Then they released Arma3_64bit when it became very critical.

I still have to turn off Intel Virtualization Technology. No one can explain why Intel Virtualization Technology reduces FPS stability in Arma3. 

 

Share this post


Link to post
Share on other sites

Almost all scripting commands interact with shared state: the game world. So very few commands can run at the same time without causing race conditions. And some scripts wait for each other so they wouldn't gain anything. So for most script the blocking overhead need to ensure correctness may even worsen performance. Granted, for a very small range of scripting, doing only pure somewhat intensive calculations, you might benefit from having another thread do work. But doing pure calculations in SQF is not really good use of CPU either. So if your script fits that use case your are probably better off with an extension.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×