5 ways to turn 1 into 0 and 0 into 1


    Apr 18 2015 | 8:49 pm
    Hi guys, which one is the best CPUwise? I mean, is using logic operators more CPU intensive than using simple math? Is using simple discrete math objects better or worst that using [expr]? Is using [sel] a better way to do it?
    many thanks!

    • Apr 18 2015 | 10:07 pm
      you forgot one:
    • Apr 19 2015 | 5:55 am
      i havent looked into it, because currently the copying does not work (i begin to dislike the permanent website updates), but the three shortest ones are for sure these:
      [!= 1]
      [== 0]
      [if $i1]
    • Apr 19 2015 | 6:02 am
      oh btw, [> 0] and [< 1] will also work, but it is a bit dangerous to develop a program like that. :)
    • Apr 19 2015 | 10:15 am
      Hi Alfonso.
      This is a weird question... I mean—a perfectly legitimate one, of course, but I can't imagine a situation in which the difference in performance cost between == 0 and != 1 is even slightly noticeable... But I might be wrong!
      The easiest way to know is, I think, doing some testing: you can connect a [uzi 100000000] and a cputimer (the little subpatch you find in the cpuclock help file) to each module, and see what figures you get.
      I'm not doing the test myself, because I want to take a guess: and my guess is that expr and if are the slowest (and possibly if slower than expr, since it has to do one more branching), as they have to somehow interpret the expression each time; the options involving more than one object come next, as passing messages through inlets and outlets is expensive; [!- 1] is better, but arithmetic operators are slightly slower than logical operators as they have to keep into account signs, carries, etc.; and I'd say there is no significant difference between [== 0] and [!= 1].
      Faites vos jeux...
      aa
    • Apr 19 2015 | 10:27 am
    • Apr 19 2015 | 11:22 am
      @All...hi and thanks guys! I was just curious 'cause in the long run when in a patch i have a lot of triggering logic involving those kind of things and i.e. multiple patches are running in i.e. 20 M4L devices...well even a 2% cpu can be useful. I use to run pretty heavy setups in my performances so i was just askin' out of curiosity.
      @ANDREA AGOSTINI thanks for the tip...seems that [!- 1] is more than 5 times ( often between 5 and 10 times ) faster than [== 0]. Obviously we 're talking of very small figures ( in the order of 10^-3 ms for [!-1] and 10^-2 ms for [== 0] ).
      @WETTERBERG yeah! that's the easiest one indeed! i'm a dumbass :-)
      @HZ37 yeah a dangerous syndrome! :-)
      all the best everyone!
    • Apr 19 2015 | 3:19 pm
      HZ37: specifically, the First Rule of Optimization is very VERY important while maxing.
    • Apr 19 2015 | 3:26 pm
      @WETTERBERG great! :-)
    • Apr 19 2015 | 6:29 pm
      generic rule with those simple objects: you usually save the most CPU when avoiding connections, i.e. try to use as less objects as possible.
      the solution using [select] is by far worse than each of the solutions using only one object.
      from that viewpoint the funny article about premature optimization is partially invalid for max/msp: in max you often optimize by writing less code than you had in the first sketch of your patch.
      my name is a good example, too. it used to be much longer 15 years ago:
      -110
    • Apr 20 2015 | 7:58 am
      Worrying about the difference between [!= 1] and [== 0] when you're passing messages through patch cords is like putting air conditioning on in the house while all the doors and windows are open. And you've got the radiators running.
      Message lookup with patch cords uses hundreds, if not thousands, of times more CPU than simple logical comparisons.
      If you're worried about CPU (which you should not be until you've got your logic working), either of your two single-box "logic" comparisions will be best—the other solutions are, frankly, on the Rube-Goldbergish side (for those outside the US, Heath Robinson, Jean Tinguely, Storm P, chindōgu, etc.).
      If you're worried that you may need to update a potentially expensive logic decision, wrap it into an abstraction. Abstractions are cheap at run time (although they take a little longer to load when you open a file).