Announcement

Collapse
No announcement yet.

Please implement Short-Circuit evaluation for Blueprint

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Uh this is already supported, you just stagger the branch nodes. Do x then if true do y. I thought this was the intended workflow for that in BP.

    Regardless c++ is by standard a short circuiting language. since BP is written in c++ you'd think that it would be SC'd as well, can you provide proof it isnt SC'ing ?

    I wonder if SC was overridden for BP so that there are no errors in branch prediction.

    Because it seems like blueprint works on the surface as such that each node is its own function and they try to safely acquire all data needed for said function before execution, which would answer why both get looked at (i honestly have no idea)
    Last edited by SaxonRah; 09-12-2015, 05:19 AM.
    Youtube
    Machine Learning C++ Plugin
    Lindenmayer System C++ Plugin

    Comment


      #17
      Blueprint runs on virtual machine, tt's something that virtual machine needs to support or it something that need to be node class.
      =========
      My Tutorials:
      Basic knowledge about Classes and UObject environment and stuff like that

      Comment


        #18
        Originally posted by SaxonRah View Post
        Uh this is already supported, you just stagger the branch nodes. Do x then if true do y. I thought this was the intended workflow for that in BP.

        Regardless c++ is by standard a short circuiting language. since BP is written in c++ you'd think that it would be SC'd as well, can you provide proof it isnt SC'ing ?

        I wonder if SC was overridden for BP so that there are no errors in branch prediction.

        Because it seems like blueprint works on the surface as such that each node is its own function and they try to safely acquire all data needed for said function before execution, which would answer why both get looked at (i honestly have no idea)
        @SaxonRah yeah I'm away you can just stack the branch , but it seems counterintuitive to have AND node and ended up having to do that.

        BTW , I can confirm it doesn't short circuit surely. Just do an AND node with 2 pins. Put false at the top one. Connect the second to a pure function that returns boolen . In the pure function , just do print string. You'll see the string printed , which should not , because if the first pin is false , the second one must not be evaluated.


        I think it is to be noted that , This is an optimization for an OR as well. Meaning , if the first one is true , the rest should NOT be evaluated.
        Last edited by Frozenfire; 09-13-2015, 12:39 PM.
        Developer at AmmoboxStudios.



        Eximius ( An FPS/RTS Hybrid )

        Comment


          #19
          Jesus christ, is the OP's simple point really so hard to understand or is it common to simply not read messages before posting here? He clearly statet what's the problem, he made examples, he even linked the wikipedia article. It's that simple:
          If the first condition is false already, Blueprint shouldn't even evaluate the other pins connected to an AND node. That's not only more elegant for null-checks etc., it's way faster, too (for obvious reasons.)

          And yes, it would be great if BP would behave this way.

          spyro
          Last edited by spyro; 09-14-2015, 05:33 AM.

          Comment


            #20
            Originally posted by Frozenfire View Post
            @SaxonRah yeah I'm away you can just stack the branch , but it seems counterintuitive to have AND node and ended up having to do that.

            BTW , I can confirm it doesn't short circuit surely. Just do an AND node with 2 pins. Put false at the top one. Connect the second to a pure function that returns boolen . In the pure function , just do print string. You'll see the string printed , which should not , because if the first pin is false , the second one must not be evaluated.


            I think it is to be noted that , This is an optimization for an OR as well. Meaning , if the first one is true , the rest should NOT be evaluated.
            The reason i said i thought it was the intended workflow is that im quite sure that kismet worked like this too. Where it would check both regardless. I could be mistaken.


            You're right it doesn't SC. Which would imply its programmed like this for a reason, I'll try and look up the code for the nodes and see if anything is specifically said so.

            So the nodes are quite simple they literally just say "return A && B;" and "return A || B;" Which is weird because both && and || are short-circuiting by c++ standard. The only way to get a non SC OR / AND is by using the + for OR and * for AND in c++ Which is actually Boole Algebra.. but you get the desired functionality of non SC checks.

            Can i get a much more experienced Epic Developer to tell me why this is happening ? I'm so freaking confused as to why this happens, and im really interested as to how you've done this.

            Operator overloading somewhere perhaps ?


            Actually I wonder if the arguments passed to the OR and AND nodes are function calls and they are executed first thus the short circuiting is basically useless because you've seen the results of the functions before you checked the returns.
            Last edited by SaxonRah; 09-14-2015, 05:55 AM.
            Youtube
            Machine Learning C++ Plugin
            Lindenmayer System C++ Plugin

            Comment


              #21
              aha!
              this explains a lot.

              +1
              this should really be a priority for a hot fix
              tegleg.co.uk - indie electronic music label
              Android + HTML5 WIP Physics Game
              PC Games - Android Apps

              Comment


                #22
                I think I have an idea how to fix this problem. Temporary variables and the comma operator!
                Instead of "return A && B;" you should write
                "bool ABool, BBool;
                return (ABool=A), (BBool=B), (ABool && BBool);
                "

                I think this would make it so that it would tell the compiler to force a sequence of actions.
                Youtube
                Machine Learning C++ Plugin
                Lindenmayer System C++ Plugin

                Comment


                  #23
                  Just have been following the discussion and like to add my 2 cents

                  Short circuit evaluation can speed up certain things, but also has its caveats.
                  For example if evaluation of the second term in the boolean AND expression is doing more than just evaluating.
                  Sometimes I write code where functions evaluate something but also does "global" stuff. Not a nice style, I know, but it sometimes really simplifies coding a lot.
                  In Delphi I mostly use short circuit evaluation and use a compiler switch to enable "full" evaluation on a case by case base.

                  So, if implemented, it should be possible to choose the evaluation method...

                  Comment


                    #24
                    First of all, thanks for mentioning short circuit evaluation. My intuitive solution was to chain my nodes, which produces a lot of ugly code but it definitly speeds things up.

                    Originally posted by KVogler View Post
                    Just have been following the discussion and like to add my 2 cents

                    Short circuit evaluation can speed up certain things, but also has its caveats.
                    For example if evaluation of the second term in the boolean AND expression is doing more than just evaluating.
                    Sometimes I write code where functions evaluate something but also does "global" stuff. Not a nice style, I know, but it sometimes really simplifies coding a lot.
                    In Delphi I mostly use short circuit evaluation and use a compiler switch to enable "full" evaluation on a case by case base.

                    So, if implemented, it should be possible to choose the evaluation method...
                    I think its always good to make things more strict. If there is a better way to do something, everybody should be forced to do it like this. Everything else would end up in ugly and slow code.

                    In my opinion, logical operators are not made to execute code whichs modifies the state of your program.
                    Last edited by SchnitzelDude; 09-14-2015, 07:33 AM.

                    Game Design - Photogrammetry - Programming
                    Tutorials · Twitter · Twitch

                    Comment


                      #25
                      In my opinion, logical operators are not made to execute code whichs modifies the state of your program.
                      That is what I meant by "Not a nice style"
                      Anyway, its not the operators that are the issue, but the evaluation of the operands. Te operators just define the operation and precedence rules govern their order.
                      Cases where, whilst evaluating an operand of a boolean expression, a program modification can simplify things are recursive tree travelling where some data is accumulated in a globally accessible list...

                      Comment


                        #26
                        Originally posted by spyro View Post
                        Jesus christ, is the OP's simple point really so hard to understand or is it common to simply not read messages before posting here?
                        Calm down, we get it. My point was it's already possible so I didn't see what OP said was *missing* as such. Like SaxonRah says, you stagger the branch nodes.

                        Originally posted by SchnitzelDude View Post
                        In my opinion, logical operators are not made to execute code whichs modifies the state of your program.
                        Depends on the situation though, you might be performing an op on a variable using pass-by-reference, and returning based on what happens.



                        I don't see any reason NOT to have this, though so long as there are no major hits in flexibility taken by doing so. It should be off by default too, most Blueprint users probably have no idea what SCE is, and usually won't ever need to.

                        Comment


                          #27
                          I noticed this with the Select nodes as well. It evaluates every pin before selecting the result. It's very annoying, since it forces you to use execution branching inside otherwise pure functions/macros and in large select nodes it can cause unexpected performance overhead.

                          I assume this is a side effect of how BP nodes work: they take all the pins, feed it into their underlying C++ function and then grab the output. Implementing short-circuiting would require a node to have a different kind of logic where it executes a function for each pin sequentially (boolean operations) or evaluate a specific pin and execute a function to decide which pin(s) to evaluate next (the select node).
                          Last edited by manoelneto; 09-14-2015, 11:32 AM.

                          Comment


                            #28
                            I noticed this with the Select nodes as well. It evaluates every pin before selecting the result. It's very annoying.....
                            On the other hand it produces a "stable" evaluation speed....

                            Comment


                              #29
                              Originally posted by KVogler View Post
                              On the other hand it produces a "stable" evaluation speed....
                              it produce logspam

                              Comment


                                #30
                                I think it's fine the way it is, where simplicity is more important than brevity.
                                99.9% of the time, short-circuit evaluation would not change the running speed of a blueprint.
                                If you have a profiler that shows that in some particular case, it actually matters, then you should probably make this explicit in the blueprint by using an explicit second Branch node.
                                And the mantra has been: if performance really matters, write it in C++...

                                Comment

                                Working...
                                X