The LSL Hackers' Test v. 0.9

Original test score: 62
New test score, including all added questions before this post: 66

I just might be a linden.



However this doesn't really test your LSL skills, honestly... More the mistakes you've made (like someone said previously). I expected more from this...




New test score, including all added questions before this post, and including the last few sentences: 67

If there's a time difference between these, Linden Labs needs to hire a compiler guy.

There is a difference and they do need to hire a compiler guy. (but (++i) is actualy the same in bytecode as (i = i + 1) hmmm or was it (i = 1 + i) i forget, shouldn't matter).

forgot

Object shouts: Empty Script.

Hmm...I actually think (i++) is the same bytecode as (i=i+1) and from what I know, both should be slightly slower than (++i). I think the (i=i+1) should be slowest too. I may be wrong. But I think most modern compiler should have fixed all the difference anyway, I dunno for SL though.

Probably a flawed test, but here is what I got:

 CODE             TIME          DEVIATION
i++;             0.001300     +/- 0.000053
++i;             0.000918     +/- 0.000056
i = i + 1;       0.000937     +/- 0.000045

Based upon take 5 samplings of 10,000 iterations at various times. The time for the while loop is subtracted from the overall time to isolate the particular target code. (I have a whole spreadsheet of this junk....)

just so everyone knows, there is no ++ or -- operator (likewise there aren't +=, -=, *=, %=, /= operators) they are expanded out.

anatomy of "b++;"

50 00 00 00 04 // push dword at local address 0x4 into stack
  5e 00 00 00 01 // push dword 0x1 into stack
    50 00 00 00 04 // push dword at local address
      70 11 // pop two dwords from the stack, add them with integer arithmatic, push result into stack
    30 00 00 00 04 // peak dword from stack and copy into local address 0x4
    01 // pop dword from stack
  01 // pop dword from stack

anatomy of "++b;"

5e 00 00 00 01 // push dword 0x1 into stack
  50 00 00 00 04 // push dword at local address
    70 11 // pop two dwords from the stack, add them with integer arithmatic, push result into stack
  30 00 00 00 04 // peak dword from stack and copy into local address 0x4
  01 // pop dword from stack

"--" works the same way except it's "71" instead of "70"

if you were wondering "b = b + 1" has the same bytecode as "++b" i've check.

Hm...weird. So (i++) is far slower than (i=i+1)? How could that be? It should be as slow at least. Lindens should do somethings to fix that, many people use (i++) just because they think it faster

I have a bad habit of using ++i in my for loops for other languages now.


And it's all Strife's fault.

and I have always had habit of using 'i++;' and 'i+=j;' everywhere i could for so long time o.o

That definately make sense - my ++i and i = i + 1 test's time are within their deviation from each other.

Incidently, how are you seeing the inner workings of the LSL VM Strife? This could save me a lot of time of running time tests to figure out relative code sniplet time/efficieny if I could just calculate it by it's byte code steps.

Which leads to:
73 [] - You can quote the byte code for LSL statements.

i++ isn't that much slower. I'm surprised it's repeating the fetch, I'd have thought a dup would be faster... or isn't there a "dup" opcode?

Strife, where are you getting this info about the internals of LSL?

And yes, they need a compiler guy to fix the damn "a-1" bug.

i haven't talked with LL recently about this but last time i did they said it would be best if i didn't say how.

I'll release my notes shortly...