Studio 5000 Structure text - Adding vs Multiply

[sterky]

I have quite a large number of recipes in CASE form that I'm writing in structured text. I'm hoping to keep things clean and efficient when looking at the sum of all the code I am writing.

So my question is when it comes to computation time and program size, which is better

y = x * 3

or

y = x + x + x


This is a rather basic example and I'm sure the processor handles multiplication like multiple additions but curious if someone with better understanding can weigh in.

I've already declared some of the more common multiples outside of the Case structure, so I can just reference those tags rather than compute them for each recipe. Since I do a check of all recipes for best fit, I'd like the search to be as fast as possible.

 

[drbitboy]

I would be surprised if x*n was ever slower than x+x+..., and certainly for n>2.

For searching over many recipes, then a CASE statement is probably slower than a binary search, and a binary search is probably slower than a direct array lookup (if possible).

 

[tlf30]

I would advise to always remember whatever approach you take is maintainable. Just keep in mind the readability of the code. Something might be a hair slower, but if it is readable then that is what is important.

 

[(8{)} ( .)]

The simple math operations are not going to be time issues. Where you will see big differences when raising data to a power. For example:


x * x * x


will be faster than


x^3


This was certainly the case with older processors.


Cheers,


(8{)} ( .)
(Yosi)

 

[AustralIan]

https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/logix-rm002_-en-p.pdf


example using Compactlogix 5380

Ins Type Time (us)

ADD DINT 0.013
ADD REAL 0.084
MUL DINT 0.187
MUL REAL 0.084

so for REAL, MUL is more efficient, for DINT, ADD is more efficient until y=x*15

 

[sterky]

Thank you for the doc, exactly the literature I was looking for

 

[sterky]

For searching over many recipes, then a CASE statement is probably slower than a binary search, and a binary search is probably slower than a direct array lookup (if possible).

How would you even go about doing a binary search in studio logic? Unfortunately my recipes don't follow a true ascending structure, recipe 4 and 6 might not fit my criteria but 5 could so I can't rule out checking some of the later recipes but at a certain point I definitely don't need check later recipes.

 

[drbitboy]

How would you even go about doing a binary search in studio logic? ...

Just like any other language.

I do not understand your process, and the suggestion of binary search was probably in ignorance.

What do those case statements look like i.e. the "best fit" code executed for each value of the recipe number? Are they all similar, with different values for various parameters to determine some fit-ness metric for each recipe?

 

[CapinWinky]

You'll get more noticeable performance gains by eliminating operations. For instance, if you were doing x+y+A, x+y+B, x+y+C... then doing Z:=x+y and then Z+A, Z+B, Z+C... will have a bigger impact than x**4 vs x*x*x*x.

I wouldn't bother with any optimization basic operations unless you're eliminating/optimizing at least 1000 of them. You'd get more out of eliminating a single cyclically called SSV than several hundred DINT additions.

 

[Cheeseface]

You might be assuming STX runs at the same speed as ladder. This isn't always the case. Instruction execution times don't account for operand type either, which means they also don't account for fetch and decode times.

You are almost always better off writing for future maintenance than for processor speed. Especially something like recipe handling which no one cares if it takes a few milliseconds longer.

For example: say that 3 * x becomes 2 * x. Are you going to search and replace "+ x" with ""? It's not going to work -- changing from 3 * x to 3.5 * x is impossible.

 

[sterky]

Just like any other language.

I do not understand your process, and the suggestion of binary search was probably in ignorance.

What do those case statements look like i.e. the "best fit" code executed for each value of the recipe number? Are they all similar, with different values for various parameters to determine some fit-ness metric for each recipe?

The suggestion at least gave me some interesting readings and ideas to improve the process.

At a high level, I'm getting 2 variables and checking which recipes/patterns are valid and their fit within the maximum parameters. The user can then decide which one is best for their needs.

So there may be a pattern that doesn't fit and a later pattern in the case structure that does fit. I think I will break up the Cases into sets/routines so I don't need to check later recipes at a certain breakpoint

 

[drbitboy]

The suggestion at least gave me some interesting readings and ideas to improve the process.

At a high level, I'm getting 2 variables and checking which recipes/patterns are valid and their fit within the maximum parameters. The user can then decide which one is best for their needs.

So there may be a pattern that doesn't fit and a later pattern in the case structure that does fit. I think I will break up the Cases into sets/routines so I don't need to check later recipes at a certain breakpoint

Do all cases/sets/routines use the same set, or subsets of a small set, of parameters? In other words, could the parameters for all cases be encapsulated in an array of UDTs, and the two variables fit evaluated in an AOI that uses one of those UDTs as an input argument? The the case statements are replaced by a loop over the array of UDTs.

e.g.

VAR_INPUT
    var1 : WHATEVER1;
    var2 : WHATEVER2;
END_VAR

VAR
    recipe_array : ARRAY[1..99] of RECIPE_UDT;
    iCase : DINT;
    fit_results_array : ARRAY[1..99] of BOOL;

END_VAR[COLOR=#0000ff][B]
    (* Check which recipes fit the data *)[/B][/COLOR]
    FOR iCase := 1 to 99 DO
         fit_results_array[iCase] := fit_func(var1, var2, udt_array[iCase]);
    END_FOR

    [B][COLOR=#0000ff](* Present recipes that returned True from fit function to the user *)[/COLOR][/B]
    ...

 

[Peter Nachtwey]

x*3 is probably faster because x only needs to be fetched once. Many instructions operate in one clock now. For instance a multiply and add can take one clock cycle. It depends on CPU. Also it depends on how the CPU accesses memory. In the case of X+X+X the CPU probably only needs to fetch X once from memory (slow) and then the other times from cache (fast).

What you DON'T WANT TO DO IS use this X**2 instead of X*X.

 

[sterky]

Do all cases/sets/routines use the same set, or subsets of a small set, of parameters? In other words, could the parameters for all cases be encapsulated in an array of UDTs, and the two variables fit evaluated in an AOI that uses one of those UDTs as an input argument? The the case statements are replaced by a loop over the array of UDTs.

e.g.

VAR_INPUT
    var1 : WHATEVER1;
    var2 : WHATEVER2;
END_VAR

VAR
    recipe_array : ARRAY[1..99] of RECIPE_UDT;
    iCase : DINT;
    fit_results_array : ARRAY[1..99] of BOOL;

END_VAR[COLOR=#0000ff][B]
    (* Check which recipes fit the data *)[/B][/COLOR]
    FOR iCase := 1 to 99 DO
         fit_results_array[iCase] := fit_func(var1, var2, udt_array[iCase]);
    END_FOR

    [B][COLOR=#0000ff](* Present recipes that returned True from fit function to the user *)[/COLOR][/B]
    ...

As much as I'd like to simplify the recipes to a single AOI, the math done in each recipe/pattern varies too wildly to do it. I made some significant improvements by declaring some of the commonly used math'd variables outside of the case structure.

ie

[I]a[0] := var/2;
a[1] := var;
a[2] := var*2;

b[0] := var2/2;
b[1] := var2;
b[2] := var2*2;

case 1:
  math and stuff

case 2:
  different math and stuff[/I]

so at least I don't need to handle that more common operation more than once and short tags for easy case creation/readability.

I did want to break out an overall check of the pattern to a separate case structure from pattern calculation but for ease of understand and maintenance, I am choosing not to unless I really need the performance. Much better to keep it together well at least at this stage of development