Fight with runaway limit

Discussions about Coding and Scripting
Buggie
Godlike
Posts: 1766
Joined: Sat Mar 21, 2020 5:32 am

Fight with runaway limit

Post by Buggie » Wed Mar 30, 2022 3:30 pm

I found some observation which can be useful for other. All Observation done via diassembled token view for function via UE Explorer.

Predefinition:
Runaway counter increased only in two VM tokens: Jump and JumpIfNot.

All stated matter only for bottle necks which make main part of runaway limit. No sense apply this to any code.

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (A) {
			B = true;
			continue;
		}
		C = true;
	}

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (A) {
			B = true;
		} else {
			C = true;
		}
	}
1. Both notation produce exactly same byte-code.

2. Travel via block after if eat 4 points per iteration: for condition, if, continue/end block, jump at loop end.
Travel via block after else eat 3 points per iteration: for condition, if, jump loop.
So better, place things which come often in else block.

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (A) {
			B = true;
		}
	}

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (!A)
			continue;
		B = true;
	}
this code produce different VM code and first always eat 3 point per iteration.
But second eat 4 point per iteration if "continue" called.
Last edited by Buggie on Wed Mar 30, 2022 4:07 pm, edited 1 time in total.

User avatar
Feralidragon
Godlike
Posts: 5462
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Fight with runaway limit

Post by Feralidragon » Wed Mar 30, 2022 3:49 pm

It would be cool if one of the patches included an option to enable a log of this count at the end of every tick, in order to debug and know how far away you're from it, both in normal and extreme conditions, even to check first hand the effect of these things you're talking about.

Having that said, however, if you're near this limit at all, it generally means the code is doing too much and the game will be extremely slow either way.
I already discussed with Anth the possibility of increasing this limit, because of a few very legit possible cases, but he thought it's good as it is, so he might have already a good idea of what the average count might actually be in normal conditions.

But one thing that may be changed in the future is how these are counted towards the limit, because this kind of limit is meant for loops (for, while, etc) and not for if and continue , which seem mostly like an unintended consequence of how this limit is counted, so these might be treated differently in some way so that they don't increase this count, effectively raising the limit in the end.

User avatar
sektor2111
Godlike
Posts: 6031
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Fight with runaway limit

Post by sektor2111 » Wed Mar 30, 2022 3:59 pm

Right now it's entertaining to me that what this post is not recommending - but I wanted that, was turned into the same direction which I stated
viewtopic.php?f=5&t=14672&p=130095#p130095
I don't get the point for not making Editor to help you in any way...
"-norunaway" switch and "abovenormal" priority for Editor are now my default settings - and I'M FINE this way.
When this switch "-norunaway" was created - someone had REASONS for implementing it - and it's HELPFUL in Editor. No crash and no pain, just go to prepare a coffee until task it's ready, I'm not rushing anywhere... At C++ Level Editor does X billions of iterations and I don't see what's the stupid deal in UScript when is executed in Editor. Why having limits in Editor ? Why not doing some cute UScript assets because iterations are throwing rocks at you ?

Buggie
Godlike
Posts: 1766
Joined: Sat Mar 21, 2020 5:32 am

Re: Fight with runaway limit

Post by Buggie » Wed Mar 30, 2022 4:05 pm

In game 10 000 000 is huge number. And you can run client with "-norunaway" switch too.

This is mostly need for crappy solutions on UnrealEd side. But anyway 10 000 000 is slow enough for turn it off on default basis. Who need - able run with switch.

Also I make mistake. Each loop eat at least 2 point. One for condition, second for jump back. I go correct first now.

Another useful info: counter reset only on start each tick.

Automatically merged

About handle limiter inside code - I prefer Exec command for that. It will solve all problems and backward "compatible".

Automatically merged

https://github.com/OldUnreal/UnrealTour ... ues/774[hr][/hr]

Automatically merged

3. join two "if" together, reduce usage points, because partial equation of condition done via Skip token.

User avatar
sektor2111
Godlike
Posts: 6031
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Fight with runaway limit

Post by sektor2111 » Wed Mar 30, 2022 4:35 pm

Let's consider that my XC_PathsWorker builder tool is pretty much simple and allowing user to work as he wants just because additional tests during building ReachSpecs process might go into crazy iterations and results can be... trash depending on map's geometry.
The harder problem for me was not generating ReachSpecs but it was the solution for optimizing the process for creating them more simple as possible and without adding extra paths from A to C when route should be A B C, unless point B needs to be connected elsewhere. Examining some spots using Script and not eyes was my big problem which I couldn't solve. The rest was piece of cake.
But... because I don't have skills for writing a scripted "eye" for Editor, I leave things as they are because builder is useful for me in this state.
Last edited by sektor2111 on Wed Mar 30, 2022 4:40 pm, edited 2 times in total.

Buggie
Godlike
Posts: 1766
Joined: Sat Mar 21, 2020 5:32 am

Re: Fight with runaway limit

Post by Buggie » Wed Mar 30, 2022 4:38 pm

Code: Select all

	i = -1;
	while (++i < RUNAWAY_LIMIT) {
		C = true;
	}

Code: Select all

	i = 0;
	do {
		C = true;
	} until(++i >= RUNAWAY_LIMIT);
4. first loop eat 2 points per iteration: JumpIfNot + Jump.
Second loop eat only 1 (!) point per iteration. Just one JumpIfNot.
yes, it is not exactly same as second. You need "if" at start. but it is 1-2 additional point once, not +1 point for each iteration.

So now all critical loops must be rewrite to do..until. When do this - pay attention: when "until" condition is true, loop terminated. Opposite for "while".

User avatar
Barbie
Godlike
Posts: 2480
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Fight with runaway limit

Post by Barbie » Wed Mar 30, 2022 9:16 pm

Buggie wrote:
Wed Mar 30, 2022 4:38 pm
So now all critical loops must be rewrite to do..until.
I'd never change a head-controlled loop to a bottom-controlled and lose clearness of code because of language issues. It's the job of the compiler to create efficient machine or byte code of it.

*real programmers use safer hex*
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

Buggie
Godlike
Posts: 1766
Joined: Sat Mar 21, 2020 5:32 am

Re: Fight with runaway limit

Post by Buggie » Thu Mar 31, 2022 2:19 am

Yea, yea, yea. You can start from stop use SoftDrv. Because it is re-written on assembler, after figure C++ version is too slow for any real usage.
We live in real world, not in imaginary. So sometimes need do weird stuff if you need things be done.

Anyway, back to direct topic, if your code not suffer from runaway limits (I am sure not), this suggestion not useful for you. Write weird code not in critical for performance parts is definitely bad habit.

User avatar
sektor2111
Godlike
Posts: 6031
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Fight with runaway limit

Post by sektor2111 » Sat Apr 02, 2022 6:01 am

I'll experiment more of these "do - until" for figuring efficiency. At this moment I'm using it in XC_PathsWorker but... I don't know how much does it help.
Every single Navigation Point is taken and studied what is having in said defined connect range - using RadiusActors then sorting nodes based on distance. More nodes, more iterations - at a moment I think nothing helps here except adding "-norunaway" and all returns to normal. More "smart" probing inside Linked List toward connections means more iterations... Majority of UE1 specific maps doesn't need "-norunaway" only those which are not for UE1...

Perhaps I did an expensive method and code structures/methods could be more optimized - different written. By chance, I did not see more candidates interested to point me a better way and then... it's what I could do after asking X times for a solution concerning ReachSpecs handling in UT - because 227 has more than UT here, still incomplete because you don't know exactly what Pawn is supported when you look at those Lines Drawn, and 227 is mangling UT maps at random...

Buggie
Godlike
Posts: 1766
Joined: Sat Mar 21, 2020 5:32 am

Re: Fight with runaway limit

Post by Buggie » Sat Apr 02, 2022 7:24 am

Remake loops not able solve runaway limit problem, just make appear it little after. for example if you use 8 if's inside loop then remake loop only give you 10% more. So it is not big win. If you push limit in x4 times, then OFC this remake not help at all.

Also if you use goto - it too jump, which make +1 point for each goto.