Hmm he has published the code generated00B01003 83 EC 08 sub esp,8
00B01006 53 push ebx
int x = 0;unsigned int uTicks = timeGetTime();
00B01007 8B 1D E8 20 B0 00 mov ebx,dword ptr ds:
[00B020E8h]
00B0100D 56 push esi
00B0100E FF D3 call ebxfor( int i=0;i< 30000000; i++)
00B01010 8B F7 mov esi,edi
00B01012 89 45 FC mov dword ptr[ebp-4],eax
00B01015 69 F6 80 C3 C9 01 imul esi,esi,1C9C380h
{
x = x + param1;
}for( int i=0;i< 30000000; i++)
00B0101B B8 80 C3 C9 01 mov eax,1C9C380h
{
x = x - param1;
00B01020 2B F7 sub esi,edi
00B01022 48 dec eax
00B01023 75 FB jne 00B01020
}Is the first loop optimized by the compiler with a single
multiplication. Or i am getting it wrong ????
It could look like it.
Arne
The original premise seems to be that OpenQuant is slow because it wasSo not only is the person relying on a test that demonstrates nothing
useful, he cannot even interpret it correctly. I'd say even a
relatively stupid compiler is probably smarter than that guy.
To compound the problem, he has an irrational bias against .NET (and it
appears, Java). He claims .NET is useless for computationally intensive
code. But there are far too many people using .NET (and Java) for
exactly that sort of thing for that claim to be true. In fact, I'm
currently involved in a project that is almost entirely numerical
computations and data processing, and almost all of the code involved is
.NET/C# code.
As does a compiled C# program. The "principle that it doesn't run
natively" is completely false, for both C# and for C/C++.
That's just not true. A C# program has to be interpreted/JIT'd whatever
you want to call it before it can run.
Jeff said:That's just not true. A C# program has to be interpreted/JIT'd whatever
you want to call it before it can run.
A compiled C program (assuming it's statically linked to its libraries)
just runs.
If you don't start timing the program until after it has been compiled and
loaded and is running, then what difference can it make whether it was
compiled 10 milliseconds before it was loaded or 10 months before?
That makes as much sense as "apple pie/pickup truck or whatever
you want to call it".
Interpreted and JIT compiled are very different.
Indeed.Interesting how people are willing to argue about terminology but
unable to face the fact that NET programs can be very slow to start.
Indeed. Any timing should start when the program starts or you will get
entirely false results.
Jeff said:Indeed. Any timing should start when the program starts or you will get
entirely false results.
In the case at hand it does.
Therefore, since any overheads of JIT
compiling or loading of the assembly have already been incurred before
the program (and its timer) starts, they cannot legitimately be used to
explain differences in the timing.
In some respects, compilers are often much "smarter" than the programmer
using them. A compiler incorporates a wealth of very specific, esoteric
information regarding the target architecture, such as instruction
timings, pipeline optimizations, CPU modules, etc. never mind features
that detect common, easily-optimized patterns and transform the code to
take advantage of those.
It's one of the main reasons that coding something in assembly isn't
really all that good a way to optimize code any more. CPUs are far more
complicated than the days of Mel, and there are a handful of people at
best who could actually write better assembly code than a compiler can.
And frankly, I doubt _any_ of those people can do so while still
producing working, correct code anywhere close to as quickly as someone
using a higher-level language.
To compound the problem, he has an irrational bias against .NET (and it
appears, Java). He claims .NET is useless for computationally intensive
code. But there are far too many people using .NET (and Java) for
exactly that sort of thing for that claim to be true. In fact, I'm
currently involved in a project that is almost entirely numerical
computations and data processing, and almost all of the code involved is
.NET/C# code.
C# programs are JIT-compiled. But the "JIT" in "JIT-compiled" refers only
to the time at which the program is compiled. That is, "just-in-time".
It's exactly the same as compiling a C/C++ program, except for when the
compilation happens.
Actually, no. It depends on what you are trying to compare. For the vast
majority of applications, startup time is completely irrelevant. It would
be stupid to measure it.
Again, it depends on what you're measuring. If every time the program is
used, it happens on a freshly booted PC, then sure. You would probably
want to measure that.
But that's almost never the case, and so the performance under that
scenario is irrelevant. And again, measuring performance under that
scenario (or any irrelevant scenario) would be stupid.
[...]One of the biggest
complaints about NET that comes up in news groups and forums is the slow
start up of programs.
Right. That's why we see posts complaining about that here in this
newsgroup all the time. Oh, wait. Those posts don't exist.
In any case, none of this has anything to do with your false claim that C#
is interpreted.
[...]One of the biggest
complaints about NET that comes up in news groups and forums is the slow
start up of programs.
Right. That's why we see posts complaining about that here in this
newsgroup all the time. Oh, wait. Those posts don't exist.
You may not be aware that there are other programming related news group
in existence perhaps? There are also many web based forums as well.
Exactly. So any meaningful test needs timing with a stop watch from the
time the program is started by double clicking or whatever.
The NET
program will always be slower because of the JIT overhead.
And for a
real world comparison the PC should be freshly booted between tests
because there is some sort of additional overhead what seems to be NET
components loading.
That was a terminology issue that I have corrected several times in this
thread.