If not .Net then what?

[jim]

In a thread about wrapping .Net applications using Thinstall and Xenocode,
it was pointed out that there may be better programming languages/IDEs to
use for the purpose of creating standalone, single executable apps.

My goal is to create desktop applications for use on Windows XP+ OSs that
are distributed as single executables that do not require traditional
install packages to run.

I would like to use a drag and drop UI development tool like the .Net IDE
(or the old VB6) to make development as easy as possible. I am a hobbyist
programmer and would like to put out some useful apps, but I don't want to
have to become an expert at a complex language like C++ to do so reliably.

More than one person responding to the previous thread held the opinion that
..Net was great for corporate environments where all PCs are strictly
regulated, but may not be the best option to develop the type of apps that I
would like to develop for the PC community at large.

So what, in your opinion, would be a good alternative to use to develop the
type of applications that I am trying to develop?

jim

[Jon Skeet [C# MVP]]

Richard Heathfield <rj*@see.sig.invalidwrote:

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.

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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Richard Heathfield]

Jon Skeet [C# MVP] said:

Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

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

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

Richard Heathfield wrote:

Jon Skeet [C# MVP] said:

>Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

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

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 :D

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/

[Richard Heathfield]

spinoza1111 said:

<snip>

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jon Skeet [C# MVP]]

Richard Heathfield <rj*@see.sig.invalidwrote:

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

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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Richard Heathfield]

Jon Skeet [C# MVP] said:

<snip>

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/

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Spam Catcher]

Richard Heathfield <rj*@see.sig.invalidwrote in
news:uf******************************@bt.com:

>This is
rather a problem for unexperienced C++ programmers placing large
objects on the stack.

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.

--
sp**********@rogers.com (Do not e-mail)

[Andre Kaufmann]

Richard Heathfield wrote:

Andre Kaufmann said:

<snip>

>Well I simply state you hadn't a performance problem, just used the
tools wrong.

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

[Spam Catcher]

"Miha Markic" <miha at rthand comwrote in
news:OF**************@TK2MSFTNGP02.phx.gbl:

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

--
sp**********@rogers.com (Do not e-mail)

[Andre Kaufmann]

Miha Markic wrote:

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]

On 29/12/2007 in message <MP*********************@msnews.microsoft.com>
Jon Skeet [C# MVP] wrote:

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

--
Jeff Gaines

[Andre Kaufmann]

Richard Heathfield wrote:

Jon Skeet [C# MVP] said:

>Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

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

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:

<snip>

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 <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Andre Kaufmann said:

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

Then we have nothing further to discuss.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Andre Kaufmann]

Richard Heathfield wrote:

Andre Kaufmann said:

<snip>

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

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

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

[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]

"Jon Skeet [C# MVP]" wrote:

>

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

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Mr. Arnold]

CBFalconer wrote:

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

[Scott Roberts]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Richard Heathfield <rj*@see.sig.invalidwrote:

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

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

[Richard Heathfield]

spinoza1111 said:

On Dec 29, 9:42 pm, Richard Heathfield <[e-mail]:

>spinoza1111said:

<snip>

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

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jon Skeet [C# MVP]]

CBFalconer <cb********@yahoo.comwrote:

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.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Andre Kaufmann]

Richard Heathfield wrote:

Andre Kaufmann said:

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

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

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

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

[Bart C]

"Stephen Howe" <sjhoweATdialDOTpipexDOTcomwrote in message
news:rN******************************@pipex.net...

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

[Richard Heathfield]

Andre Kaufmann said:

Richard Heathfield wrote:

>Andre Kaufmann said:

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

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 ?

Since you say you don't believe me, what is the point in my saying anything
to you? Think about it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Mr. Arnold]

Andre Kaufmann wrote:

Richard Heathfield wrote:

>Andre Kaufmann said:

<snipped>

You can't talk to King Little Richard as he knows it all. You should cut
that fossil loose, and let him try to hold his court in comp.programming. :)

[Barry Kelly]

Richard Heathfield wrote:

Andre Kaufmann said:

Richard Heathfield wrote:

Andre Kaufmann said:

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

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 ?

Since you say you don't believe me, what is the point in my saying anything
to you? Think about it.

Because factual evidence stands alone, and you haven't provided any.

-- Barry

--
http://barrkel.blogspot.com/

[Barry Kelly]

Herfried K. Wagner [MVP] wrote:

Disclaimer: I work for CodeGear, a division of Borland. I do not and
(legally) cannot speak for the company. I speak in a personal capacity
only.

The reality is, it's a niche product that performs admirably for it's
intended
purpose. And I think it would be great for someone who wants to create
"standalone" Win32 apps.

Delphi is now developed by another company than Borland.

Delphi is a product developed by CodeGear, a subsidiary of Borland.

I am not sure
about support for older versions of Delphi like Delphi 7.

We work hard to ensure compatibility between releases, such that people
upgrading to newer versions should simply face a recompile, possibly
with a few adjustments, rather than a large amount of work. If code
compiled using very old releases doesn't work as well as possible with
new OSes etc., we hope that the code can be ported to a newer release
with ease.

As Delphi applications can and often are built as standalone
executables, I'd wager that they are often more resilient to changing
OSes than systems which link in lots of shared code.

Applications
developed using older versions may not be guaranteed to work properly on
future versions of Windows. That's what will finally kill VB6 too.

Delphi is an ongoing product. It's not like VB6, terminated in its
tracks. Delphi continues to be enhanced and developed.

-- Barry

--
http://barrkel.blogspot.com/

[Richard Heathfield]

Barry Kelly said:

Richard Heathfield wrote:

>Andre Kaufmann said:

Richard Heathfield wrote:
Andre Kaufmann said:

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

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 ?

Since you say you don't believe me, what is the point in my saying
anything to you? Think about it.

Because factual evidence stands alone, and you haven't provided any.

Not so. Everything that I have reported in this thread is factual. Whether
I have made correct *deductions* from the facts I have reported is of
course a matter of opinion, and I accept the possibility that I have made
incorrect deductions.

Nevertheless, it *is* the case that, in 2003 (I think), I and a colleague
wrote, in C++, a working system for analysing source code for determining
dependency relationships, and it *is* the case that we moved the code to
..Net and found that it ran sixty times slower on that platform. There may
be many reasons for that, reasons which we couldn't identify at the time,
and I accept that wholeheartedly.

But when Andre Kaufmann says that he doesn't believe that we did this, he
is basically accusing me of lying. If that is what he thinks, well, that's
up to him, but it makes future discussion with him rather pointless.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Andre Kaufmann]

Richard Heathfield wrote:

Barry Kelly said:
[...]

But when Andre Kaufmann says that he doesn't believe that we did this, he
is basically accusing me of lying.

No - I don't blame you of lying, but perhaps misinterpreting - read below.

If that is what he thinks, well, that's
up to him, but it makes future discussion with him rather pointless.

I only can't believe you, because you don't say us how you did it -
moved the C++ code to .NET. You haven't converted it, since you posted
that you don't want to convert code to .NET.

We don't know which compiler you used and which language: C++ / C# /
Delphi / C++/CLI ?

You haven't answered this question not in several posts, where I asked
for this information to track down the problem.
What would you conclude if one makes statements and doesn't answer
simple questions (please continue reading before answering this question) ?
Currently my conclusion, derived from the posts was:
----------------------------------------------------

You have compiled your code with Visual Studio C++ .NET in the debug
version, which is .... slow compared to the release switch. This is a
rather common "problem", when switching the compilers from CBuilder to
VStudio, because by default CBuilder (the old version) hasn't supported
multiple configurations and starts by default with all optimizations
turned on.

Even if you turn all optimizations on in VStudios debug default
configuration of a C++ project, the debug heap is still active and slows
down heavily your application. Since you are using commonly *not*
VStudio but only CBuilder I came to the conclusion above.
Shouldn't be offensive to you at all.

Andre

[Michael D. Ober]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:9J******************************@bt.com...

Barry Kelly said:

>Richard Heathfield wrote:

>>Andre Kaufmann said:

Richard Heathfield wrote:
Andre Kaufmann said:

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

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 ?

Since you say you don't believe me, what is the point in my saying
anything to you? Think about it.

Because factual evidence stands alone, and you haven't provided any.

Not so. Everything that I have reported in this thread is factual. Whether
I have made correct *deductions* from the facts I have reported is of
course a matter of opinion, and I accept the possibility that I have made
incorrect deductions.

Nevertheless, it *is* the case that, in 2003 (I think), I and a colleague
wrote, in C++, a working system for analysing source code for determining
dependency relationships, and it *is* the case that we moved the code to
.Net and found that it ran sixty times slower on that platform. There may
be many reasons for that, reasons which we couldn't identify at the time,
and I accept that wholeheartedly.

But when Andre Kaufmann says that he doesn't believe that we did this, he
is basically accusing me of lying. If that is what he thinks, well, that's
up to him, but it makes future discussion with him rather pointless.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Now that we have an application, there are a few questions that you still
haven't answered.

1) What version of dotNET? I suspect it's 1.1 with VS 2003 from your time
frame. Version 2.0 is signficantly faster that 1.1 for most applications.
2) What dotNET language did you port your application to?
3) Did you use automated porting tools or did you take the time to actually
rework the application to take advantage of the features in dotNET? I
suspect the answer to this is that you didn't spend the time to use the
framework the way it was designed.

Mike Ober.

[Richard Heathfield]

Andre Kaufmann said:

Richard Heathfield wrote:

>Barry Kelly said:
[...]

But when Andre Kaufmann says that he doesn't believe that we did this,
he is basically accusing me of lying.

No - I don't blame you of lying, but perhaps misinterpreting - read
below.

Then I have certainly misinterpreted an earlier remark that you made, for
which I apologise.

>If that is what he thinks, well, that's
up to him, but it makes future discussion with him rather pointless.

I only can't believe you, because you don't say us how you did it -
moved the C++ code to .NET. You haven't converted it, since you posted
that you don't want to convert code to .NET.

We wrote the original system in ISO C++ (plus Berkeley sockets).

We don't know which compiler you used and which language: C++ / C# /
Delphi / C++/CLI ?

We compiled the original code using several compilers - Intel, Visual
Studio 7, and gcc - and got comparable results from all of them - around
the 6 to 10 second mark for our test data set, with Visual C++ giving us 8
seconds IIRC. The translation to .Net involved converting to "managed"
C++.

You haven't answered this question not in several posts, where I asked
for this information to track down the problem.
What would you conclude if one makes statements and doesn't answer
simple questions (please continue reading before answering this question)
?

I would conclude that the person concerned isn't all that interested in a
justification, no matter how spirited, of a development environment that
they themselves rejected some years ago.

Currently my conclusion, derived from the posts was:
----------------------------------------------------

You have compiled your code with Visual Studio C++ .NET in the debug
version,

No. I may not be the brightest star in the firmament, but even I know to
switch to release mode when doing performance analysis - and my
then-colleague *is* one of the brightest stars in the firmament; even if
I'd been dense enough to try a performance test in debug mode, she'd soon
have put me right.

You seem to think that, because I sing C++ Builder's praises, I am a heavy
C++ Builder user. I'm not. In fact, I don't think I've ever used it in the
Real World, although I use it a fair bit at home. Most of my Real World
experience has been on Microsoft, GNU, and big iron compilers. I've used
(almost) every version of Visual C++ ever published, as well as Microsoft
C5.0, 5.1 and 6.0 (which pre-dated Visual C++). I am perfectly well aware
of the difference between debug and release.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jon Skeet [C# MVP]]

Bart C <[e-mail]:

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.

The funny thing about the Fibonacci sequence is that it's always shown
as the example of recursion, but it's one of the easiest recursions to
"undo" into a *far* more efficient form.

I'm sure most people reading this could give an alternative in their
sleep, but here's an example:

static int Fib(int n)
{
int previous = 0;
int current = 1;

for (int step = 0; step < n; step++)
{
int next = previous+current;
previous = current;
current = next;
}
return previous;
}

(Note that this is one step off from the code you gave - I was checking
by the sample data from Wikipedia. It's trivial to change, of course.
If you don't care about the n=0 case, it's slightly neater to return
current and make step start at 1, but hey...)

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.

Whether VS is over-the-top or not is a matter of opinion, of course. I
personally prefer Eclipse's Java support to VS's C# support, but never
mind. There are certainly a lot of designers, which I'm not generally a
fan of.

Other than that:
o Lots of languages compiling to IL - yes.
o The languages all being MS - no (see http://boo.codehaus.org for
example).
o Large runtime - yes.

I wouldn't say that's the "point" of .NET though. That's a question I
don't have time to address right now, unfortunately.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Andre Kaufmann]

Richard Heathfield wrote:

Andre Kaufmann said:

[...]
seconds IIRC. The translation to .Net involved converting to "managed"
C++.

O.K. thank you for the information and please apologize the parts of my
posts which might have been unintentionally offensive.

To be honest I'm playing around with managed C++ only after the old
managed C++ style supported by VS7 had been deprecated and C++/CLI has
been introduced.
So I have only performance experience with the newer C++/CLI syntax and
don't know if the managed C++ syntax / implementation had some
"performance problems". It definitively had some readability problems,
regarding the ugly double underscore keywords, although these have been
more standard compliant.

60 times is a huge decrease and from the information I currently have I
would suspect it to be a string problem, since strings in .NET are
immutable and therefore each changing of a string creates a new string
object, which may be quite inefficient.

But it's also possible that managed C++ had other performance problems.
That a performance decrease is not always the case, when switching to
managed C++, here a little illustrative example I'm currently investigating:

-------------------------------------------------
Native C++ example:

class T { public: void cb(int i) {} };

void perf()
{
test t;
boost::function<void (int)foo = boost::bind<void>(&T::cb, t, _1);
foo(100);
return 0;
}

-------------------------------------------------

Managed C++/CLI example:

ref class T { public: void cb(int i) {} };
delegate void CBD(int i);

void perf()
{
T^ test = gcnew T();
CBD^ foo = gcnew CBD(test, &T::callback);
foo(100);
return 0;
}

-------------------------------------------------
The native function call foo(100) needs 30 assembly instructions and 3
branches/jumps.
The managed one needs 5 assembly instructions and 3 branches/jumps.
But it's too early to derive anything from that. I'm currently searching
for the problem / failure I've made - if there is one.
And I'm not an expert regarding the boost::bind/function templates, so
maybe there's a more efficient way to write it, which reduces the number
of assembly instructions needed too.

[...]
C5.0, 5.1 and 6.0 (which pre-dated Visual C++). I am perfectly well aware
of the difference between debug and release.

Then please apologize, wasn't my intention to be offensive. I've got
bitten by the default configuration too, activated all optimizations,
but forgot to remove/change the damn debug macros.

Andre

[Andre Kaufmann]

Andre Kaufmann wrote:

>
O.K. thank you for the information and please apologize the parts of my
posts which might have been unintentionally offensive.

Ehm, damn could be misinterpreted too ;-).
Shouldn't mean that I had any intention to be offensive only that some
posts might be.

Should read:

Please apologize all parts of my posts which might have been offensive.
Wasn't my intention to be offensive.

[...]

Andre

[Randy Howard]

On Sun, 30 Dec 2007 17:44:02 -0600, Andre Kaufmann wrote
(in article <Ov**************@TK2MSFTNGP05.phx.gbl>):

Andre Kaufmann wrote:

>>
O.K. thank you for the information and please apologize the parts of my
posts which might have been unintentionally offensive.

Ehm, damn could be misinterpreted too ;-).
Shouldn't mean that I had any intention to be offensive only that some
posts might be.

Should read:

Please apologize all parts of my posts which might have been offensive.
Wasn't my intention to be offensive.

This political correctness bull is out of hand when you must post a
correction to your apology because you fear that the original apology
might have been offensive.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Michael D. Ober]

"Andre Kaufmann" <an*********************@t-online.dewrote in message
news:OP**************@TK2MSFTNGP05.phx.gbl...

Richard Heathfield wrote:

>Andre Kaufmann said:

>[...] seconds IIRC. The translation to .Net involved converting to
"managed" C++.

O.K. thank you for the information and please apologize the parts of my
posts which might have been unintentionally offensive.

To be honest I'm playing around with managed C++ only after the old
managed C++ style supported by VS7 had been deprecated and C++/CLI has
been introduced.
So I have only performance experience with the newer C++/CLI syntax and
don't know if the managed C++ syntax / implementation had some
"performance problems". It definitively had some readability problems,
regarding the ugly double underscore keywords, although these have been
more standard compliant.

60 times is a huge decrease and from the information I currently have I
would suspect it to be a string problem, since strings in .NET are
immutable and therefore each changing of a string creates a new string
object, which may be quite inefficient.

But it's also possible that managed C++ had other performance problems.
That a performance decrease is not always the case, when switching to
managed C++, here a little illustrative example I'm currently
investigating:

-------------------------------------------------
Native C++ example:

class T { public: void cb(int i) {} };

void perf()
{
test t;
boost::function<void (int)foo = boost::bind<void>(&T::cb, t, _1);
foo(100); return 0;
}

-------------------------------------------------

Managed C++/CLI example:

ref class T { public: void cb(int i) {} };
delegate void CBD(int i);

void perf()
{
T^ test = gcnew T();
CBD^ foo = gcnew CBD(test, &T::callback);
foo(100);
return 0;
}

-------------------------------------------------
The native function call foo(100) needs 30 assembly instructions and 3
branches/jumps.
The managed one needs 5 assembly instructions and 3 branches/jumps.
But it's too early to derive anything from that. I'm currently searching
for the problem / failure I've made - if there is one.
And I'm not an expert regarding the boost::bind/function templates, so
maybe there's a more efficient way to write it, which reduces the number
of assembly instructions needed too.

>[...] C5.0, 5.1 and 6.0 (which pre-dated Visual C++). I am perfectly well
aware of the difference between debug and release.

Then please apologize, wasn't my intention to be offensive. I've got
bitten by the default configuration too, activated all optimizations, but
forgot to remove/change the damn debug macros.

Andre

OK - now we're getting somewhere. I have heard that the C++ in VS 2003 had
some major issues with performance, especially when mixing C++ code with
dotNET libraries. I do know that Visual C++ 7.0 is slower than VC++ 6.0.
In addition, you need to realize that Managed C++ isn't a true dotNET
language. Rather, it's a hybrid. Thus you can't really make the claim that
dotNET apps are slower than C++.

Mike.

[Richard Heathfield]

Michael D. Ober said:

<snip>

OK - now we're getting somewhere. I have heard that the C++ in VS 2003
had some major issues with performance, especially when mixing C++ code
with
dotNET libraries. I do know that Visual C++ 7.0 is slower than VC++ 6.0.

So in other words, you recognise that the .Net implementation I was using
had serious performance issues, which is what I said all along.

In addition, you need to realize that Managed C++ isn't a true dotNET
language. Rather, it's a hybrid. Thus you can't really make the claim
that dotNET apps are slower than C++.

It said .Net on the box. Are you telling me Microsoft were lying to my
then-client by claiming it was .Net when really it wasn't .Net? Would you
advise them to sue Microsoft?

In any case, it is not my claim that .Net apps are slower than C++, because
C++ doesn't have a speed. It's a language, not an implementation. The
speed of the "vanilla" C++ version varied depending on whether the
executable image had been built using Intel, gcc, or Visual Studio.

..Net, however, /is/ an implementation, so it does make sense to talk about
the speed of .Net applications - and in my experience it is unacceptably
slow. If you have a different experience, I'm pleased for you.

My original response in this thread was to someone who said "I've only ever
heard one objection to .Net...", and he went on to explain why he thought
that the objection was invalid. My only objective in this thread was to
broaden his experience, by giving him two more objections. The fact that
some people here don't agree with those objections does not put them into
a different class from the original objection which, after all, he himself
did not agree with. But never again will he be able to say "I've only ever
heard one objection to .Net..." - because he has now heard at least three.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Herfried K. Wagner [MVP]]

"Andre Kaufmann" <an*********************@t-online.deschrieb:

The C++ compiler should emit the most optimized IL code of all .NET
compilers available from MS. At least with C++/CLI.

Well, optimization is primarily performed by the JIT compiler nowadays and
not by the compiler used to emit the IL. Optimization on JIT-level can be
more powerful because it can keep the machine's characteristics in mind.
Inlining, for example, is typically performed by the JIT compiler in .NET.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Andre Kaufmann]

Herfried K. Wagner [MVP] wrote:

[...]
Well, optimization is primarily performed by the JIT compiler nowadays
and not by the compiler used to emit the IL. Optimization on JIT-level
can be more powerful because it can keep the machine's characteristics
in mind. Inlining, for example, is typically performed by the JIT
compiler in .NET.

Sure, agreed.

But the JIT compiler has to be fast, so that startup time/runtime isn't
decreased that much. And IMHO it currently can do only local
optimizations. High level optimizations, like removing complete code
parts or function calls, are still the task of the compiler itself.

It doesn't mean that the effect is significant and measurable
(generally), only that the C++ compiler sometimes can optimize the code
better and emit somewhat more efficient IL code.

This might be not the case in the future anymore, if all compilers will
share the same back end. And this will be the case if I understood the
Phoenix project correctly.

Andre

[Herfried K. Wagner [MVP]]

Andre,

"Andre Kaufmann" <an*********************@t-online.deschrieb:

>Well, optimization is primarily performed by the JIT compiler nowadays
and not by the compiler used to emit the IL. Optimization on JIT-level
can be more powerful because it can keep the machine's characteristics in
mind. Inlining, for example, is typically performed by the JIT compiler
in .NET.

[...]

But the JIT compiler has to be fast, so that startup time/runtime isn't
decreased that much.

That's true. In some situation creating a native image of the IL image may
be a solution. This can be archieved using the "ngen.exe" tool which comes
with the .NET Framework. The resulting native image is placed in the NIC
(Native Image Cache), which is part of the GAC (Global Assembly Cache). In
addition, the JIT compiler performs caching, which means that native
versions of methods etc. are cached and reused. This will reduce overhead
when calling a certain method more than once.

And IMHO it currently can do only local optimizations. High level
optimizations, like removing complete code parts or function calls, are
still the task of the compiler itself.

Sure, the compiler can do some optimizations. However, the potential
optimizations a JIT compiler can perform are more evolved than those of the
compiler. Nevertheless, some sompilers provide different optimizations.
The VB compiler, for example, supports disabling of certain checks which
will result in fewer IL instructions but will also reduce security.

I believe that the whole performance debate misses the point:

..NET is a platform that is most suitable for writing user mode applications
in which performance and real-time behavior are not really important. On
the other hand, C and C++ are optimized for writing system applications
(kernel mode, heavy interaction with hardware, etc.).

Although C++ can be used to write applications similar to those commonly
written in VB/C#, the latter programming languages are more suitable for
this purpose (library support, designer support, IDE support, abstraction).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert[MVP]]

Herfried,

Please (you know what I want to write)

Cor

[Jeff Gaines]

On 31/12/2007 in message <uI*************@TK2MSFTNGP06.phx.gblHerfried
K. Wagner [MVP] wrote:

>On the other hand, C and C++ are optimized for writing system applications
(kernel mode, heavy interaction with hardware, etc.).

I would love to go back to pure C, but I would like a decent IDE and drag
and drop creation of forms. Is there anything like that available nowadays?

--
Jeff Gaines

[Herfried K. Wagner [MVP]]

"Cor Ligthert[MVP]" <no************@planet.nlschrieb:

Please (you know what I want to write)

Sorry, I don't know what you want to tell me...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Tom Shelton]

On 2007-12-30, Jon Skeet C# MVP <sk***@pobox.comwrote:

CBFalconer <cb********@yahoo.comwrote:

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.

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.

I'm not sure why people discount mono all the time. Mono works and is
being used - for real applications. No, it is not 100% compatible with
MS's implementation - but, it is pretty close.

--
Tom Shelton

[Randy Howard]

On Mon, 31 Dec 2007 11:38:13 -0600, Tom Shelton wrote
(in article <#i**************@TK2MSFTNGP03.phx.gbl>):

On 2007-12-30, Jon Skeet C# MVP <sk***@pobox.comwrote:

>CBFalconer <cb********@yahoo.comwrote:

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

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.

I'm not sure why people discount mono all the time. Mono works and is
being used - for real applications. No, it is not 100% compatible with
MS's implementation - but, it is pretty close.

On what percentage of the platforms for which a standard (pick a
flavor) C or C++ implementation is available?


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Mr. Arnold]

Randy Howard wrote:

On Mon, 31 Dec 2007 11:38:13 -0600, Tom Shelton wrote
(in article <#i**************@TK2MSFTNGP03.phx.gbl>):

>On 2007-12-30, Jon Skeet C# MVP <sk***@pobox.comwrote:

>I'm not sure why people discount mono all the time. Mono works and is
being used - for real applications. No, it is not 100% compatible with
MS's implementation - but, it is pretty close.

On what percentage of the platforms for which a standard (pick a
flavor) C or C++ implementation is available?

This is another poster out of comp.programming that you should just
simply ignore him as he too is an old retired, mind you, fossil that's
not in the game any more.

[Jeff Gaines]

On 01/01/2008 in message <uM**************@TK2MSFTNGP06.phx.gblMr.
Arnold wrote:

>This is another poster out of comp.programming that you should just simply
ignore him as he too is an old retired, mind you, fossil that's not in the
game any more.

Happy New Year to you too :-)

Some of the best products in their class have been produced by people who
do not have to price their time in to them.

--
Jeff Gaines