Porting Flash 9 Code

I have some libraries in flash 9 (robotics code) (I think this is some ecmascript format). Does anyone have any insight into how difficult this will be to port to Unity's javascript version? Also, does anybody have any speed comparisons between the two?

 

Anything that doesn't use flash-specific APIs is pretty easy. I have a number of pure math functions that I was able to copy and paste into Unity from Flash CS3. Then there are like functions that live in different places, like some of the math stuff, that're easy enough to replace.

The way classes work is different, though. If you're used to the Flash CS3 class and package structure, then you've actually got it easy -- you remove the class and package definitions, and just let the class properties live in what feels like global namespace but really isn't... Give it a go.

Far as speed comparisons go your guess is as good as mine; I feel like it's apples and oranges. However you could always do math function calls to test speed. I personally love the "multiply a variable by 0.5 100,000 times vs divide by 2 100,000 times" test. First time I did that it blew my mind.

 

Sorry for the diversion, but out of curiosity, what was the result of your test?

 

I haven't run the test in Unity (I just haven't been curious enough), but multiplying by 0.5 is a lot faster than dividing by 2. This seems to be the case in most scripting languages, and even in some regular compilers. I tried it in Flash and found that the division runs at least 15% slower in all situations.

A friend of mine told me about that a while back. When you're doing a few thousand of those per frame, every little bit of time saved helps. Dunno if Unity has the same thing, tho -- never sat down to time it out.

 

In AS3, it is only very slightly faster -- in test designed just to see how fast it is. Even in the best case you aren't going to double your speed and you are already talking about operations that are really fast. In the real world, you probably contributed non-optimal code in other places that has a far greater impact. It is probably one of those things that is a good habit to get into, but that will seldom make a significant difference.

FYI - In Actionscript, bitwise shift operators, as long as you aren't using Number declarations, are significantly faster than either.

 

That depends on whether you're using floating point or integers. If integers, it's faster to divide by 2. You generally want to avoid mixing floating point and integers if you can help it (since they have to be converted back and forth).

--Eric

 

It's more of a compiler issue. There's no reason why a compiler shouldn't convert any fixed division into a fixed multiplication at compile-time.

The obvious speedup for division (or multiplication) by powers of two (such as 0.5 and 2) is bit-shifting integers and adding/substracting from the exponent for floats. Again, no reason why a compiler can't do this.

Note that multiplication (even for floats) is a cheap operation these days, so optimizing multiplies is probably a waste of effort.

One case where you may want to optimize is to take into account parallel execution units (e.g. you might have four math operations in a row, two of which require an FPU, two don't). Again -- WAY beyond what anyone is likely to care about unless you're writing compilers or very highly optimized code (e.g. Photoshop filters).

I don't know how integer division can possibly be faster than multiplication. Multiplication is one clock cycle. (Unless it's something to do with JavaScript's dynamic typing ... including a 0.5 in an expression turns the entire expression into floating point...?)

 

In Unity javascript, if "foo" is an integer, "foo /= 2" gets just about exactly the same speed as "foo = foo << 1". So there might be some optimization there. Doing "foo *= .5" is three times slower however.

If "foo" is a float, "foo *= .5" is faster than "foo /= 2.0", but only by 5%. "foo /= 2" is slower than "foo /= 2.0", by about 10%. Some of this depends on your CPU no doubt; I'm on a G5.

--Eric

 

Basically you want to avoid mixing floats and integers in a single expression when possible, as mentioned above:

This gets compiled to sth like this:

Code (csharp):

1. foo = convert_float_to_int( convert_int_to_float(foo) * 0.5 )

Note how the compiler has to convert foo to a float and back again. This is the reason for the slowness.

Again there is conversion, but only a single int to float in this case. (Although this ought to have been optimized away by the compiler.)

... and the compiler. Some compilers even recognize the *0.5 case above and change it into a bitshift operator, which would make all cases identical.
Also the PPC used to have better floating point performance than intel processors, although I don't know it is still the case with the latest generations of CPUs.

(Complicating all this, Intel CPUs have two different ways of doing floating point operations: one using old FPU stack-like operations and other using the SSE registers. Using SSE, even for single data is faster than the old FPU instructions. But afaik, Mono currently uses the old way of performing floating point calculations.)