If not .Net then what?

[spinoza1111]

Scott Roberts said:





Ah, I approve.  

Okay - *at the time*, no, we didn't bother. We simply showed the boss the
comparative figures, and he agreed that there was no point in continuing
with .Net. After all, everyone has deadlines, and we'd already beaten
ours. The last thing anyone wanted was to add another three months to the
project while we fiddled around trying to figure out how to get Yet
Another Microsoft Technology to do as it's told. It was that or deliver

And, of course, to Learn YAMT.

fast code, early, within budget. We chose the latter. Wouldn't you?

Later on, however, one or other of us (I forget which) discovered (I'm not
sure how authoritatively) that, apparently, .Net is not good at heavily

Dijkstra was precise: much of what passes for knowledge in computing
circles is a sort of oral folklore, whisperings of dark secrets around
campfires in a demon-haunted world.

How would .Net not be good at recursion? My parser in the compiler for
Build Your Own .Net Language and Compiler worked at constant time
applying a rather deeply recursive top-down descent algorithm.

.Net has to set up a safe and rational procedure call for recursion
the first time, and reuse it depending on the depth of recursion. The
folk-lore isn't confirmed that it isn't "good" at recursion.

Recursion was hard when routines supplied "work areas" to their
callees and compilers blew their tops trying to compile a recursive
call. The rumor that .Net's technologists messed it up, when the
academy has long known what you have to do (think stacks, Richard) is
a blood libel.

recursive code, and since our code did little else *but* recurse (its
function was to extract dependency relationships from source code, and
much of this was achieved by parsing the source to look for stuff like
#include "foo.h", <a href="yadayadayada.html">, etc etc - and parsing is
an inherently recursive process), this may go some way towards explaining
the huge performance disparity between .Net and native code.

Whoa, a huge performance disparity emerges as it were from de jungle.
I'm no expert on relative performance disparities between .Net and
native. I do know, however, that historically, whenever a man wanted
to solve a problem with some sort of run-time language that had to be
interpreted in some way, your basic Computer Guys would mutter
aaaaargh burn me buttocks would ye slow things down, belike?

There is such a think as folkish wisdom. But there is also folly in
the folk.

With all due respect, this sounds to me belike one of those *ersatzen*
for due diligence, in which the actual coders are invited by
management to evaluate a new tech direction without being given any
slack on the deadlines, which they could use to sit back and do due
diligence.

I mean, did you write recursive code and run it on a .Net platform
side by side with a "native" platform?

It sounds to me that some guy passed along a rumor at some meeting.
One reason why programmers, and many other decent folk, abhor meetings
in tech venues where the main job is production. No time is given for
intellectual honesty, and Rumour, painted full of tongues, is the time-
saver of choice.

This is to me an economic tragedy as severe as that of the commons,
but nameless. The workers are asked to take control by management but
not given the time to do the work of self-management, and for this
reason, revert to folk-lore.

 

[Richard Heathfield]

spinoza1111 said:

My parser in the compiler for
Build Your Own .Net Language and Compiler worked at constant time
applying a rather deeply recursive top-down descent algorithm.

I am aware of your performance track record, as a result of which I find it
difficult to take seriously anything you say about performance. I am also
aware of your posting record, as a result of which I find it difficult to
take seriously anything you say on any subject whatsoever.

 

[Jon Skeet [C# MVP]]

Yeah, fair enough - I'll revise it to "100% of the .Net projects I've been
involved with have run 60 times slower than their native equivalents".

And that's entirely reasonable, so long as you tack on:

"... but we didn't know how to optimise it, or profile it, or have any
experience in .NET"

Then everyone will understand how much weight to place on that
particular data point

 

[Richard Heathfield]

Jon Skeet [C# MVP] said:

Then everyone will understand how much weight to place on that
particular data point

My dear chap, if people truly understood how to weigh the data available to
them, we wouldn't let ourselves be ruled by crooks!

Er, sorry, typo. s/crooks/politicians/

 

[Guest]

Excuse me? We already had working code - and you want us to *rewrite*
it? As in, write it *again*? I Don't Think So. We already had a
solution that worked well and worked fast. We tried it on .Net and
suddenly it took ten minutes instead of ten seconds. Now, we had two
ways we could go - rewrite the code to find two orders of decimal
magnitude from somewhere (bearing in mind that the original coding did
not build in two orders of stupidity for us to magically find later),
or drop .Net - it was no contest, believe me.

Working code doesn't mean the optimal code for .NET. It's like running a a
foreign language document through BabelFish and expecting it to return a
flawless translated document - it just doesn't work that way. You probably
need to tweak, optimize your code for the .NET platform just as you did for
whatever language you originally wrote it for.

So you already had pre-conceived biases against .NET, so perhaps it's
better to you stick to whatever language/framework you were using
orignally... since that's what you want anyways.

 

[Guest]

No. If that were true, the native code would have run slowly too.
Remember we are talking SIXTY times slower on .Net than natively.

For example, string concatenation without StringBuilder will grind .NET to
a halt. Could be something similar.

So 60x slower isn't something surprising ... especially if you do not have
..NET experience or understand how the framework works under the covers.

 

[Andre Kaufmann]

Andre Kaufmann said:



<shrug> I know the performance problem existed, and I know it went away
when we stopped using .Net - make of it what you will.

I'll continue to state it, since you don't write how you compiled your C
code for .NET -> how did you please ?
Otherwise I must assume you either aren't interested in an explanation
or try to troll around.

In one post you indirectly stated that you haven't converted your code
to .NET but recompiled it under Visual C++ .NET.
The latest Visual C++ .NET compiler doesn't compile by default C code to
..NET and a typical fault of CBuilder users is to compare debug builds
and I had long discussions why the C code (typically heap intensive one)
is so slow compiled under Visual C++ (in debug mode).

Andre

 

[Guest]

.net is a complex tool and you are right, if you are in a hurry than
you should use whatever tool you are skilled in (this is a general
rule, not just .net one).
However, if you are planning mid-long term development then you might
take a better look at .net and start diggining into - you won't
regret.

Nah, maybe the old fossil wants job security... and hence doesn't want to
introduce .NET into his workplace

 

[Andre Kaufmann]

To avoid countless further posts, would you be so kind to create a
sample that shows ~60x (or whatever the factor is) slower code execution?

He hasn't responded to the parts of my posts too, where I stated too he
has been doing something wrong, only by denying it.

I simply wanted to know how they have compiled C code to .NET but got no
answer yet, so I assume he is not interested in an explanation.

Andre

 

[Jeff Gaines]

In that case it would probably be worth avoiding the assertion that
.NET is slow in future.

Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
any programmers with a few years experience who aren't aware of that. If
it were possible to use the latest common controls in VB6 I'd go back to
it like a shot.

 

[Andre Kaufmann]

Jon Skeet [C# MVP] said:

In that case it would probably be worth avoiding the assertion that
.NET is slow in future.

Yeah, fair enough - I'll revise it to "100% of the .Net projects I've been
involved with have run 60 times slower than their native equivalents".

Since you don't write which compiler and settings you used and which
code basis (C - Code / C-Sharp etc.) I don't believe you've compiled
..NET code at all.

Andre

 

[Richard Heathfield]

Andre Kaufmann said:

I simply wanted to know how they have compiled C code to .NET but got no
answer yet,

C++, actually. Well, it was - what, four years ago? Something like that.
Lots of new technologies come along all the time. Pick one at random.
Spend two to three weeks using it. Abandon it, never to use it again. Then
answer random detailed questions on it four years later. Maybe you'll do
better than I did.

so I assume he is not interested in an explanation.

Explain away if you want to. No, I'm not terribly interested, but I'm
interested enough to continue to follow the thread.

 

[Richard Heathfield]

Andre Kaufmann said:

I don't believe you've compiled .NET code at all.

Then we have nothing further to discuss.

 

[Registered User]

-snip-

I don't think .NET struggles with recursive algorithms. Tail-recursion
is only used in certain circumstances (depending on the JIT compiler
and source language, if I remember correctly) but that's unlikely to be
responsible for the majority of a 60x slowdown. It may have had *some*
performance impact, but not of the magnitude you saw.

I suspect it's far more likely that your code had some other bottleneck
(such as using string concatenation instead of a StringBuilder) which
was due to inexperience rather than anything inherently wrong with the
framework itself.

One of the earlier posts by Mr. Heathfield mentioned the application
used sockets. If performance was an issue that is where I would look
first.
-snip-A deadline is just an arbitrary date on the calendar chosen by someone
with a to-do list. Unfortunately marking the task as completed is
often more important than properly completing the task.

Fair enough - but it really doesn't sound like that "best shot" was
even slightly enough to give you sufficient evidence for your ".NET is
slow" claim.

That seems to be what everyone is trying to point out. Anecdotal
evidence concerning a port of a port's performance is being given too
much value. The is especially true when the first port involved
hacking on socket code.

regards
A.G.

 

[Andre Kaufmann]

Andre Kaufmann said:



C++, actually. Well, it was - what, four years ago? Something like that.

Thank you.

You have used the same C++ compiler (I assume Visual Studio) to compile
the *same* code to

a) native
b) pure or safe IL code


compared it and b) is 60 *times* slower ?


As I wrote it's a common pitfall for C-Builder users to:

1) Compile the debug version under VC only, which unfortunately
uses some slow debug settings by default, to catch heap
errors more quickly

2) Assume Visual Studio .NET C++ compiler is a .NET compiler by default
The name is unfortunately misleading

Andre

 

[Cor Ligthert[MVP]]

Jeff,

Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
any programmers with a few years experience who aren't aware of that. If
it were possible to use the latest common controls in VB6 I'd go back to
it like a shot.

If that is really so, you should good follow the advices which by instance
Jon has given in this thread.

An average VB6 application should be much slower in overall throughput then
a .Net application (with the exception of applications using heavily late
binding in whatever way). A C application is not comparable because that can
even be software which is not real meant for Net like by instance drivers.

Cor

 

[Jon Skeet [C# MVP]]

Why? .NET is slow, any VB6 or C app beats it hands down, there can't be
any programmers with a few years experience who aren't aware of that. If
it were possible to use the latest common controls in VB6 I'd go back to
it like a shot.

If you can provide *evidence* of that, you'll be the first to do so in
this thread...

 

[Cor Ligthert[MVP]]

Miha,

Imagine a person used to drive a Zastava Yugo. He knows it to the bones.
Now, let's imagine that he tries a brand new Lamborghini Diablo and
because his lack of knowledge he can't even start it up.

It is very patriotic from you to tell that a Zastava is easier to handle
then a Lamborghini, however I have the idea that somebody coming from a
Lamborgini could have problems to drive with a Zastava too even if it was in
the same speed.

However starting a car should be with both no problems. I am not so fond
about cars from the communist era so I believe that the Lamborgini will
start much easier and be much reliable.

That should be the same with .Net developing software and the documentation
around it. And in my idea that is.



Cor

 

[Mr. Arnold]

jim wrote:

<snipped>

I see the MS camp is in heated battle with King Little Richard
Heathfield of comp.programming. The king and his disciples as well as
most that frequent comp.programming are anti MS and hate MS with a passion.

But mainly it's that lunatic King Little Richard that sets the pace in
the NG and is at the helm, as everyone can see.

You should all kick him to the curb, because otherwise, I'll lip drivel
all of you about MS and .NET and until the cows come home.

I don't know why the OP posted to that disaster of NG called
comp.programming to arouse the lip babbling King Little Richard about .NET

<VBG>

 

[Mr. Arnold]

jim wrote:


<oops a small correction>

You should all kick him to the curb, because otherwise, King Little
Richard will lip drivel all of you about MS and .NET and until the cows
come home.

<g>