I don't remember zep announcing it, but I just discovered that the problem we found a while back on this thread...

https://www.lexaloffle.com/bbs/?tid=29364

...seems to have been fixed. At the time, the power operator (the caret symbol, "^") only worked for positive whole numbers, not negative or fractions.

For you cycle-counters out there, I've tested it, and the cost is 9 cycles:

CYC CODE
--- ----------------------------
  9 L1=L2^2
  1 L1=L2*L2

Notice that's versus 1 cycle for a multiply, so use v*v to square a value, not v^2. In fact, if you can spare the tokens, doing a handful of multiplies will still be faster for small whole-number powers.

Anyway, thanks to zep for fixing that. I can remove my custom pow() functions now. :D

While I'm talking cycles...

Also worth noting is that a lot of methods of accessing global variables, global functions, and table members are more expensive than they used to be.

When this happens, it seems to cost one more cycle than it used to, which is in line with what I think was always intended. Many global accesses used to be 1 more cycle than locals, but not all. Now they all seem to be. So reading a global in your expression now costs 2 cycles, while a local costs 1.

I think the table member thing is a bugfix as well. I found at one point that I could do x=y and x=table.y in the same number of cycles, but that is no longer the case.

I think most people who care about performance already habitually cache values in local variables, so these issues shouldn't be a problem, just something to be aware of.