If not .Net then what?

[Miha Markic]

Another objection is that it's slow. The first program I moved to .Net ran
around 60 times slower than native - way too slow to be useful.

It is not that slow. It might be a bit slower or a bit faster, depending on
what you are doing.
But the magnitude of your problem clearly shows that you were doing
something wrong.

 

[Richard Heathfield]

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.
Now, he doesn't bother to RTFM, nor he asks anybody how to start it up.

The conclusion? Diablo sucks while Yugo rules.

Now imagine an experienced racing team who can get a car around Silverstone
in around 86 seconds (the lap record is 84.475, so 86 is nothing
earth-shaking, but it's not exactly useless, either). They take delivery
of a brand-new car that supposedly works on a completely new principle.
The team has two drivers. The first one takes it out for a test, but about
a quarter of the way around the circuit she gets out and starts walking,
because she assumes it's stalled. It hasn't, but she's moving round the
track faster than the car. The second one is more patient, and completes a
single lap in just under an hour and a half - about the time it would
normally take to do the full sixty laps or so.

The race is next week. What should the team do? Sing the praises of the
car, and say "this must be our fault for not knowing the car; let's forget
the race, and work 24/7 on getting the car up to walking speed in time for
the following race"? Or are they more likely to say "this looks like a
complete lemon - let's stick with a car that can compete"?

Yes, maybe the new car *can* be driven, by people who are very very
familiar indeed with it, at a sensible and even competitive pace. But for
people who need high performance in a hurry, it's a wombat.

 

[Miha Markic]

Yes, maybe the new car *can* be driven, by people who are very very

familiar indeed with it, at a sensible and even competitive pace. But for
people who need high performance in a hurry, it's a wombat.

..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.

 

[Richard Heathfield]

It is not that slow.

Denial? Interesting.

It might be a bit slower or a bit faster, depending
on what you are doing.

A bit, yes.

But the magnitude of your problem clearly shows that you were doing
something wrong.

No, that's begging the question.

 

[Jon Skeet [C# MVP]]

The race is next week. What should the team do? Sing the praises of the
car, and say "this must be our fault for not knowing the car; let's forget
the race, and work 24/7 on getting the car up to walking speed in time for
the following race"? Or are they more likely to say "this looks like a
complete lemon - let's stick with a car that can compete"?

I don't think anyone's really criticising your decision to go with
native C++ instead of .NET - it's the fact that you've taken your first
experience of .NET (which sounds half-hearted - you got the result you
wanted, i.e. the decision to stick with C++, and didn't put significant
effort into understanding why the .NET version was slow) and
extrapolated from there to your original claim that "it's slow".

I suspect that if I wrote C++ trying to use .NET idioms, that could be
slow as well - but I wouldn't make the assumption that that was the
fault of C++.

It's worth accepting that different platforms have different idioms,
and that you shouldn't expect your first experiences in a "new"
platform to compare well with experiences in a platform on which you
have a lot of experience.

Now, if you'd hired a .NET developer (not necessarily an expert - just
someone who was genuinely familiar with the platform), profiled the
app, *tried* to make it perform well, and still failed - *that* would
have been good evidence that .NET was slow for your particular
situation. (It still wouldn't have been good *general* evidence of
course.)

 

[Richard Heathfield]

Jon Skeet [C# MVP] said:

I don't think anyone's really criticising your decision to go with
native C++ instead of .NET - it's the fact that you've taken your first
experience of .NET (which sounds half-hearted - you got the result you
wanted, i.e. the decision to stick with C++,

Well, to be honest, I wanted C, but my colleague reasoned that C++ is
pretty much like C except that it has more toys, and it would be easier
for me to ignore toys I don't want than for her to do without toys she's
used to. She had a point, of course, so we went C++ instead of C.

and didn't put significant
effort into understanding why the .NET version was slow) and
extrapolated from there to your original claim that "it's slow".

Life's too short to spend it doing exhaustive analysis of every single
technology that comes along. Nevertheless, we spent several weeks on the
..Net thing, if memory serves me right. And we did use it to write a test
harness, which we ended up using even though we didn't like it very much.

I suspect that if I wrote C++ trying to use .NET idioms, that could be
slow as well - but I wouldn't make the assumption that that was the
fault of C++.

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles with
recursive algorithms, which makes it kinda pointless for language
processing applications.

Now, if you'd hired a .NET developer (not necessarily an expert - just
someone who was genuinely familiar with the platform), profiled the
app, *tried* to make it perform well, and still failed - *that* would
have been good evidence that .NET was slow for your particular
situation. (It still wouldn't have been good *general* evidence of
course.)

It would have been a neat trick, actually, since the ink on the box was
still wet - the only .Net people in the UK at the time were either beta
testers or liars.

But we did give it the best shot we could without compromising the
deadline.

 

[Miha Markic]

Nevertheless, it does seem that .Net struggles with

recursive algorithms, which makes it kinda pointless for language
processing applications.

It does seem to you....

 

[Miha Markic]

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?

 

[Lasse Vågsæther Karlsen]

Jon Skeet [C# MVP] said:

I don't think anyone's really criticising your decision to go with
native C++ instead of .NET - it's the fact that you've taken your first
experience of .NET (which sounds half-hearted - you got the result you
wanted, i.e. the decision to stick with C++,

Well, to be honest, I wanted C, but my colleague reasoned that C++ is
pretty much like C except that it has more toys, and it would be easier
for me to ignore toys I don't want than for her to do without toys she's
used to. She had a point, of course, so we went C++ instead of C.

and didn't put significant
effort into understanding why the .NET version was slow) and
extrapolated from there to your original claim that "it's slow".

Life's too short to spend it doing exhaustive analysis of every single
technology that comes along. Nevertheless, we spent several weeks on the
.Net thing, if memory serves me right. And we did use it to write a test
harness, which we ended up using even though we didn't like it very much.

I suspect that if I wrote C++ trying to use .NET idioms, that could be
slow as well - but I wouldn't make the assumption that that was the
fault of C++.

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles with
recursive algorithms, which makes it kinda pointless for language
processing applications.

Did you profile the .NET solution and verified that it was indeed
recursion that ate up time? So far all we know is that it relied heavily
on string parsing and recursion, but without profiling evidence I
wouldn't assume anything about why it ran slow.

I have a fairly extensive recursive solution implemented in a system
that processes gigabytes of log-files each day and recursion was nowhere
near a bottleneck in that solution. I/O and memory usage (GC) was the
top two time-spenders in that solution.

It would have been a neat trick, actually, since the ink on the box was
still wet - the only .Net people in the UK at the time were either beta
testers or liars.

Considering I'm still learning new ways to eek more performance out of
..NET every week I'll venture a guess that your solution wasn't optimal
either. It might've been the best you could produce but I'll vaguer that
there is probably a better solution available.

Would it be able to eat up the 1/60th speed degradation? Probably not,
but who knows.

All I'm saying that regardless of your particular solution, .NET isn't
slow in all respects.

Pick the best tool for the job. Sounds like you did. Case closed.

 

[Jon Skeet [C# MVP]]

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles with
recursive algorithms, which makes it kinda pointless for language
processing applications.

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.

It would have been a neat trick, actually, since the ink on the box was
still wet - the only .Net people in the UK at the time were either beta
testers or liars.

Well, it was in beta test for a pretty long time - people had
reasonable experience before it was fully released. I'd call myself a
reasonably experienced C# 3 developer, but C# 3 was only released last
month as part of .NET 3.5.

However, the significant point is that "lack of experienced
developers" certainly *was* a valid objection to using .NET - back
then. It isn't now, and it isn't a good reason to claim that .NET is
slow.

But we did give it the best shot we could without compromising the
deadline.

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.

Do you think that .NET would be widely used at all if it were typically
60x slower than native code?

 

[Richard Heathfield]

Lasse Vågsæther Karlsen said:

Did you profile the .NET solution and verified that it was indeed
recursion that ate up time?

As I said upthread, as far as I can recall we did not succeed at the time
in working out why the .Net version was so slow.

Considering I'm still learning new ways to eek more performance out of
.NET every week I'll venture a guess that your solution wasn't optimal

I can accept that.

 

[Jon Skeet [C# MVP]]

Pick the best tool for the job. Sounds like you did. Case closed.

I'd expand that slightly further:

Pick the best tool for the job and for the resources available. I
strongly suspect that if the resources available had been experienced
C# developers who didn't know native C++, the best tool for the same
job would be .NET.

 

[Richard Heathfield]

Jon Skeet [C# MVP] said:

Do you think that .NET would be widely used at all if it were typically
60x slower than native code?

Yes, I'm afraid I do.

 

[Cor Ligthert[MVP]]

Jon,

Do you believe in the fable that native code is quicker than code build
around efficient routines?
Native code is because of the nature which leads to often inneficient use
normally slower, which start at the loading time because the size of a
native program in memory is forever huger then with efficient routines
(what a runtime in fact is).

Beside that there is since 1965 probably not anymore one real for general
purpose written application in total native code which works without any OS
around it. (The OS's were in the beginning in fact nothing more then a kind
of runtime).

Cor

 

[Bart C]

[on C++ appl being 60x slower in .Net]

Yes, it's a fair point. Nevertheless, it does seem that .Net struggles
with
recursive algorithms, which makes it kinda pointless for language
processing applications.

Perhaps you can post the shortest piece of code that shows the problem. Then
some of us (not me) might help finding the reasons.

Bart

 

[Richard Heathfield]

Bart C said:

Perhaps you can post the shortest piece of code that shows the problem.

That's a perfectly sensible request, but alas, the answer is no, I can't do
that. This is because the incident in question occurred (several years
ago) on a client site - NDA applies, so I wouldn't be able to show the
code to you even if I had a copy (which I don't). And since I never use
..Net any more if I can possibly avoid it, I simply don't care enough to
construct an example. Sorry.

 

[Jon Skeet [C# MVP]]

Do you believe in the fable that native code is quicker than code build
around efficient routines?

I'm not at all sure what you mean.

In some cases I believe that idiomatic native code will be faster than
..NET. In some cases it will be slower. In most cases my experience
suggests it will be "about the same".

Native code is because of the nature which leads to often inneficient use
normally slower, which start at the loading time because the size of a
native program in memory is forever huger then with efficient routines
(what a runtime in fact is).

Um, no. Loading a runtime takes time - this is easy to see when you
first run even a small .NET program after boot. A comparable native
program is likely to load and start up much quicker. After the
framework is in the disk cache, the startup time of .NET improves a lot
though.

Beside that there is since 1965 probably not anymore one real for general
purpose written application in total native code which works without any OS
around it. (The OS's were in the beginning in fact nothing more then a kind
of runtime).

"Native code" in this context is "source code which is compiled
directly to machine code". That doesn't prevent it from using standard
libraries.

 

[Jon Skeet [C# MVP]]

That's a perfectly sensible request, but alas, the answer is no, I can't do
that. This is because the incident in question occurred (several years
ago) on a client site - NDA applies, so I wouldn't be able to show the
code to you even if I had a copy (which I don't). And since I never use
.Net any more if I can possibly avoid it, I simply don't care enough to
construct an example. Sorry.

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

 

[Richard Heathfield]

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".

 

[Lasse Vågsæther Karlsen]

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".

Fair enough

Made me laugh