7 Replies - 9700 Views - Last Post: 04 November 2012 - 01:09 AM

#1 Masterakos  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 31
  • Joined: 20-November 10

Strange execution time behavior

Posted 28 October 2012 - 04:29 AM

Hello,

I've created a task to execute in C#. I tried to watch the execution time and i noticed something strange (at least for me). The task is this :
static void Main(string[] args)
        {
        jump: // Task is starting
            Gameboard board = new Gameboard(); //initialize things
            board.Initialize_NewGame(); //initialize things
            ChessEngine engine = new ChessEngine(); //initialize things
            Stopwatch watch = new Stopwatch(); //initialize things

            watch.Start(); // *** Stopwatch Starts ***
            foreach (Piece piece in board.Pieces)
            {
                if (piece.Color == 'W') engine.Generate_Moves(piece, new VitrualGameboard(board.Squares, board.Pieces));
            }
            watch.Stop(); // *** Stopwatch Starts ***

            Console.WriteLine("Moves generated in :" + watch.Elapsed.TotalMilliseconds.ToString("0.00") + " ms total");
            if (Console.ReadLine() == "") goto jump;
        }



So after the watch.Stop() i can print the execution time and IF i press Enter the task starts again and i get more results in milliseconds always.

Now let me show you the results on the image.


Attached Image


So how is this possible? I mean the difference in the first execution is obvious.
Does CPU cache memory has something to do with this ?

Is This A Good Question/Topic? 0
  • +

Replies To: Strange execution time behavior

#2 Ryano121  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1362
  • Posts: 3,002
  • Joined: 30-January 11

Re: Strange execution time behavior

Posted 28 October 2012 - 04:36 AM

When you run it first the CLR has to convert the IL into native machine code to run on your machine - this takes time. However when you do it again, the CLR remembers what machine code was generated before so doesn't have to generate it again. This improves the speed on subsequent rounds.

Also goto == bad :) Nothing wrong with a sentinel while loop though.

This post has been edited by Ryano121: 28 October 2012 - 04:43 AM

Was This Post Helpful? 3
  • +
  • -

#3 Curtis Rutland  Icon User is online

  • (╯□)╯︵ (~ .o.)~
  • member icon


Reputation: 4464
  • View blog
  • Posts: 7,780
  • Joined: 08-June 10

Re: Strange execution time behavior

Posted 29 October 2012 - 07:44 AM

Agreeing with the goto sentiment. This is essentially the same:

static void Main(string[] args)
{
	do{
		Gameboard board = new Gameboard(); //initialize things
		board.Initialize_NewGame(); //initialize things
		ChessEngine engine = new ChessEngine(); //initialize things
		Stopwatch watch = new Stopwatch(); //initialize things

		watch.Start(); // *** Stopwatch Starts ***
		foreach (Piece piece in board.Pieces)
		{
			if (piece.Color == 'W') engine.Generate_Moves(piece, new VitrualGameboard(board.Squares, board.Pieces));
		}
		watch.Stop(); // *** Stopwatch Starts ***

		Console.WriteLine("Moves generated in :" + watch.Elapsed.TotalMilliseconds.ToString("0.00") + " ms total");
	}while(Console.ReadLine() == "");
}



With the added benefit of not using GOTOs.
Was This Post Helpful? 1
  • +
  • -

#4 Masterakos  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 31
  • Joined: 20-November 10

Re: Strange execution time behavior

Posted 01 November 2012 - 06:24 AM

why using goto == bad ? Very interesting, i've never heard of it.
Was This Post Helpful? 0
  • +
  • -

#5 Curtis Rutland  Icon User is online

  • (╯□)╯︵ (~ .o.)~
  • member icon


Reputation: 4464
  • View blog
  • Posts: 7,780
  • Joined: 08-June 10

Re: Strange execution time behavior

Posted 01 November 2012 - 06:29 AM

You've been out of the loop...it's been bad since 1968:

http://www.u.arizona...ed_Harmful.html

Here's a slightly more modern discussion:

http://stackoverflow...sidered-harmful

The general consensus is, don't use goto. If you find yourself needing goto, you probably need to reengineer something.
Was This Post Helpful? 0
  • +
  • -

#6 Momerath  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1010
  • View blog
  • Posts: 2,444
  • Joined: 04-October 09

Re: Strange execution time behavior

Posted 01 November 2012 - 05:11 PM

There was an article published after the 1968 one (which I can't find) pointing out certain program constructs that become confusing without using GOTO.

The question you should ask yourself: If goto is so bad, why did they include it in the C# language?
Was This Post Helpful? 0
  • +
  • -

#7 Curtis Rutland  Icon User is online

  • (╯□)╯︵ (~ .o.)~
  • member icon


Reputation: 4464
  • View blog
  • Posts: 7,780
  • Joined: 08-June 10

Re: Strange execution time behavior

Posted 01 November 2012 - 09:40 PM

I believe that the reason the designers left goto in was to allow a behavior like falling through in switch statements, since cases are also labels.

The MSDN also lists an example of breaking out of a deeply nested series of if statements. I prefer Java's approach here, using a labeled break statement.

However, I've yet to see a non-trivial example where goto actually simplifies code. One that can't be refactored so that it is still as readable without the goto. Everyone shows the nested ifs, but I say you can change the design to not rely on deep nesting. That's a bad design in the first place.
Was This Post Helpful? 0
  • +
  • -

#8 lucky3  Icon User is offline

  • Friend lucky3 As IHelpable
  • member icon

Reputation: 231
  • View blog
  • Posts: 765
  • Joined: 19-October 11

Re: Strange execution time behavior

Posted 04 November 2012 - 01:09 AM

I actually used goto recently, and I think it was "justified" (as far as goto can be). I was calculating planets' positions at given time, and was working on procedures from internet source. As Pluto is no longer a planet, calculations for it, wasn't available at that source.

Later I found out that I'd need to calculate Pluto's positions, too. So I've searched for another internet source, and implemented those calculations in the same function, as for other planets. Methods for Pluto, differed, let's say, in the first 1/3 of the procedure.

I could re-factor my original function, and call one method for other planets' calculations, and other for Pluto's, return results to this common function, and continue with the rest 2/3 of this original function with returned data. I could avoid goto here, but I didn't do it, because this would mean just sending the same variables to one or another function, and then retrieve back calculated values, just to use them further. I went with if block for Pluto, using same variables from this common function, and point it with goto to the last 2/3 of the function, skipping first 1/3, where calculations for other planets are done.

For me, at this particular case, using goto was justified, although I share common opinion on not using it.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1