^..^

21st February 2005 22:42 UTC

calculation-speed comparison
Just now we discussed whether a calculation of sines in init and storing them in megabuf or calculating them directly in point would be faster. So i tried to make a preset to compare both kinds. Unfortunately i don't get it to work. It'd be kind if someone could check where in the code i made the mistake.
Thanks a lot!

/edit: i know that i "deactivated" one line of code using "//", but that's not the mistake...

UnConeD

22nd February 2005 01:01 UTC

Note that such a comparison is not good, as you need to compare them in a realistic environment: i.e. inside a complicated preset.

With just a simple circle like this, the entire sin table probably fits into the cache so the megabuf seems faster. But in a realistic preset with lots of code, the megabuf can get swapped out of the cache.

As far as the code goes, the problem is simple. You do: exec2(index+1, ...)

This doesn't do anything, it should be exec2(assign(index,index+1), ...)

Some notes:

- When using megabuf indexes, you should cast them to integers with floor(). For example if you have (i*$pi*2)*2 items with even and odd items, you need to do floor(i*$pi*2)*2 and floor(i*pi*2)*2+1. Otherwise you have no guarantee that (i*$pi*2)*2 is an even item.
- You don't reset the_count and index in your scope, which means it only has the right values the first time. Perhaps the mod takes care of it, but you should be on the safe side anyway, becuase typically the amount of points has no relation to the size of the lookup table. This is only because you're drawing a circle.

^..^

22nd February 2005 10:11 UTC

Thanks!
What a simple problem... But as i said i'm not yet 100% familiar with this kind of code. Bout the circle: i chose the simplest shape that uses a sin, to just get the code to work, then i wanted to "complicate" it.

Also thanks for the tips! Actually the modulus should reset the counter, isn't it a reliable operator?

One word about my idea of the table: as avs never does an continous calcultion (variables don't increase on infinite small amounts, they increase on predefined steps like "+0.02 per frame", dont' they?) it's always only approximate if you draw a shape that way, so the megabuf could offer a self defined exact list of sin-values. This list will get as big as you want it to be detailled, cause sin actually is a periodic function, (sin(x) is the same like sin(x+2*pi)). So only the values in the bounds of 0 and 2*pi have to be stored. All further x values wont have different sines.

PAK-9

23rd February 2005 21:05 UTC

coned is right, the code page will get swapped out of cache after a certain size so a propper test needs a lot of code. I'm trying to think of a robust but simple idea for a test preset, if only AVS had nop's it would be a lot easier, perhaps a load of useless assignments to a LOT of different variables to really fill up the stack/heap and push the memory usage out of just cache, and it would also make sufficiently large code pages.

edit: I forgot to say, ^..^'s test is still valid to a point, because if he isnt going to make complicated presets he doesnt need a complicated test. Its still not a very useful test tho.

^..^

23rd February 2005 21:39 UTC

well, at first i wanted to get the code in init to work. After that the code should become more "demanding"...
However i don't have good idea for that. I would ask you for help, but as i know you're quite busy at the moment. So i'll postpone this idea for the time being. Besides, i don't have that much free time either...

btw what are "nop's"?

PAK-9

23rd February 2005 21:47 UTC

nop is an asm mnemonic that stands for no operation. If AVS had them you could just paste a few thousand nops which would make the code pages really big (assuming evallib didnt optimise them out). But it doesnt, so you cant.

^..^

23rd February 2005 21:58 UTC

thanks!
besides, are you really reeeaally curious about knowing wich code-type is faster? cause i did this as an exercise at first, but somehow i lost that "initial ambition"... ;)

PAK-9

24th February 2005 17:22 UTC

I'm not really that curious because I'm 95% sure a sine will be slower. I would be borderline gobsmacked if a megabuf retrieval turned out to be slower.

^..^

24th February 2005 17:29 UTC

but unconed's explanation also seems logical to me...
Perhaps i'll work further on a useful test-preset, if i get a idea what to use as "benchmark code"..