Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Why so slow processing time?


  • Please log in to reply
11 replies to this topic

#1 Klop

Klop

    Advanced Member

  • Members
  • PipPipPip
  • 49 posts

Posted 07 June 2011 - 02:40 PM

Hi,

Why does this simple piece of code take approx 1 second to execute for each while loop?

public static void Main()
{
	while (true)
	{
		byte result = 0;
		led.Write(true);
		for (int i = 0; i < 20000; i++)
		{
			result += 1;
		}
		led.Write(false);
		for (int i = 0; i < 2000; i++)
		{
			// Blink...
		}
	}
}

At 48 Mhz this results in 2.400 assembly cycles (20000 * 2400 = 48M) to do: result += 1; This does not make sense at all for me.

Am I missing something? Or does the Netduino framework really take so much overhead? That can be true can it. Or is it the debugging feature that messes it up - can it be disabled/removed?

Please can anyone help me out here.

Thanks.

#2 Ravenheart

Ravenheart

    Member

  • Members
  • PipPip
  • 18 posts
  • LocationBulgaria

Posted 07 June 2011 - 02:49 PM

By the looks of your code you seem to be trying to pause the thread for some time in order to "blink", if what you are doing is that then the way you do it totally wrong and you should instead look at the Thread.Sleep() method.

#3 Klop

Klop

    Advanced Member

  • Members
  • PipPipPip
  • 49 posts

Posted 07 June 2011 - 03:17 PM

By the looks of your code you seem to be trying to pause the thread for some time in order to "blink", if what you are doing is that then the way you do it totally wrong and you should instead look at the Thread.Sleep() method.

I'm doing this on purpose just to get a small blink and with this match approx one second for the entire while loop.
20000 loops just adding 1 to result should not take approx one second. The led should not even blink - it should go so fast that the led would be on the entire time.

#4 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 07 June 2011 - 03:41 PM

The C# code is compiled in an portable assembly called Intermediate Language (IL). In this way the IL can be guaranteed to work exactly in the same manner on any platform, CPUs, etc. On PCs, where the RAM and CPUs are enough, there is a background process called JIT-compiler: JIT means "Just-In-Time". You don't notice all that, but that "JITter" translates the IL to CPU-specific opcodes. The result is an execution often faster as the equivalent C++ compilation, but with all the C# features and benefits included. For tiny platforms like the Micro Framework, where the RAM is maybe a dozen KB, there are no enough rooms for a JITter. So a board like Netduino, operates intepreting the IL on the fly. The "long" time that a simple accumulation takes over 20K cycles is normal. Hope it helps. Cheers
Biggest fault of Netduino? It runs by electricity.

#5 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 07 June 2011 - 05:10 PM

Also, pay attention to the kind of loop you're using. Watch the difference:

public static void Main()
{
    byte bresult = 0;
    int iresult = 0;

    Debug.Print(Utility.GetMachineTime().Ticks.ToString());
    for (int i = 0; i < 20000; i++) { bresult += 1; }
    Debug.Print(Utility.GetMachineTime().Ticks.ToString());
    for (int i = 0; i < 20000; i++) { /* nothing */ }
    Debug.Print(Utility.GetMachineTime().Ticks.ToString());
    for (int i = 0; i < 20000; i++) { iresult += 1; }
    Debug.Print(Utility.GetMachineTime().Ticks.ToString());
    for (int i = 0; i < 20000; i++) { ++iresult; }
    Debug.Print(Utility.GetMachineTime().Ticks.ToString());
}

Runned it a couple of times, output:

1436254933
1448545280 (difference: 12290347)
1456158720 (difference: 7613440)
1466142720 (difference: 9984000)
1476114133 (difference: 9971413)

2131536426
2144333013 (difference: 12796587)
2151945600 (difference: 7612587)
2161930026 (difference: 9984426)
2171901226 (difference: 9971200)

2337301760
2349823573 (difference: 12521813)
2357433813 (difference: 7610240)
2367418666 (difference: 9984853)
2377390080 (difference: 9971414)


The numbers are quite consistent.
This shows that incrementing with a byte consumes much more cycles then with an int. Could be because the range of a byte is exceeded many times. or because a byte is 8 bit and the system is 32-bit like the integer. I'm not sure what the difference exactly is. There is also a difference in performance beteen Value +=1 and ++Value.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#6 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 07 June 2011 - 06:08 PM

There is also a difference in performance beteen Value +=1 and ++Value.

This is usually where the compiler modus operandi comes into play. As you are compiling in debug mode the usual way for compilers to work is not to optimise. So a ++value can get compiled to a register increment followed by a save to memory. Compare this to value += 1 where the compiler will compile this to an add instruction followed by a save to memory. With optimisation the compiler may realise that value +=1 is a special case and convert this to in increment whilst value += 100 is converted to an add instruction.

Sorry - the former compiler writer in me surfaces.

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#7 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 07 June 2011 - 06:48 PM

There is also a difference in performance beteen Value +=1 and ++Value.

Stefan, have you measured the performance of Release build?

#8 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 07 June 2011 - 08:00 PM

Stefan, have you measured the performance of Release build?

just while debugging in visual studio. but it was to make a point that a lot of different approaches can give a lot of different results ;)
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#9 Klop

Klop

    Advanced Member

  • Members
  • PipPipPip
  • 49 posts

Posted 07 June 2011 - 09:40 PM

So if I want it to perform better I need to write c or c++ code for my time consuming operations? Thats the only way right? Does a guide exist for writing your own c or c++ code and compiling it into a project in visual studio? Or how do you do it?

#10 ItsDan

ItsDan

    Advanced Member

  • Members
  • PipPipPip
  • 101 posts

Posted 07 June 2011 - 10:28 PM

You really shouldn't draw those kinds of conclusions from test cases. Write a routine that does something useful and see what kind of results you get.
Follow the adventures of the Box of Crappy Surplus

Total BOCS Traveled Distance: 9708 miles | States Visited: 5
Track the Box

#11 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 08 June 2011 - 06:45 AM

So if I want it to perform better I need to write c or c++ code for my time consuming operations? Thats the only way right?

Sometimes just looking at the code and writing it in a different way is all that's needed. Also, a piece of code which is not the fastest it could be, may be fast enough for what you want it to do.

As Dan says, do it and see if it is good enough.

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#12 Klop

Klop

    Advanced Member

  • Members
  • PipPipPip
  • 49 posts

Posted 08 June 2011 - 08:43 AM

Sometimes just looking at the code and writing it in a different way is all that's needed. Also, a piece of code which is not the fastest it could be, may be fast enough for what you want it to do.

As Dan says, do it and see if it is good enough.

Regards,
Mark

I already have written a code block which is optimized by only doing multiplication and shifting and runs in a small for loop. It is this code block that runs to slow which I couldn't understand - therefore I did the simple loop test to test the netduino performance/speed.

So I believe I need to write my code block in native code in order to get the right performance/speed. But how do I do that - how do I link c or c++ code with the firmware build? That's how you would do it right?

Can anyone help me with a small tutorial or guide.

Thanks.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.