M
Miha Markic
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.
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.
R
Richard Heathfield
Miha Markic said:
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.
M
Miha Markic
Yes, maybe the new car *can* be driven, by people who are very very
..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.
..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.
R
Richard Heathfield
Miha Markic said:
Denial? Interesting.
A bit, yes.
No, that's begging the question.
J
Jon Skeet [C# MVP]
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.)
R
Richard Heathfield
Jon Skeet [C# MVP] said:
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.
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.
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.
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.
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.
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.
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.
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.
M
Miha Markic
Nevertheless, it does seem that .Net struggles with
It does seem to you....
It does seem to you....
M
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?
that shows ~60x (or whatever the factor is) slower code execution?
L
Lasse Vågsæther Karlsen
Richard said:
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.
J
Jon Skeet [C# MVP]
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.
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?
R
Richard Heathfield
Lasse Vågsæther Karlsen said:
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.
I can accept that.
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.
I can accept that.
J
Jon Skeet [C# MVP]
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.
R
Richard Heathfield
Jon Skeet [C# MVP] said:
Yes, I'm afraid I do.
Yes, I'm afraid I do.
C
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
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
B
Bart C
[on C++ appl being 60x slower in .Net]
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
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
R
Richard Heathfield
Bart C said:
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.
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.
J
Jon Skeet [C# MVP]
Cor Ligthert said:
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".
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.
"Native code" in this context is "source code which is compiled
directly to machine code". That doesn't prevent it from using standard
libraries.
J
Jon Skeet [C# MVP]
Richard Heathfield said:
In that case it would probably be worth avoiding the assertion that
..NET is slow in future.
R
Richard Heathfield
Jon Skeet [C# MVP] said:
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".
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".
L
Lasse Vågsæther Karlsen
Richard said:Jon Skeet [C# MVP] said:
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
