If not .Net then what?

[Stephen Howe]

When you say "simple stuff" it makes me think that you probably used the

built-in, drag & drop, "RAD" features of the IDE. I would contend that
those features are not intended for use in enterprise applications.

Well then, lets benchmark it:

Sieve of Erastophenes
Copying N files from one directory to another without using an API.
Reading the complete works of Shakespeare and then dumping to stdout each
word in alphabetical order plus a count

If you have to spend a couple of years on each task to get equivalent
performance, then .NET has lost.

Now if relatively simple tasks are all slow in .NET (or Java), dont care
which, compared to straight Win32 console apps in VB6, C, C++, Dephi,
Fortran, isnt it a matter of time before Microsoft declares .NET as legacy?
Garbage Collection from 1959 will work well for a limited class of problems.
But AFAIK, it is pretty poor as a universal panacea.

There was never anything wrong with straight Win32 or Win64 apps until MS
got bored.
Remind me also which MS apps are written in .NET?

Stephen Howe

 

[Stephen Howe]

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.

If the code was, say, 250,000 lines of converted C++, then yes it could be
so.
There coudl be easily be something that is missed.

But suppose it was a 10-line program.
You check the obvious that you dont have debug switches switched on.
And it is still slow compared to an equivalent C or C++ Win32 program.
Then yes, I blame .NET

Stephen Howe

 

[CBFalconer]

.... snip ...

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

I think you are all missing the fundamental point. C++ has a well
known, and generally adhered to, ISO standard. .NET is basically a
single supplier system. Richard and associates prefer not to be
limited to such a small user area. The fact that they could
immediately find bugs [1] is confirmation of their wisdom.

[1] I define a slow-down factor of 60 as a bug.

 

[Mr. Arnold]

Richard and associates prefer not to be
limited to such a small user area. The fact that they could
immediately find bugs [1] is confirmation of their wisdom.

[1] I define a slow-down factor of 60 as a bug.

Well, you heard it from Prince CBFalconer a disciple, a serious behind
kisser to King Little Richrad in King Little Richard's comp.programming
NG about King Little Richard, and how they will kiss his behind time and
time again.

The OP that crossed posted to sorry comp.programming made a serious
mistake in posting to this NG and to the people with such serious bias
opinions and behind kissing going on that happens in that NG.

 

[Michael D. Ober]

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.

My experience with memory intensive apps in VB 6 that I have actually
rewritten in VB 2005 is quite the opposite. The VB 2005 version is usually
around twice as fast simply because the NET GC is so much better. As for
comparing C++ to any NET language, you're comparing apples to oranges. C++
and C# design goals are not the same, despite the similarity in name.

I have to agree with some of the other responders that OP is actually trying
to prevent a switch to dotNET, and, even, possibly a switch to Windows (or
forcing a switch away from Windows).

Mike Ober.

 

[Scott Roberts]

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

You forgot "and only spent 2 weeks on it, and that was 2 years ago, and I
haven't even looked at it since."

 

[spinoza1111]

spinoza1111said:



I am aware of your performance track record, as a result of which I find it

That's lie, pure and simple, although in corporatese. You know very
little about it. Its flaws, FYI, are mostly ideological, a failure to
sign-on with normalized deviance.

difficult to take seriously anything you say about performance. I am also

I found it equally difficult to take you seriously on .Net performance
because you passed along a rumor to save time.

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

So don't respond with lies about what you do and do not know. You have
performance anxiety and are engaged in psychological transference. You
enabled a cyberbullying campaign here in 2003 and 2004 by creating
offline web pages and you fantasize, as best as I can determine, about
the power of a pet language.

You feed what you believe to be a troll while at the same time
admonishing your partner in crime, Randy Howard, not to do so; this
alone displays bad faith.

 

[spinoza1111]

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

My point. When I started messing around in Java, I realized very
quickly owing to greater type strictness, Java was a different world,
and for this reason I didn't pop off about Java. I was certainly
willing to have Heathfield admonish me in 2003, in effect remind me
after a long vacation from using C, that "for loops evaluate for
conditions repeatedly" based on his expertise. But here, he enters
like Rumour in Henry IV part 2:

Open your ears; for which of you will stop
The vent of hearing when loud Rumour speaks?
I, from the orient to the drooping west,
Making the wind my post-horse, still unfold
The acts commenced on this ball of earth:
Upon my tongues continual slanders ride,
The which in every language I pronounce,
Stuffing the ears of men with false reports.
I speak of peace, while covert enmity
Under the smile of safety wounds the world:
And who but Rumour, who but only I,
Make fearful musters and prepared defence,
Whiles the big year, swoln with some other grief,
Is thought with child by the stern tyrant war,
And no such matter? Rumour is a pipe
Blown by surmises, jealousies, conjectures
And of so easy and so plain a stop
That the blunt monster with uncounted heads,
The still-discordant wavering multitude,
Can play upon it.

 

[spinoza1111]

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/

Excellent foppery, my dear Richard. Jon is objecting to your entering,
"painted full of tongues", to speak with no authority and to say,
".Net doesn't 'do' recursion well". You divert us with references to
politicians which were elected by you and who in fact use data systems
constructed not to clarify truth, but to massage Rumours, with the
person most able to afford the best hardware and software winning the
race.

In the case of .Net you could have downloaded free software and tried
testing your code under .Net to have some numbers. But it appears that
you let loud Rumour speak.

 

[spinoza1111]

As Dijkstra pointed out, folklore replaces science. My dear fellow, it
is almost ungrammatical to say that ".Net is slow". It's as
incomprehensible as saying "computers are slow", or "the Boeing 747 is
slow", in that it is unrelativised to specific benchmarks and specific
needs.

A better case could be made for saying "computers today are too fast
and should slow down" because today they produce wrong answers
elegantly and fast, and today they enable people to spread rumours and
to cyberbully.

.Net is an interpreted. threaded, layer varnish'd over raw computation
which is reified when unattached from human needs. By the computing
reifier .Net stands sore charged for "wasting time" DESPITE the fact
that sans .Net or Java, we'd long have succumbed to random code
executing anywhere.

What!? VB6 controls were a joke and spread incomprehension because of
the unnecessary form/control divergence and the horror of the property
bag. Today, I can create controls without a mouse on sea, land and air
(on the commuter ferry and in coach class) by writing C sharp code,
and this is a Good Thing.

VB1..VB6 were infantile disorders, Babes in Toyland.

 

[spinoza1111]

:







... snip ...




I think you are all missing the fundamental point.  C++ has a well
known, and generally adhered to, ISO standard.  .NET is basically a
single supplier system.  

Which conforms to ECMA standards.

Richard and associates prefer not to be
limited to such a small user area.  The fact that they could
immediately find bugs [1] is confirmation of their wisdom.

[1] I define a slow-down factor of 60 as a bug.

Gee, even in Console.Writeline("Hello world") versus printf("Hello
world\n");? I'll alert the media.

 

[Richard Heathfield]

spinoza1111 said:

That's lie, pure and simple, although in corporatese.

No, it's not, as anyone can see from a quick Google Groups search for
articles posted in comp.programming containing both "nilges" (not
necessarily as author) and "strlen". I got 163 hits. Anyone bored enough
to wade through them all will quickly learn that you don't know spit about
performance, and that you lack the intellectual honesty to acknowledge and
learn from your errors.

 

[Cor Ligthert[MVP]]

VB1..VB6 were infantile disorders, Babes in Toyland.

But in very much ways a bleu print for C#.

C# is not only inheriting from C++, Java or C.

To follow your anology: C# has beauty as mother an a geek as father.



Cor

 

[Cor Ligthert[MVP]]

C# is not only inheriting from C++, Java or C.

To follow your anology: C# has beauty as mother an a geek as father.

The same for her brother VB for Net of course.

Cor

 

[Jon Skeet [C# MVP]]

I think you are all missing the fundamental point. C++ has a well
known, and generally adhered to, ISO standard. .NET is basically a
single supplier system. Richard and associates prefer not to be
limited to such a small user area.

That much is fine. It's a perfectly valid objection. I should point out
that C# also has an ISO standard; I'm not sure whether the CLI which
has an ECMA standard also has an ISO standard - but either way, unless
you include things like Mono, it's still a single supplier system.

The fact that they could
immediately find bugs [1] is confirmation of their wisdom.

[1] I define a slow-down factor of 60 as a bug.

That's crazy without knowing what their code was doing. There are
plenty of reasons why Richard might have seen a slow-down factor of 60
by performing a *naive* port without any bugs in .NET. You just can't
expect to apply all idioms from one platform to another. You need to
learn the idioms of the new platform.

 

[Jon Skeet [C# MVP]]

Well then, lets benchmark it:

Sieve of Erastophenes
Copying N files from one directory to another without using an API.

Any API at all, or just a file copying API? In other words, do you
allow APIs to open a file as a stream?

Reading the complete works of Shakespeare and then dumping to stdout each
word in alphabetical order plus a count

If you have to spend a couple of years on each task to get equivalent
performance, then .NET has lost.

I'd agree, so long as you allow, say, a 20% performance loss to still
count as "equivalent" - it's close enough that the development benefits
of .NET easily make up for it, in my view.

I'd also have one other performance stipulation: that the tasks not be
so fast as to make startup time dominate. In other words, make the
tasks sufficiently long (or run them repeatedly within one test) so
that the overall test takes at least a minute. After all, most
applications (particularly server side) *do* run for more than a
minute, and it's the long-term performance which matters more.

Now if relatively simple tasks are all slow in .NET (or Java), dont care
which, compared to straight Win32 console apps in VB6, C, C++, Dephi,
Fortran, isnt it a matter of time before Microsoft declares .NET as legacy?

I'd agree. But there's an "if" which you appear to be assuming is
actually the case.

Now, would you care to actually do the benchmarks you've mentioned
above? They all sound simple enough that I can probably find the time

Garbage Collection from 1959 will work well for a limited class of problems.
But AFAIK, it is pretty poor as a universal panacea.

It's not meant to be a universal panacea - just better than manual
malloc/free. (I also rather suspect that it's moved on since 1959 - did
John McCarthy invent generational, concurrent garbage collection back
then?)

There was never anything wrong with straight Win32 or Win64 apps until MS
got bored.
Remind me also which MS apps are written in .NET?

There are some (Windows Live Writer and SQL Server Management Studio
just to pick a couple of examples), and some coming up (the health care
system they're building, for exampe). Don't expect Office to be
rewritten in .NET any time soon though - a complete rewrite would be
daft.

 

[Andre Kaufmann]

Andre Kaufmann said:


Then we have nothing further to discuss.

O.K., you stated you don't want to port your code to .NET in another
post and you said that your code runs 60 times slower under .NET ?

If I ask how you did it you simply ignore the questions. And if I try to
tickle you a bit to get it out, you seem to be offended.

You blame others knowing nothing of performance, but you can't tell us
why your code port (was it ?) has been that slow.

So the facts:

a) You have C++ code
b) Stated you compiled it somehow as .NET application
c) Stated that it runs 60 times slower
d) Have no single proof
e) Don't tell us how you did b)
f) Blaming others to be kind of dumb by using the words "clicky-pointy"
g) Can't prove it all


But yes, in one point you are correct:

Then we have nothing further to discuss.

There isn't really nothing substantial to discuss.


Andre

 

[Jeff Gaines]

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

What would be a good test? I am happy to try it (if only for my own
satisfaction) but don't want to spend hours putting something together.
Something like sorting a large string array and calculating factorials?

 

[Miha Markic]

If the code was, say, 250,000 lines of converted C++, then yes it could be

so.
There coudl be easily be something that is missed.

But suppose it was a 10-line program.
You check the obvious that you dont have debug switches switched on.
And it is still slow compared to an equivalent C or C++ Win32 program.
Then yes, I blame .NET

I really wonder how could be a 10 lines program 60x slower.

 

[Bart C]

Well then, lets benchmark it:

Sieve of Erastophenes

I tried this little recursive program in C#. And similar in straight C. The
C# took nearly twice as long but that was probably in debug mode. So
pleasantly surprised.

Unless I've missed the point about what .Net is, I'm assuming it's a bunch
of MS languages all producing the same IL and a huge runtime, plus some
over-the-top IDEs.

using System;
class program
{
static void Main(string[] args)
{
int n,f;
n=43;
f = fib(n);
Console.WriteLine("Fib({0})={1}", n,f);
Console.ReadLine();
}

static int fib(int n){
if(n>1)
return fib(n-2)+fib(n-1);
else
return 1;
}
}


Bart