Here's my FFT results. I'm not sure how to interpret the output. I have to head to work. I'll look closer at the source later today.
I haven't looked at the code but something is definetly a miss between them. The timer frequency is way off and the ending run times are orders of magnitude off.
Your results for Linux box (AMD Sempron 2200, 1.5GiB) look quite reasonable. Notice that the guts of the FFT gets run and timed ten times. Your later runs are approx 375us which sounds about right comparing to my box (see below).
Notice that the first run is much longer 1541us. This is also what I am seeing.
Your results for Windows (Intel Quad Core 2.4GHz, 4GiB) are all screwy. That's a fault of my timing code. Thing is you have a high resolution counter going at 2.4GHz which stuffs up the calculations with a resolution of less than a nanosecond.
Attached is another version of fft_bench with soem changes in the timing to fix that. Also I've neatened up the output.
Here is what I get out of my Linux Intel Core2 Duo CPU which seems to have a CPU clock of 2GHz:
fft_bench v2.0
1024 point bit-reversal and butterfly
Operations timed using the system's high-resolution performance counter.
Timer frequency in ticks per second = 10000000
Timer is accurate within 100000 picoseconds
Run 1: time = 395 us
Run 2: time = 116 us
Run 3: time = 116 us
Run 4: time = 116 us
Run 5: time = 116 us
Run 6: time = 116 us
Run 7: time = 116 us
Run 8: time = 116 us
Run 9: time = 116 us
Run 10: time = 116 us
Results:
Freq. Magnitude
0 510
192 511
320 511
512 511
Expected:
Freq. Magnitude
0 510
192 511
320 511
512 511
Notice that the first run is nearly four times longer than the others as mono sorts things out on the first pass through the code, probably JITing away and allocating memory etc.
Now we do some Ahead Of Time Compilation (AOT) with:
mono --aot -O=all fft_bench.exe
And this is what I get:
fft_bench v2.0
1024 point bit-reversal and butterfly
Operations timed using the system's high-resolution performance counter.
Timer frequency in ticks per second = 10000000
Timer is accurate within 100000 picoseconds
Run 1: time = 158 us
Run 2: time = 153 us
Run 3: time = 152 us
Run 4: time = 152 us
Run 5: time = 152 us
Run 6: time = 152 us
Run 7: time = 152 us
Run 8: time = 152 us
Run 9: time = 152 us
Run 10: time = 152 us
Results:
Freq. Magnitude
0 510
192 511
320 511
512 511
Expected:
Freq. Magnitude
0 510
192 511
320 511
512 511
Notice that the first run through is now much the same time as the later runs. No more JITing going on. But strangely the overall execution speed is slower! Very Odd.
So this AOT business works well for a one shot program or to make it look like a big GUI app is responding faster when you start it. But not so good for long running services.
Well I know nothing of GAC or verifying assemblies. But seems to me that if the verification involves some long winded parsing at start up that should not affect the timing measurements I am taking here. Thing is I'm using the "Stopwatch" to time the guts of the FFT ten times in one run of the program ,and I would expect any verification to be done before we get to our first timing run.
As we see mono AOT is faster on start up but then settles down to be slower. Curious.
I can guess that during the first run through with JIT it is actually compiling the decimate and butterfly methods whic it does not have to do on subsequent iterations.
So AOT should be expected to remove that start up lag. But what about afterwards?
Here is the result on MS Windows XP SP3 of fft_bench as you provided it. The first one is the release version.
fft_bench v2.0
1024 point bit-reversal and butterfly
Operations timed using the system's high-resolution performance counter.
Timer frequency in ticks per second = 3579545
Timer is accurate within 279365 picoseconds
Run 1: time = 4467 us
Run 2: time = 179 us
Run 3: time = 179 us
Run 4: time = 179 us
Run 5: time = 179 us
Run 6: time = 179 us
Run 7: time = 179 us
Run 8: time = 179 us
Run 9: time = 179 us
Run 10: time = 179 us
Results:
Freq. Magnitude
0 510
192 511
320 511
512 511
Expected:
Freq. Magnitude
0 510
192 511
320 511
512 511
Here is the debug version on the same OS
fft_bench v2.0
1024 point bit-reversal and butterfly
Run 1: time = 664 us
Run 2: time = 65 us
Run 3: time = 64 us
Run 4: time = 64 us
Run 5: time = 64 us
Run 6: time = 64 us
Run 7: time = 64 us
Run 8: time = 64 us
Run 9: time = 64 us
Run 10: time = 64 us
Results:
Freq. Magnitude
0 510
192 511
320 511
512 511
Expected:
Freq. Magnitude
0 510
192 511
320 511
512 511
Operations timed using the system's high-resolution performance counter.
Timer frequency in ticks per second = 3579545
Timer is accurate within 279 nanoseconds
Debug version as you compiled it seems to be ~twice as fast. I'll try this out after compiling myself if you want... let me know
That' does not look right. That Debug executable is not up to sate with the source code.
There are some TABs missing from the Release version output.
Suggest you re-compile and replace those results in the last post.
I have never seen any difference in speed going from Debug to Release with mono.
Ah yes. I forgot to mention. When I run a normal (no AOT) build, Debug or Release, the initial run time is much larger when running under the monodevelop IDE than it is when running straight from the command line.
Here it is recompiled using VS 2008 Express, I didnt use gac utils yet.
Debug
fft_bench v2.0
1024 point bit-reversal and butterfly
Operations timed using the system's high-resolution performance counter.
Timer frequency in ticks per second = 3579545
Timer is accurate within 279365 picoseconds
Run 1: time = 1235 us
Run 2: time = 313 us
Run 3: time = 313 us
Run 4: time = 313 us
Run 5: time = 314 us
Run 6: time = 313 us
Run 7: time = 313 us
Run 8: time = 313 us
Run 9: time = 313 us
Run 10: time = 314 us
Results:
Freq. Magnitude
0 510
192 511
320 511
512 511
Expected:
Freq. Magnitude
0 510
192 511
320 511
512 511
and here is the release version
fft_bench v2.0
1024 point bit-reversal and butterfly
Operations timed using the system's high-resolution performance counter.
Timer frequency in ticks per second = 3579545
Timer is accurate within 279365 picoseconds
Run 1: time = 1902 us
Run 2: time = 203 us
Run 3: time = 202 us
Run 4: time = 202 us
Run 5: time = 202 us
Run 6: time = 201 us
Run 7: time = 201 us
Run 8: time = 201 us
Run 9: time = 201 us
Run 10: time = 201 us
Results:
Freq. Magnitude
0 510
192 511
320 511
512 511
Expected:
Freq. Magnitude
0 510
192 511
320 511
512 511
OK, looks like the fft_bench in C# is fit to include with it's peers in the fft_bench suite.
What have we proved, I'm not sure.
C# turns out to be 60 to 100 percent slower for this fft than the equivalent C.
We can drive serial ports from it.
The language itself is pretty cool.
Monodevelop is a breeze to use.
On a personal level, now I'm goofing around with Linux Mint and a cross platform development. Just needed a reason I guess. I'd really like to be a part of the GCC / Eclipse and Propeller 2 development... never received an email though.
There are some interesting points raised there re: the JIT being able to make best use of your particular CPU. Still raw speed is not the be all and end all of programming.
In my quest for cross platform programming I have been promoting C++ and Qt. So I guess it's time for me to do some comparisons between the two.
Also I have to see how well this goes on my ARM boards running Ubuntu.
Still raw speed is not the be all and end all of programming.
It certainly isn't with M$. I loved this quote: "Microsoft does not recommend using C# for time-critical applications." I assume they are include their operating systems in the "time-critical application" category. This would explain a lot. I've just installed Windows 7 on a new dual core 3G 64 bit intel processor, and when I listen closely I can hear the CPUs sobbing in frustration.
Yes, I know. After purchasing Windows 2.0, 3.0, 3.1, 3.11, 98, NT3, NT4, XP, 2000, 2003 etc etc etc I swore I would never again be stupid enough to purchase yet another M$ Operating system that was (perhaps excluding 2.0!) both slower and less user friendly than the previous one.
But I relented since a few people seem to have Catalina issues on Windows 7 which I have been unable to fix remotely. It seems there are a few (understatement of the decade?) oddities with Windows 7.
C# is great for people who like it So is Forth for people who like that. So is C, Pascal, PHP, PERL, Java, BASIC, etc ....
I'm slow getting Propalyzer sources to post because I had to rebuild it from a .exe assembly. It's almost ready to go, but I want to do some sanity checks. Time is short right now, so be patient. Propalyzer will be released as fully open source - the comments I had are gone because of reverse engineering the .exe. Sorry about that. Maybe someone would have time to add some protocol decoders in the open-sourced Propalyzer later.
Thanks to everyone for remaining on topic in this thread.
Heater,
You are thinking of the Netduino ( http://netduino.com/ ), they have a board that can be programmed using the .NET Micro framework. (C#, etc.) They use an Atmel chip that is Arm7 based. The base one is $35, and there is another one with Ethernet built in for $60.
RossH,
The OS is not written in C#. Also, that statement is more about applications that require critical timing, and thus would be messed up by a garbage collection stall, or similar. The same is true for any of the higher level languages that use garbage collection and what not.
Actually it was the FEZ boards that I remember seeing before.
Those sites talk about "open source" for their designs.
Does that include the .NET run time?
Can they be used from mono some how?
Yes, Microsoft released the .NET Micro Framework under the Apache 2.0 open license. You can find it here: http://www.netmf.com Several years ago (10 or so) we also released "Rotor" which was the initial "Shared Source" code to the .NET Framework CLI and C#. That was the original basis for Mono.
There is this description and license page from Fedora.http://fedoraproject.org/wiki/Licensing/Microsoft_Shared_Source_License
This is not "Open Source" at all. It includes non-commercial use clauses and other restrictions.
Given that mono is released under the GPL and other open source licenses I don't see how any of it can be based on Rotor.
In fact whilst googling around I found this statement regarding the situation:
People that are interested in continuing to contribute to Mono, or that are considering contributing to Mono's open source implementation of those class libraries should not look at this upcoming source code release.
C# Programming for those who like .net and/or mono
I keep seeing this thread rise. The tittle is a contradiction in terms in and of it self, translated to spoken English it reads 'Unusable Form of OO C Programming for Those Who Do NOT Like Programming'.
As such I can not see any reason that all these intelligent Propeller users are responding to this thread (yes now I am guilty).
I'm still undecided. C# seems to be quite usable, as much as Java or Python etc. There might be a question mark over performance but that is a hit we take with many languages, Java, Python, PHP, JavaScript etc etc. Perhaps not quite up to snuff for small embedded systems. It does offer cross platform support so I quite like it.
I dare say that c#/.net built programs will work for the larger majority (compared to others) of ignorant end users using windows, regardless of what computer they use. (cover my head here)
Comments
I haven't looked at the code but something is definetly a miss between them. The timer frequency is way off and the ending run times are orders of magnitude off.
Bill
Your results for Linux box (AMD Sempron 2200, 1.5GiB) look quite reasonable. Notice that the guts of the FFT gets run and timed ten times. Your later runs are approx 375us which sounds about right comparing to my box (see below).
Notice that the first run is much longer 1541us. This is also what I am seeing.
Your results for Windows (Intel Quad Core 2.4GHz, 4GiB) are all screwy. That's a fault of my timing code. Thing is you have a high resolution counter going at 2.4GHz which stuffs up the calculations with a resolution of less than a nanosecond.
Attached is another version of fft_bench with soem changes in the timing to fix that. Also I've neatened up the output.
Here is what I get out of my Linux Intel Core2 Duo CPU which seems to have a CPU clock of 2GHz:
Notice that the first run is nearly four times longer than the others as mono sorts things out on the first pass through the code, probably JITing away and allocating memory etc.
Now we do some Ahead Of Time Compilation (AOT) with:
And this is what I get:
Notice that the first run through is now much the same time as the later runs. No more JITing going on. But strangely the overall execution speed is slower! Very Odd.
So this AOT business works well for a one shot program or to make it look like a big GUI app is responding faster when you start it. But not so good for long running services.
Well I know nothing of GAC or verifying assemblies. But seems to me that if the verification involves some long winded parsing at start up that should not affect the timing measurements I am taking here. Thing is I'm using the "Stopwatch" to time the guts of the FFT ten times in one run of the program ,and I would expect any verification to be done before we get to our first timing run.
As we see mono AOT is faster on start up but then settles down to be slower. Curious.
I can guess that during the first run through with JIT it is actually compiling the decimate and butterfly methods whic it does not have to do on subsequent iterations.
So AOT should be expected to remove that start up lag. But what about afterwards?
I'll update that soon with other language and platform versions we have been collecting.
Here is the debug version on the same OS
Debug version as you compiled it seems to be ~twice as fast. I'll try this out after compiling myself if you want... let me know
EDIT: PC is 1.8 Ghz with 1Gb memory
There are some TABs missing from the Release version output.
Suggest you re-compile and replace those results in the last post.
I have never seen any difference in speed going from Debug to Release with mono.
Debug: 321us
Release: 133us
Using Mono there's not much of a difference between debug and release.
Debug
and here is the release version
all were run from the normal command prompt
What have we proved, I'm not sure.
C# turns out to be 60 to 100 percent slower for this fft than the equivalent C.
We can drive serial ports from it.
The language itself is pretty cool.
Monodevelop is a breeze to use.
What next?
I found this short article on Code Project that talks about C/C# performance. The write up is a little easy on C#, The article seems reasonable.
http://www.codeproject.com/KB/cs/CSharpVsCPP.aspx
On a personal level, now I'm goofing around with Linux Mint and a cross platform development. Just needed a reason I guess. I'd really like to be a part of the GCC / Eclipse and Propeller 2 development... never received an email though.
In my quest for cross platform programming I have been promoting C++ and Qt. So I guess it's time for me to do some comparisons between the two.
Also I have to see how well this goes on my ARM boards running Ubuntu.
It certainly isn't with M$. I loved this quote: "Microsoft does not recommend using C# for time-critical applications."
I assume they are include their operating systems in the "time-critical application" category. This would explain a lot. I've just installed Windows 7 on a new dual core 3G 64 bit intel processor, and when I listen closely I can hear the CPUs sobbing in frustration.
Ross.
"Microsoft does not recommend using C# for time-critical applications."
Ha! Yes, I have read that. Well, for once I have to agree with Microsoft.:)
However there is at least one MCU producer who touts .NET as a "good idea". Sorry I don't have a link to those sad people now.
Also Java (same as C# but even crappier) has been proposed as great idea for embedded systems.
Why?
Yes, I know. After purchasing Windows 2.0, 3.0, 3.1, 3.11, 98, NT3, NT4, XP, 2000, 2003 etc etc etc I swore I would never again be stupid enough to purchase yet another M$ Operating system that was (perhaps excluding 2.0!) both slower and less user friendly than the previous one.
But I relented since a few people seem to have Catalina issues on Windows 7 which I have been unable to fix remotely. It seems there are a few (understatement of the decade?) oddities with Windows 7.
Ross.
I'm slow getting Propalyzer sources to post because I had to rebuild it from a .exe assembly. It's almost ready to go, but I want to do some sanity checks. Time is short right now, so be patient. Propalyzer will be released as fully open source - the comments I had are gone because of reverse engineering the .exe. Sorry about that. Maybe someone would have time to add some protocol decoders in the open-sourced Propalyzer later.
Thanks to everyone for remaining on topic in this thread.
You are thinking of the Netduino ( http://netduino.com/ ), they have a board that can be programmed using the .NET Micro framework. (C#, etc.) They use an Atmel chip that is Arm7 based. The base one is $35, and there is another one with Ethernet built in for $60.
RossH,
The OS is not written in C#. Also, that statement is more about applications that require critical timing, and thus would be messed up by a garbage collection stall, or similar. The same is true for any of the higher level languages that use garbage collection and what not.
Those sites talk about "open source" for their designs.
Does that include the .NET run time?
Can they be used from mono some how?
Yes, Microsoft released the .NET Micro Framework under the Apache 2.0 open license. You can find it here: http://www.netmf.com Several years ago (10 or so) we also released "Rotor" which was the initial "Shared Source" code to the .NET Framework CLI and C#. That was the original basis for Mono.
Bill
What is this "shared source" of which you speak?.
There is this description and license page from Fedora.http://fedoraproject.org/wiki/Licensing/Microsoft_Shared_Source_License
This is not "Open Source" at all. It includes non-commercial use clauses and other restrictions.
Given that mono is released under the GPL and other open source licenses I don't see how any of it can be based on Rotor.
In fact whilst googling around I found this statement regarding the situation:
What a mine field!
As such I can not see any reason that all these intelligent Propeller users are responding to this thread (yes now I am guilty).
I'm still undecided. C# seems to be quite usable, as much as Java or Python etc. There might be a question mark over performance but that is a hit we take with many languages, Java, Python, PHP, JavaScript etc etc. Perhaps not quite up to snuff for small embedded systems. It does offer cross platform support so I quite like it.