Jump to content

Recommended Posts

31 minutes ago, Muzzleflash said:

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.

Thank you for good response in theme,

 

all true (except "Almost all" :) (not really close, but as you said it depends on what you writing)),

and yes integration of something, like: new 'more precise' number variable type and set of commands for it; would be great with this improvement,

but:

_ i am sure even in default Arma 3 there is parts of code which' performance could be seriously,noticeable improved by usage of this addition,

_ and you did not counted abilities which would be granted by the addition

(things which now just can't be written and work without braking the game' process (like: noticeable much more complex analyzation part of AI' behavior control))

 

Using of extensions was 1st idea which came to mind about realisation of the multithreaded execution in arma,

but the option: can be integrated in the game (what leads to mutch better working performance) and do not require knowledge of additional programming language.

Share this post


Link to post
Share on other sites

We might have different definitions of "almost all", but if I look at this list https://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3 there aren't many commands with can run simultaneous without expensive synchronization. You can't use addMagazine because some other script might be reading that. You can't run X setPos Y because someone might be running getPos, or getPosATL, or even "Z distance X", and so on - also you can't run getPos either for the same reason.

Share this post


Link to post
Share on other sites
23 minutes ago, Muzzleflash said:

We might have different definitions of "almost all", but if I look at this list https://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3 there aren't many commands with can run simultaneous without expensive synchronization. You can't use addMagazine because some other script might be reading that. You can't run X setPos Y because someone might be running getPos, or getPosATL, or even "Z distance X", and so on - also you can't run getPos either for the same reason.

https://img-fotki.yandex.ru/get/467152/111360945.1/0_19b2b2_e8ee7b8f_orig

(did fast so can be mistakes) (marked what can't)

(counting what here captured half of "add|_|", all "remove|_|" and only ~30% of "get|_|") in total is ~ half :)

 

(only when commands changing only shared memory they can't run simultaneously)

(point of multithreaded execution is running analysation,data changing processes)

Share this post


Link to post
Share on other sites

That's not even a fraction. You can't use any command with the word 'find' in it because other scripts might be moving the objects at the time. You can't use fog, because another script might be manipulating or reading fog at the same time. You can't use forEach because another script might be modifying the array. Same with formation, or any get* command which may be modified directly by a set* command, or indirectly. Same with resize, road-commands, etc.. So that covers pretty much all commands on that screenshot except pure math ones, like round, + or acos.

Share this post


Link to post
Share on other sites
5 minutes ago, Muzzleflash said:

That's not even a fraction. You can't use any command with the word 'find' in it because other scripts might be moving the objects at the time. You can't use fog, because another script might be manipulating or reading fog at the same time. You can't use forEach because another script might be modifying the array. Same with formation, or any get* command which may be modified directly by a set* command, or indirectly. Same with resize, road-commands, etc.. So that covers pretty much all commands on that screenshot except pure math ones, like round, + or acos.

Its question of realisation, if will not be used way to prevent "reading" of memory ceil while other process "writing" on it (which are exist (and according to what you said before: yes it can be too performance lowering, but main goal is execution of independent code and ability to access shared memory is just awesome enhancement for it))

then ~yes: all connections to shared information will be unavailable,

but only "shared", (arrays can be local (all actions with them you described can be used))

Share this post


Link to post
Share on other sites

Note there are two concurrency issues. One is ensuring multiple scripts work together correctly. That is that they don't intrude on each other. This is currently very simple by running scripts in the unscheduled environment where you can avoid undesired interaction. This is something you will need to extend sqf with features so scripts do not conflict. The second issue, is preventing multiple simultaneous running scripts from crashing Arma. Say you have a two scripts. Script A controls a squad, giving waypoints and such. Script B removes stuff far away from human players. If they can run at the same time, script B might be trying to use some command on a squad member or the group, but then script B deletes the unit at the same time crashing Arma. This can easily be solved by locking the entire game world so only one script may modify it at a time, but then no other script can run anyway making it all pointless. Or you can make more fine grained locking, like locking the squad member so only one script is running any commands related to the unit at the time, but that will be very hard to implement correctly.

Share this post


Link to post
Share on other sites
19 minutes ago, Muzzleflash said:

One is ensuring multiple scripts work together correctly. That is that they don't intrude on each other. This is currently very simple by running scripts in the unscheduled environment where you can avoid undesired interaction. This is something you will need to extend sqf with features so scripts do not conflict.

Already described all additions, just wait for rewrited suggestion version (actually in obsolete one it described too)

19 minutes ago, Muzzleflash said:

The second issue, is preventing multiple simultaneous running scripts from crashing Arma. Say you have a two scripts. Script A controls a squad, giving waypoints and such. Script B removes stuff far away from human players. If they can run at the same time, script B might be trying to use some command on a squad member or the group, but then script B deletes the unit at the same time crashing Arma.

Sorry, but you like do not reading my posts ) :

 

19 minutes ago, Muzzleflash said:

This can easily be solved by locking the entire game world so only one script may modify it at a time, but then no other script can run anyway making it all pointless.

Its how its going to be, but:

20 minutes ago, Ilias48rus said:

ways to prevent "reading" of memory ceil while other process "writing" on it are exist,

but according to what you said before:

_ yes: it can be too performance lowering,

_ but _only if_ best available way still will lower overall performance more then improve:

__ then yes- it will not be used, so:

___ all connections to shared information will be unavailable (only "shared", (arrays can be local (all actions with them you described can be used)

___ but main goal is execution of independent code

___ and ability to access shared memory is just awesome enhancement for it

(yes, i edited it for easier reading)

;

 

19 minutes ago, Muzzleflash said:

Or you can make more fine grained locking, like locking the squad member so only one script is running any commands related to the unit at the time, but that will be very hard to implement correctly.

Yes, but thats something will leave for dev. team while only they getting paid for it :)

Share this post


Link to post
Share on other sites
19 minutes ago, Muzzleflash said:

Note there are two concurrency issues. One is ensuring multiple scripts work together correctly. That is that they don't intrude on each other. This is currently very simple by running scripts in the unscheduled environment where you can avoid undesired interaction. This is something you will need to extend sqf with features so scripts do not conflict. The second issue, is preventing multiple simultaneous running scripts from crashing Arma. Say you have a two scripts. Script A controls a squad, giving waypoints and such. Script B removes stuff far away from human players. If they can run at the same time, script B might be trying to use some command on a squad member or the group, but then script B deletes the unit at the same time crashing Arma. This can easily be solved by locking the entire game world so only one script may modify it at a time, but then no other script can run anyway making it all pointless. Or you can make more fine grained locking, like locking the squad member so only one script is running any commands related to the unit at the time, but that will be very hard to implement correctly.

While BI may be able to prevent hard crashes i doubt they will solve all potential multithreading issues in such a way that scripters cannot fuck it up. If we ever want to get some form of multithreading we will have to accept that it is going to be just as difficult as in any other situation.

Share this post


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

While BI may be able to prevent hard crashes i doubt they will solve all potential multithreading issues in such a way that scripters cannot fuck it up. If we ever want to get some form of multithreading we will have to accept that it is going to be just as difficult as in any other situation.

i do not feel it very difficult writing it' possible realisation concept,

regardless to:

_ what truly i would say if user crashing something by own script its his action,

do not see real ways to crash anything in the concept

 

(obviously i always welcome mistake,inconsistency finding in my works|states)

Share this post


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

Already described all additions, just wait for rewrited suggestion version (actually in obsolete one it described too)

Which addition specifically? But making scripts work together is something that needs scripter's input somehow to ensure that scripts work. I can make scripts that work together right now. But - without any changes - will break if Arma becomes able to run multiple scripts run at the same time.

 

22 minutes ago, Ilias48rus said:

Sorry, but you like do not reading my posts ) :

Can you clarify what you mean here? I read the first main post, skimmed the entire thread until and has read every response since my first post in this thread.

 

22 minutes ago, NeMeSiS said:

While BI may be able to prevent hard crashes i doubt they will solve all potential multithreading issues in such a way that scripters cannot fuck it up. If we ever want to get some form of multithreading we will have to accept that it is going to be just as difficult as in any other situation.

I agree. People are still able to make the game crash with certain sequences even now. To be honest I think the only it could ever work is with a share-nothing approach (which is used in web browsers). In that approach, you gather some data, and it is copied to another thread. That thread has no access to the game world at all anymore. It has all the data sent to it, but cannot run any commands on the world, like getPos or addWeapon. When that thread/script is done computing on the data it was sent, and has computed a result, the result is copied back to the original thread. This way you avoid a community with a majority not having a advanced computer science of software engineering knowledge from screwing up. But again, I still believe all the cases were you really want to take some data, run an independent long-running computation, and then use the results - as in the approach just mentioned - are better served by an extension.

Share this post


Link to post
Share on other sites

I don't disagree that it will be useful to find approaches to get better FPS. I just don't believe that the scripting engine is the right place to do it, or that it in fact takes very many FPS directly. I can run a lot of scripts (even poorly written once) and experience almost no drop in FPS. But dropping 30 AI into a mission takes a much larger hit. Especially the AI might use an upgrade instead, still being mostly hardcoded to old-school FSM. But at least we can shoot a guy raising a binoculars, without him completing the raising of the binoculars first, and then the lowering, before finally performing his death animation - it only did take until Arma 3 for that.

Share this post


Link to post
Share on other sites
23 minutes ago, Muzzleflash said:

I don't disagree that it will be useful to find approaches to get better FPS. I just don't believe that the scripting engine is the right place to do it, or that it in fact takes very many FPS directly.

 

Well, currently it cant eat that much FPS in the most used situation, scripts just run more slowly instead. :p 

Share this post


Link to post
Share on other sites
43 minutes ago, Muzzleflash said:

Which addition specifically? But making scripts work together is something that needs scripter's input somehow to ensure that scripts work. I can make scripts that work together right now. But - without any changes - will break if Arma becomes able to run multiple scripts run at the same time.

(i meant "aditions" to the program' structure)

Behaviour of execution of scripts without insertion of new commands in them,

_ or implementation of automated system (in that case it will not be important cause the system' work will be visible mostly only in performance enhancement)

will not change;

43 minutes ago, Muzzleflash said:

Can you clarify what you mean here? I read the first main post, skimmed the entire thread until and has read every response since my first post in this thread.

i meant what i inserted between | : | and | ; | symbols in same post where you quoted it from

 

43 minutes ago, Muzzleflash said:

I agree. People a..

(couldn't attentively read fully, saved for close future :) )

 

..

 

12 minutes ago, NeMeSiS said:

Well, currently it cant eat that much FPS in the most used situation, scripts just run more slowly instead. :p 

,+ ,it can verry seriously, but only with certain custom scripted things, that script' speed is the problem

Share this post


Link to post
Share on other sites

Any theory should be tested in practice. Continue theoretical discussions - will not give a discussion of the result.

 Here is an example of how the game looks on the server in 3-4 hours of play. FPS has not changed for me during this time, but there are large backlogs in AI. In a collision between players, this problem does not appear. This is the work of scripts or something else?

On the video it is visible how the bullet stops AI, almost at once. But AI falls to the ground not at once. On video it is noticeable that movement of AI happens to lag. On video there is no movement of cars with AI, cars move with big lag. The car can stop and in 2-3 seconds to move to a big distance.

 

  • Like 2

Share this post


Link to post
Share on other sites

That video shows either a poor connection between the client and server, and/or a server that is way too busy. If the server is too busy, unless very poor usage of scripts, scripts are not directly responsible. They may be indirectly, for example by spawning lot's of stuff.

 

From my own anecdotal experience with hundreds of games, I believe that the largest changes in FPS occurs, when a machine, typically the server, goes to suddenly having, or not having, many AI's under its control in active combat.

Share this post


Link to post
Share on other sites
4 minutes ago, Muzzleflash said:

That video shows either a poor connection between the client and server, and/or a server that is way too busy. If the server is too busy, unless very poor usage of scripts, scripts are not directly responsible. They may be indirectly, for example by spawning lot's of stuff.

 

From my own anecdotal experience with hundreds of games, I believe that the largest changes in FPS occurs, when a machine, typically the server, goes to suddenly having, or not having, many AI's under its control in active combat.

With communication all is good. I will repeat, the bullet always stops AI, in that place where has got. In firefight with players, there is no such problem. This problem is absent within 3-4 hours, before her emergence.
Maybe what is offered by the author makes sense, and needs check, but not theoretical fights?

Share this post


Link to post
Share on other sites
9 hours ago, lex__1 said:

 

 

Yes, showed on the video can be problems caused by not enough fast commands procession,

Thanks for it,

and yes the theme' suggested improvement on one side directed to improve the overall commands procession speed;

 

 

I always welcome practical checking of anything

and have some practical parts of the concept development process (which been bit slowed down, cause to my usual snowball principle of development (as further i go so deeper want to get in))

(for now updated first topic and name, hope its better)

Share this post


Link to post
Share on other sites

- Often the missions use the acceleration of the time of day, for immersion, change of day and night. In the mission, which I often play, in the settings of daylight hours lasts 3 hours in the game, the dark time of the day lasts 1 hour in the game. Approximately, after the first day, after four hours with AI problems begin. *
- Repeatedly seen on the forum and on feedback.bistudio.com messages from players about spam commands in report logs.
I do not know how to check this and what happens on the server, when the server obviously skips something and does not produce it in scenes with AI.
Video from yesterday's game. 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.

 

  • Like 1

Share this post


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

- Often the missions use the acceleration of the time of day, for immersion, change of day and night. In the mission, which I often play, in the settings of daylight hours lasts 3 hours in the game, the dark time of the day lasts 1 hour in the game. Approximately, after the first day, after four hours with AI problems begin. *
- Repeatedly seen on the forum and on feedback.bistudio.com messages from players about spam commands in report logs.
I do not know how to check this and what happens on the server, when the server obviously skips something and does not produce it in scenes with AI.
Video from yesterday's game. 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.

 

Great video, thank you for it

through i'm not sure which of the problems really related to commands execution speed as always accepting confirmations|contestations

Inserted in first post;

 

(work on "multithreaded commands execution realization concepts suggestion" continuing)

Share this post


Link to post
Share on other sites

Want to say sorry for previous "unrefined" suggestion posts due to it difficulty for understanding,reading

I removed from rewrited version most of technical parts, hope its easy to read,understand enough and created new feedback ticket,

You can find the suggestion and link to ticket in first post,

 

Encouraging you to support the improvement request and thanks for interest;

Share this post


Link to post
Share on other sites

No any responses at all ?:dontgetit:?

 

(if you readed the "suggestion" before v0.3 suggesting you to review it, sorry for the editing within 3hours after posting)

Share this post


Link to post
Share on other sites

What about:

 

 

Also your writing and Ideas are very hard to read. The Intercept team invested quite some time in what can be multithreaded and what can't.
Read operations can theoretically (Actually can't because of Memory allocator constraints) be Multithreaded, BUT! only if there is no write operation going on anywhere and setting a global variable is a write operation.

This would however require a complete rewrite of the Scripting backend and also needs a ton of synchronization to be added which will make the whole system slower.

I don't see any reason to do that as the Enfusion engine already rewrote the Scripting backend. And BI will most likely use that Engine for next Arma game.

 

What I'm seeing here is a proposal for the next RV engine with multithreaded scripting. There will with a high likelyhood be no next RV engine. Because the RV engine is sooo old that polishing it would be way more work than just writing a new engine.

Share this post


Link to post
Share on other sites
2 minutes ago, dedmen said:

 

RV4, not next, improvement of current one, 

2 minutes ago, dedmen said:

Read operations can theoretically (Actually can't because of Memory allocator constraints) be Multithreaded, BUT! only if there is no write operation going on anywhere and setting a global variable is a write operation.

This would however require a complete rewrite of the Scripting backend and also needs a ton of synchronization to be added which will make the whole system slower.

You could at least try to read the concepts

Share this post


Link to post
Share on other sites

There will be no new Engine iteration in Arma 3.

I did read it.

I do know Arma quite well. And I've experimented with multithreaded scripting myself. I know exactly what's needed for that. And that's also why I know that this will never happen in Arma 3.

 

All your use cases:
 

Quote
0. AI’ long analyzation algorithms for behavior control;
1. High detailed analyzation (as example: for complex |precise aircraft behavior);
2. Analyzation parts of dynamic caching systems;
3. Long data extraction and editing algorithms;

Are already possible to be done multithreaded using Intercept or just making your own Extension. and 0, 2, 3 are already done in some projects utilizing Intercept. And 1 may follow in form of ACE Advanced ballistics when Intercept has prooven itself.

 

Also scripts are less than 1/8th of Arma's Frametime in Vanilla. And at most 1/4th with the Mods I am running.

 

Your "Concept" paper is a mess of barely readable/understandable words and diagrams with incomprehensible stuff all over the place.

Share this post


Link to post
Share on other sites
12 minutes ago, dedmen said:

There will be no new Engine iteration in Arma 3.

I did read it.

I do know Arma quite well. And I've experimented with multithreaded scripting myself. I know exactly what's needed for that. And that's also why I know that this will never happen in Arma 3.

 

All your use cases:
 

Are already possible to be done multithreaded using Intercept or just making your own Extension. and 0, 2, 3 are already done in some projects utilizing Intercept. And 1 may follow in form of ACE Advanced ballistics when Intercept has prooven itself.

 

Also scripts are less than 1/8th of Arma's Frametime in Vanilla. And at most 1/4th with the Mods I am running.

 

Your "Concept" paper is a mess of barely readable/understandable words and diagrams with incomprehensible stuff all over the place.

I added the Intercept as woraround in the first post, i would highly appreciate your review with comments of the "suggestion paper";

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

×