P
pamela fluente
i think that more precisely the assembly is something like:
x = param1;
x = x * 30000000;
to be fair, we should compare programs using in both the 1
multiplication for the first loop.
Does the timing improve ?
Pam
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
i think that more precisely the assembly is something like:
x = param1;
x = x * 30000000;
to be fair, we should compare programs using in both the 1
multiplication for the first loop.
Does the timing improve ?
Pam
R
Registered User
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.
developed with C# and VB.NET. The various measures of fact are amusing
considering the forum's concern is predictive analysis.
regards
A.G.
J
Jeff Gaines
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.
A compiled C program (assuming it's statically linked to its libraries)
just runs.
A
Arne Vajhøj
That's just not true. A C# program has to be interpreted/JIT'd whatever
you want to call it before it can run.
That makes as much sense as "apple pie/pickup truck or whatever
you want to call it".
Interpreted and JIT compiled are very different.
Arne
R
Rick Lones
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?
J
Jeff Gaines
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?
Indeed. Any timing should start when the program starts or you will get
entirely false results.
J
Jeff Gaines
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.
A
Arne Vajhøj
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.
I don't think anyone is not willing to face that JIT and certain
other CLR startup things do cost something.
That does not change that your claim about .NET being interpreted
is just flat out wrong.
And that is what we have been trying to communicate to you.
And the startup time is completely irrelevant for the discussion
that started this thread.
Arne
A
Arne Vajhøj
Indeed. Any timing should start when the program starts or you will get
entirely false results.
That depends on what the intention is to measure.
Arne
R
Rick Lones
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. And just to repeat one more time what everyone else has been saying:
The timer IS measuring fully-compiled native code by the time it starts.
That's not to say that this particular contrived example amounts to a meaningful
benchmark for anything. It is poorly conceived and poorly implemented.
-rick-
A
Arne Vajhøj
In the case at hand it does.
I don't think so. At least when an outer loop was added to
give stable results, then the JIT'ing of two methods is
insignificant.
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.
I don't think anybody did that.
Arne
A
Arne Vajhøj
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.
It is not that difficult.
Among other tricks it is possible to see what the compiler
generates and try to improve on that.
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.
Of course not.
They could not do that 25 years ago either.
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.
True scientific number crunching (LINPACK, BLAS, Top500 style) is still
dominated by Fortran and C.
But there are also some types of business apps that are very
CPU intensive. Like parsing SOAP XML. And that is an area
where .NET and Java is dominating.
Arne
J
Jeff Gaines
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.
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.
J
Jeff Gaines
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.
We'll have to disagree substantially there, for most users start up time
is an important measurement.
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.
Again I disagree, and so would most users I suspect. One of the biggest
complaints about NET that comes up in news groups and forums is the slow
start up of programs.
J
Jeff Gaines
[...]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.
In any case, none of this has anything to do with your false claim that C#
is interpreted.
That was a terminology issue that I have corrected several times in this
thread.
I think it's quite sad that somebody as knowledgeable as you, who commits
so much time to this group, seems willing to defend NET as it it were his
daughter's virginity. NET, the VS IDE and C# are excellent tools but there
are some issues and you ought to be able to face them.
A
Arne Vajhøj
[...]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.
Please refer us to a dozen of these complaints in various
foras.
Arne
A
Arne Vajhøj
Exactly. So any meaningful test needs timing with a stop watch from the
time the program is started by double clicking or whatever.
No.
Only if you are interested in testing startup time.
The NET
program will always be slower because of the JIT overhead.
If that was the case, then people always use ngen.
They don't. Because the JIT overhead does not matter.
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 is the same for native programs. Most of them are just
smaller.
Arne
A
Arne Vajhøj
That was a terminology issue that I have corrected several times in this
thread.
This is a computer related group.
It is expected that people understands the difference between
compiled and interpreted.
So when you confuses the two then expect to be corrected,
even though is is just terminology.
Arne
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.