Main Site Documentation

Missing tecnical data (max speed)


#1

Before buying a hardware I try to get as much info about a product as I can.
The information on the GHI and TinyClr sites is quite good.

But one very important information is missing:
What speed do I get using a FEZ board ?
72 MHz sounds very fast.
But I was surprised that outputting an alternating 0 and 1 via .NET code was so slow!
I got only 10 kHz.
Additionally there was a strong jitter.

What is missing in the tecnical data and in the beginners tutorial is
– what speed can I get via .NET code ?
– what speed can I get via native code ?
– how much is the jitter ?

Could you please add this information to your site ?

Elmü


#2

Your questions do not have definite answer and this is why you do not see them anywhere. I suggest you take a look here as it will make it a bit clearer for you http://tinyclr.com/faq/

What speed do I get using a FEZ board ?
As in what? Datalogger, sure no problem.

72 MHz sounds very fast.
But I was surprised that outputting an alternating 0 and 1 via .NET code was so slow!
I got only 10 kHz.
Yes this is expected. This si a very bad test to determine speed. See http://tinyclr.com/faq/
Try RLP if you need much higher speeds

Additionally there was a strong jitter. Yes this is expected. This is managed system and not real time, try RLP if you need real time

What is missing in the tecnical data and in the beginners tutorial is
– what speed can I get via .NET code ?
How can this be answered? I mean it is measured in what units?

– what speed can I get via native code ?
Again, in what units?

– how much is the jitter ?
Undetermined in native code. In RLP it can be realtime.


#3

In the MF version of .NET the compiled code is interpeted, not converted to machine code with a JIT compiler at run time.

Further, .NET MF when writting manged code is not real-time. Every one in a while garbage collection runs which will introduce jitter.

Runtime Loadable Procedures(RLP), which are compiled C code, can be use to get the maximum speed out of the processor, and near real-time performance.

But, if all you wanted to do is toggle a bit in mananged code (c#) you did not do it in the most efficient manner. There several other alternatives which can be discovered in the free ebooks published by GHI.

“What speed” questions are very difficult to answer. What are trying to do? What units should the answer be in? Is faster than a speeding bullet acceptable?

The same can be said for ?How much jitter". How much drift constitutes jitter? Again .NET MF is not real-time.

.NET MF is not for every solution. If you have a specific application in mind, tell us about it and then you can get a more informative answer.


#4

Good answer Gus ;D

BTW, do you know how high is up?


#5

Hello

I completely understand your answers.
And yes, I knew that managed code eats up much of the time.
But how much ?

From a 72 MHz processor I would have expected more speed.

Obvioulsy a speed determination must be connected to a code sample.

This could be like the beginners tutorial (which is very good) saying:

The following loop outputs a 10 kHz square wave signal with a 20 us jitter for 10 seconds on a FEZ domino:

for (int i=0; i<100000; i++)
{
     i_Out.Write(!i_Out.Read());
}

So people can have an idea in what range the speed of managed code is to be expected.
I would have expected 1 MHz !

Another sample should show a code and the resulting speed for native code.


#6

The problem is, noone would go about creating a 10kHz square wave using your method. The OutputCompare class is what you’re looking for, and you can create square waves of much higher frequencies than 10kHz, all while using much less CPU resources.


#7

I think what Elmue is trying to say is that doing a square wave in a loop like he showed gives a realistic view of how long the whole interpreted process takes on that given processor.


#8

Doing a square wave in a loop doesn’t show anything except how fast square-waves-in-loops run. The FEZ platform gives us lots of options for doing things differently (and faster!) than we might on another microcontroller. The interpreted nature of the platform does indeed come at a performance penalty, but the only way to tell what that is is to try it on your particular workload.

The .NETMF SDK comes with an emulator, maybe it would be helpful to try some things in there?


#9

[quote]So people can have an idea in what range the speed of managed code is to be expected.
[/quote]

Again, how would you like the speed expressed?

From my experience, managed code speed ranges from slow to very fast, depending upon what I am doing. Does that help?


#10

Not so. It shows you more than that. It shows you how fast/slow the interpreted process can take on things. For example, i can do that same loop in my ARM compiler and see that it will output a square wave far faster then doing it in .netmf. So by doing it in the way explained you can get a idea of how the .netmf will slow down the overall process in general.

I will but out now and let you guys handle it :wink:


#11

[quote]I think what Elmue is trying to say is that doing a square wave in a loop like he showed gives a realistic view of how long the whole interpreted process takes on that given processor.
[/quote]

He was able to show that he could read an output port 10,000 times a second and write it 10,000 times a second. That is 20, 000 operations a second. Is that fast or slow?

Of course, he could almost double the speed by one line of code. Would that make it faster?

Speed questions are always best answered within a context.


#12

Very true, but again, that only tells you the overhead for that particular operation. The problem is that there is no constant overhead. You can’t just flat-out say, “managed code will run at x% the speed that compiled code would run”. It depends on a LOT of variables.

The only way to know is to benchmark your particular algorithm/circumstances. If things seem to be too slow for you, that’s what Gus, Joe, and the rest of the FEZ community is here for. There is an enormous amount of knowledge housed in this community.


#13

I agree, at the same time its nice to get some basic idea. Much like when working with the LCD. I know how long it takes for me to fill the screen red, then green, then blue using C and my arm compiler.
Once could then do this using .net and compare the speed if its fast enough for the given project at hand.
Doing this will show if the current processor is fast enough to do what we want or we need to move up to the ChipworkX Module.


#14

[quote]The only way to know is to benchmark your particular algorithm/circumstances. If things seem to be too slow for you, that’s what Gus, Joe, and the rest of the FEZ community is here for. There is an enormous amount of knowledge housed in this community.
[/quote]
:clap: :clap: :clap: :clap:


#15

Hello jdal

At least you understood my point.

When one runs a Benchmark program on his PC he gets the result of let’s say 10 million read operations on the harddisk or 10 million floating point calculations. Then you know how fast is your entire system (CPU, RAM, PCI bus, harddisk, …)
But you don’t get much information of how fast that same harddsik or CPU would be in another computer.

That is a characteristic of all benchmarks.

And obviously the same applies for FEZ.
The above code gives AN IDEA of the speed.
And that is all I intended to get.

AN IDEA of the speed of a simple endless loop.

Does it run 10.000 times in a second or 1.000.000 times ?
That’s all.

All the discussion about outputting a square wave in a better way is missing the point.

That is 20, 000 operations a second. Is that fast or slow?

A car runs a maximum of 190 km/hour.
Is that fast ?

The question is not, if 190 km/h is fast.
The point is simply that THIS car runs a maximum of 190 km / h.
Not more and not less.

Elmü


#16

Like I said, this is a bad way to determine speed. Why? Because most of your code is running on the native side. For example, when you call File.Write, you are only running very little code in C# (managed) but then there are thousands of lines that does this on native side (C++).

If I tell you a look is 10K then you will think NEMTF is very slow but then if you test file access speed and it is 200KBytes/sec then it is not slow. It depends on what you are doing.

Normally, applications have 80% of execution done in native side. So, the interpreter speed is only 20% of the time. So toggling a pin is a theoretical test of the slowest possible performance you can get with NETMF. Of course there are built in services that help you with toggling a pin if this is what you need.

IIRC, this is all explained in http://tinyclr.com/faq/


#17

[quote]At least you understood my point.
[/quote]

In another life, I spent five years evaulating the performance of mainframe computers for a major oil company.Among the techniques we used for comparing multiple systems was a set of “standardized” benchmarks for our typical processing loads. We had comparison within a meaningful context.

We were using IBM computers at that time, and in my 15 years of working with IBM equipment I never saw IBM publish a list of general performance numbers.

Today, I have never seen Apple, HP or Dell publish such lists.

I have posted several performance analyses I have done on the FEZ equipment in the past. All were done within a context. For example, TCP/IP rates.

Elmue, if you think it is important to have these numbers, perhaps you should develop a list of performance criteria, how to obtain the numbers and in what units they should be expressed. You can then run the tests and publish them so other with similar questions can profit from your contribution.


#18

And you’re not likely to. Most vendors I deal with have it in their fine print that users are not permitted to publish such results. The problem is that there are entirely too many variables and configurations specific to each platform that have to be tweaked in order to get a true apples-to-apples comparison. I don’t suspect GHI has this type of fine print but you should always verify with the vendor before publishing.


#19

[quote] I don’t suspect GHI has this type of fine print but you should always verify with the vendor before publishing.
[/quote]

It is not fine print!! When you ask how fast is NETMF you are not understating the system. There are many variables and there is NO ANSWER :slight_smile:

native vs interpreted is same as apples vs oranges, even worse, NETMF is managed and native together and depending on your app;cation you maybe using more more than the other!!! So trust me there is NO ANSWER :slight_smile:


#20

Hello

So toggling a pin is a theoretical test of the slowest possible performance you can get with NETMF

Perfect !!

if you test file access speed and it is 200KBytes/sec then it is not slow

Perfect !!

These two examples are very good.
So a benchmark result would be:

Toggling a pin in .NET: 10.000 / second (with code sample)
Toggling a pin in native code: 100.000 / second (with code sample)
File access: 200.000 / second (with code sample)

Jitter toggling a pin in .NET: 20 us
Jitter toggling a pin in native code: 2 us
Jitter using OutputCompare: 1 us

I would be perfectly pleased with these benchmarks.
Obviously there should be some more.
These are just some examples.
The examples should include worst case and best case whenever possible.

And yes:
If I modify only ONE line of the sample code there will be other results.
I know that.
But I have an IDEA of the speed of THIS specific sample code.

If the car has to climb a hill it will be solwer than 190 km / h.
If the car is running down a hill it will be faster than 190 km / h.
But that’s not the point.

Elmü