| 10-16-2007, 05:44 PM | #2 | |
Square root is SLOW. You should do what you suggested: Quote:
That is the fastest, as far as I know. Less calculations each loop. |
| 10-16-2007, 06:02 PM | #3 |
function Knock takes unit u, angle a, speed v, time t returns nothing
Should be: function Knock takes unit u, real angle, real speed, real time returns nothing Otherwise those parameters look like structs :) local unit u=GetSpellAbilityUnit() = local unit u=GetTriggerUnit() This is totally off-topic, I know, but I just couldn't resist...... |
| 10-16-2007, 09:42 PM | #4 | ||
Quote:
I think that Sin and Cos and Atan2 ought to be just as slow as SquareRoot. And I only use 2 SquareRoots, whilest the angle-approach requires three trig-calls. (I am assuming this. If it turns out that SquareRoot is slower than trig-funcs, then fine) Quote:
Yeah, when using Sin and Cos, the fastest version is to store the xspeed per period values, like this: JASS:call SetArrayReal(myArray,myArrayIndexForXSpeed, Cos(angle)*speed*timer_updateInterval ) |
| 10-17-2007, 12:31 AM | #5 | |
Quote:
Why 3? (I might just be forgetting something). I'm not really sure whether SquareRoot or the trig-funcs are slower, but why not just use the other method? |
| 10-17-2007, 01:05 AM | #6 |
Square root is very slow. I think even directly calling PolarProjectionBJ would be faster then SquareRoot*2. However, I can't say for sure. Also, if both dx and dy are > 0, aren't you calling four square roots? (Or is that not possible? Haven't looked over the calling code.) |
| 10-17-2007, 01:12 AM | #7 |
It doesn't even matter how fast or slow the initial function is, just precache the cos/sin and use an array lookup in the callbacks, that's as fast as it's gonna get. |
| 10-17-2007, 02:20 AM | #8 |
Measurements on my machine, an Athlon 64 4400+, 1stddev error bars are all at +-5us. Calling empty native: 29us Calling sin: 30us Calling sqrt: 30us Multiplying two numbers: 40us Setting a global real: 20us Calling empty JASS function: 18us |
| 10-17-2007, 04:59 AM | #9 |
Sin and Sqrt have the same speed. Interesting. Is this method possibly faster for moving targets? |
| 10-17-2007, 08:08 PM | #10 | |||
Quote:
It doesn't matter much, that's right. However, if this method actually is a little bit faster==better, then why not use it instead? As I showed in the code; with both methods I could "precache" the x-speed and the y-speed. That's the point of this thing. It generates the same data. Quote:
Nah, my method will always run two SquareRoot-functions (unless dy==0). It's controlled by a simple if-then-else. Quote:
These results are staggering... Multiplying a real with itself is ~33% slower than running a Sin or SquareRoot function? Calling a Sin function is ~50% than setting a variable? Perhaps I have to rethink my scripting. Huge thanks Pipe! |
| 10-17-2007, 11:48 PM | #11 |
Multiplication isn't slow, there are just more operations to loading two variables and acting on them. |
| 10-17-2007, 11:54 PM | #12 | |
Quote:
1.) it's ugly and longer 2.) it makes no difference at all |
| 10-18-2007, 01:46 AM | #13 |
interesting numbers Pipe... |
| 10-18-2007, 01:49 PM | #14 | |
Quote:
1. Yes it's longer. Calling it ugly is almost an insult; so please don't. 2. That's why I posted this. I wanted to know if it made any difference. PipeDream has provided data which makes me think that it does not. |
