View.Update Vs View.UpdateArea

[copthesaint]

I realise I did make a thread like this in the past however I feel its very useful with this way of testing.
I originally I thought "well View.update and View.Update Area cant be a big enough difference in speed" however from testing View.Update I found out that View.Update is equivalent to View.UpdateArea (-2.-2.maxx+2,maxy+2), simply by using View.UpdateArea(0,0,maxx,maxy) you reduce the time it takes to use View.update which on my computer is approx: 0.51 ms to about 0.41ms (about 20% faster). How much time do you save? well for 100 loops you would save 10ms approx. in runtime.
The reason why I am posting this is because I myself am trying to get some extra fps from my program.

Turing:

/*View.Update vs View.UpdateArea.*/ View.Set ("graphics:640;440,offscreenonly,nobuttonbar") const RUNTIMES : int := 99 var x1 : int := round (maxx / 4) var x2 : int := round ((maxx / 4) * 3) var y : int := round (maxy / 2) var timerREC1, timerREC2 : array 0 .. RUNTIMES of int var timer : int put "please wait" for i : 0 .. RUNTIMES     timer := Time.ElapsedCPU     for j : 0 .. 99         View.UpdateArea (0-2, 0-2, maxx+2, maxy+2) %remove -2 and +2 because you can only view 0-maxx and 0-maxy in turing.     end for     timerREC1 (i) := Time.ElapsedCPU - timer     timer := Time.ElapsedCPU     for j : 0 .. 99         View.Update     end for     timerREC2 (i) := Time.ElapsedCPU - timer end for var timerSUM1, timerSUM2 : real := 0 for i : 0 .. RUNTIMES     timerSUM1 := timerSUM1 + timerREC1 (i)     timerSUM2 := timerSUM2 + timerREC2 (i) end for timerSUM1 := timerSUM1 / (RUNTIMES + 1) timerSUM2 := timerSUM2 / (RUNTIMES + 1) put "It took Turing: ", timerSUM1, "ms to run View.UpdateAREA (-2,-2,maxx+2,maxy+2) 100 times on average. ", (timerSUM1 / 100) put "" put "It took Turing: ", timerSUM2, "ms to run View.Update 100 times on average. ", (timerSUM2 / 100)

[DemonWasp]

Hmm. Interesting. I tried this:

Turing:

View.Set ("graphics:640;440,offscreenonly,nobuttonbar") const TRIALS : int := 10000 var startTime, endTime : int startTime := Time.ElapsedCPU for i : 1 .. TRIALS     View.Update end for endTime := Time.ElapsedCPU put "View.Update(): ", (endTime-startTime), "ms" startTime := Time.ElapsedCPU for i : 1 .. TRIALS     View.UpdateArea(0,0,maxx,maxy) end for endTime := Time.ElapsedCPU put "View.UpdateArea(0,0,maxx,maxy): ", (endTime-startTime), "ms" startTime := Time.ElapsedCPU for i : 1 .. TRIALS     View.UpdateArea(-2,-2,maxx+2,maxy+2) end for endTime := Time.ElapsedCPU put "View.UpdateArea(-2,-2,maxx+2,maxy+2): ", (endTime-startTime), "ms"

And got this:

code:

View.Update(): 5ms View.UpdateArea(0,0,maxx,maxy): 1337ms View.UpdateArea(-2,-2,maxx+2,maxy+2): 1454ms

It looks like View.Update() can determine whether it should bother updating or not (have you drawn anything since it was last called?) while View.UpdateArea doesn't do anything of the sort. If I force it to actually do the update...

Turing:

View.Set ("graphics:640;440,offscreenonly,nobuttonbar") const TRIALS : int := 10000 var startTime, endTime : int startTime := Time.ElapsedCPU for i : 1 .. TRIALS     Text.Locate(1,1)     put i     View.Update end for endTime := Time.ElapsedCPU Text.Locate ( 3, 1 ) put "View.Update(): ", (endTime-startTime), "ms" startTime := Time.ElapsedCPU for i : 1 .. TRIALS     Text.Locate(1,1)     put i     View.UpdateArea(0,0,maxx,maxy) end for endTime := Time.ElapsedCPU Text.Locate ( 4, 1 ) put "View.UpdateArea(0,0,maxx,maxy): ", (endTime-startTime), "ms" startTime := Time.ElapsedCPU for i : 1 .. TRIALS     Text.Locate(1,1)     put i     View.UpdateArea(-2,-2,maxx+2,maxy+2) end for endTime := Time.ElapsedCPU Text.Locate ( 5, 1 ) put "View.UpdateArea(-2,-2,maxx+2,maxy+2): ", (endTime-startTime), "ms"

...then I get:

code:

View.Update(): 1728ms View.UpdateArea(0,0,maxx,maxy): 1608ms View.UpdateArea(-2,-2,maxx+2,maxy+2): 1729ms

Presumably the extra time taken by View.Update() is involved in checking whether it needs to do the relatively-expensive "actually update" operation.

[mirhagk]

Interesting find Demonwasp, but I feel like that should just be a compiler optimization. Perhaps that should be looked at in OpenTuring.

[copthesaint]

DemonWasp @ Mon Jan 30, 2012 wrote:

Hmm. Interesting. I tried this:

Turing:

View.Set ("graphics:640;440,offscreenonly,nobuttonbar") const TRIALS : int := 10000 var startTime, endTime : int startTime := Time.ElapsedCPU for i : 1 .. TRIALS     View.Update end for endTime := Time.ElapsedCPU put "View.Update(): ", (endTime-startTime), "ms" startTime := Time.ElapsedCPU for i : 1 .. TRIALS     View.UpdateArea(0,0,maxx,maxy) end for endTime := Time.ElapsedCPU put "View.UpdateArea(0,0,maxx,maxy): ", (endTime-startTime), "ms" startTime := Time.ElapsedCPU for i : 1 .. TRIALS     View.UpdateArea(-2,-2,maxx+2,maxy+2) end for endTime := Time.ElapsedCPU put "View.UpdateArea(-2,-2,maxx+2,maxy+2): ", (endTime-startTime), "ms"

And got this:

code:

View.Update(): 5ms View.UpdateArea(0,0,maxx,maxy): 1337ms View.UpdateArea(-2,-2,maxx+2,maxy+2): 1454ms

It looks like View.Update() can determine whether it should bother updating or not (have you drawn anything since it was last called?) while View.UpdateArea doesn't do anything of the sort. If I force it to actually do the update...

No View.Update cannot. You just dont have a put call before you used View.Update. thus the screen wasnt even set to visible. When you put the view.update time then it calls the screen to be visable, so view.update area then updates the newly visable screen. You would get the same results if you but View.UpdateArea before View.Update.

DemonWasp @ Mon Jan 30, 2012 wrote:

code:

View.UpdateArea(0,0,maxx,maxy): 1337ms

epic

[DemonWasp]

Ah, yes, that's correct. That leaves me pretty confused though: why would View.Update() be slower than View.UpdateArea(0,0,maxx,maxy)? Seems...wrong. I mean, I would imagine that View.Update() will just call View.UpdateArea(0,0,maxx,maxy), but that wouldn't explain why it's slower.

[copthesaint]

well, my prediction is that view.update() calls view.updatearea (-2,-2,maxx+2,maxy+2) or something more ridiculous like that.

[mirhagk]

Or just the extra function call is that little discrepancy.

[crossley7]

I believe I saw an older thread that explains this. I have no idea where to look for it, but I believe this was found because View.UpdateArea had been optimized prior to development being stopped for Turing while View.Update had not.

Then again, if that runtime is so close for the 2 pixels larger, it may be updating a screen that is just larger than the displayed screen

[evildaddy911]

I thought that View.Update updates (-maxint,-maxint,maxint,maxint), but...

Turing:

View.Set ("offscreenonly") var x1 : int := Time.Elapsed for i : 0 .. 10000     drawfillbox (Rand.Int (0, maxx), Rand.Int (0, maxy), Rand.Int (0, maxx), Rand.Int (0, maxy), Rand.Int (0, 255))     View.Update end for var x2 : int := Time.Elapsed for i : 0 .. 10000     drawfillbox (Rand.Int (0, maxx), Rand.Int (0, maxy), Rand.Int (0, maxx), Rand.Int (0, maxy), Rand.Int (0, 255))     View.UpdateArea (0, 0, maxx, maxy) end for var x3 : int := Time.Elapsed put "Update:", x2 - x1 put "UpdateArea:", x3 - x2 View.Update

OUTPUT:

Quote:

Update:14465
UpdateArea:15140

[Aange10]

I'd like to put this out (the same testing, but in a more controlled envrionment)

Turing:

View.Set ("offscreenonly") const MAXX : int := maxx const MAXY : int := maxy const ZERO : int := 0 const NEGATIVE_ONE : int := -1000 const MAXX_PLUS_ONE : int := maxx + 1000 const MAXY_PLUS_ONE : int := maxy + 1000 var repetitions : int := 1000 var timerOne : int := Time.Elapsed () for i : 1 .. repetitions     drawfillbox (ZERO, ZERO, MAXX, MAXY, 50)     View.Update end for var timerForViewUpdate : int := Time.Elapsed () - timerOne var timerTwo : int := Time.Elapsed () for i : 1 .. repetitions     drawfillbox (ZERO, ZERO, MAXX, MAXY, 50)     View.UpdateArea (ZERO, ZERO, MAXX, MAXY) end for var timerForViewUpdateArea : int := Time.Elapsed () - timerTwo var timerThree : int := Time.Elapsed () for i : 1 .. repetitions     drawfillbox (ZERO, ZERO, MAXX, MAXY, 50)     View.UpdateArea (NEGATIVE_ONE, NEGATIVE_ONE, MAXX_PLUS_ONE, MAXY_PLUS_ONE) end for var timerForViewUpdateArea2 : int := Time.Elapsed () - timerThree put "Time for View.Update on ", repetitions, " repetitions: ", timerForViewUpdate put "Time for View.UpdateArea (0,0,",MAXX,",",MAXY,") on ", repetitions, " repetitions: ", timerForViewUpdateArea put "Time for View.UpdateArea (",NEGATIVE_ONE,",",NEGATIVE_ONE,",",MAXX_PLUS_ONE,",",MAXY_PLUS_ONE,") on ", repetitions, " repetitions: ", timerForViewUpdateArea2

I noticed at 1000 reps, the last View.UpdateArea is consistently the fastest, however at 10,000 reps it becomes slightly inferior to the first View.UpdateArea.

However all tests showed View.Update to be slower.

I'd try tweaking the parameters of the last View.UpdateArea until you found a number that found a consistent match (or write a program to do it)

[Dreadnought]

Aange10 wrote:

I noticed at 1000 reps, the last View.UpdateArea is consistently the fastest

I could not reproduce this consistently, (though it did happen at least 1 out of 5 times when I ran the program).

However, if I reverse the order of Aange10's tests, the "last View.updateArea" is the worst by a significant margin, and View.Update and View.UpdateArea(0,0,maxx,maxy) have run times within ~4% of each others. (with View.Update winning about half the time)

Note that these are my own results, but I feel they are sufficient to show that these tests have obvious flaws.

[Aange10]

Quote:

but I feel they are sufficient to show that these tests have obvious flaws.

Indeed. Solution?

I was thinking about writing a program to take the time of 10,000 executions of View.Update and View.UpdateArea (0,0,maxx,maxy), and have the prgoram find out what parameters fit into View.UpdateArea () that makes its runtime = View.Update.


Any major flaws that would discourage this experiment?

[mirhagk]

Shut down every service on your computer and kill every process you can, also compile the code into an exe before you run it (make sure you have the options either be command line arguments or as get statements at the start of the program).

Really the difference is moot, but I don't think View.UpdateArea is really significantly faster.

[Dreadnought]

I certainly encourage any further testing. From what I have seen so far View.UpdateArea(0,0,maxx,maxy) appears to be about 5% faster. However the run times fluctuate quite a bit so I'm not sure I can say anything conclusive.

I suggest that if you want to test the two (or more) functions, you should give them they're own programs that are as similar as possible, this should avoid any oddities pertaining to the order of tests (like in your previous tests).

Also, make sure you average over a couple tests (perhaps at least once use a freshly booted PC), especially if you're going to attempt to match run times of different functions.

That's all I got right now, I feel like I know too little of what is actually going on (like what does Turing compile these functions to).

Good luck!

[copthesaint]

I made one final program that I believe will give the most accurate results and overall when I ran the program at 1000 tests at graphics 800x600 View.UpdateArea would run 0.035 ms aprox. faster which isnt alot but you save that every time your program runs a loop and every time I ran it, it was always faster then View.Update. Its probably just a difference in how it is called, since View.Update has to go fetch the dimentions its self while View.UpdateArea (x1,y1,x2,y1 : int) is already specified and thus only has to update it.

Turing:

View.Set ("graphics:800;600,offscreenonly,nobuttonbar") const TESTLOOPS : int := 1000 const NOVIEWSCREENTESTS : int := 10 const VIEWSCREENTESTS : int := 10 proc view     View.Update end view proc viewUp     View.UpdateArea (0, 0, 800, 600) end viewUp var p : array 0 .. 1 of procedure x p (0) := view p (1) := viewUp type Test :     record         timer : array 0 .. 1 of array 0 .. 1 of int     end record var testsA : array 1 .. NOVIEWSCREENTESTS of Test var testsB : array 1 .. VIEWSCREENTESTS of Test for test1 : 1 .. NOVIEWSCREENTESTS     for i : 0 .. 1         testsA (test1).timer (i) (0) := Time.ElapsedCPU         for loopNum : 1 .. TESTLOOPS             p (i)         end for     end for end for for test1 : 1 .. NOVIEWSCREENTESTS     for i : 0 .. 1         testsA (test1).timer (i) (0) := Time.ElapsedCPU         for loopNum : 1 .. TESTLOOPS             p (i)         end for         testsA (test1).timer (i) (1) := Time.ElapsedCPU     end for end for drawdot (0, 0, black) cls for test2 : 1 .. VIEWSCREENTESTS     for i : 0 .. 1         testsB (test2).timer (i) (0) := Time.ElapsedCPU         for loopNum : 1 .. TESTLOOPS             p (i)         end for         testsB (test2).timer (i) (1) := Time.ElapsedCPU     end for end for View.Set ("text,nooffscreenonly,nobuttonbar") put "test1 results with no print." put "View.Update Data: " for test1 : 1 .. NOVIEWSCREENTESTS     put (testsA (test1).timer (0) (1) - testsA (test1).timer (0) (0)) / TESTLOOPS, "ms per loop" end for put "View.UpdateArea Data: " for test1 : 1 .. NOVIEWSCREENTESTS     put (testsA (test1).timer (1) (1) - testsA (test1).timer (1) (0)) / TESTLOOPS, "ms per loop" end for put "test2 results with print." put "View.Update Data: " for test2 : 1 .. VIEWSCREENTESTS     put (testsB (test2).timer (0) (1) - testsB (test2).timer (0) (0)) / TESTLOOPS, "ms per loop" end for put "View.UpdateArea Data: " for test2 : 1 .. VIEWSCREENTESTS     put (testsB (test2).timer (1) (1) - testsB (test2).timer (1) (0)) / TESTLOOPS, "ms per loop" end for