A
Arne Vajhøj
Scott said:
And you do not think 2 guys with 40 years of C++ experience would
know that ??
Arne
And you do not think 2 guys with 40 years of C++ experience would
know that ??
Arne
A
Arne Vajhøj
Richard said:
Don't.
0-60% is more likely to see.
Arne
A
Arne Vajhøj
Andre said: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".
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.
So because a guy can not remember the compiler switches he used on
a project 4-5 years then you do not believe the project existed.
Hmmmm. I guess I have been working on bunch of non existing projects
in my time.
Arne
A
Arne Vajhøj
CBFalconer said:
And what is ECMA-334 ?
You consider Windows a small area ??
Hmmmm.
No it does not.
Since it is unclear what exactly caused the lack of
performance.
All indications is that something was not ported properly.
I do not blame the dev team for that. Brand new technology
introduced late in a project with a deadline is not a recipe
for success.
But considering it wisdom may be stretching it !
Arne
A
Arne Vajhøj
Andre said:
He did explain that it was many years ago and that he obviously
could not provide the code (which should not even be necesarry
to state BTW).
And it is a free world.
He can post his opinion on .NET performance.
People can ask if he has a code example.
And he can explain that it was business code.
And then readers must summarize all experiences posted and
make their own conclusions.
But you can not demand proof.
Arne
A
Arne Vajhøj
Andre said:
1) I doubt that could give a x60 difference
2) C++ programmers usually check compiler switches
3) You can not serious expect him to remember the project settings
on a project 4-5 years ago.
Arne
A
Arne Vajhøj
Michael said:
Stuff like generic collections for simple data types has provides
huge performance improvements, but not in the x60 range.
I have not seen big improvements in the JIT (32 bit).
As Jon has posted a couple of times, then different language
sometimes requires different way of doing things.
Arne
A
Arne Vajhøj
Richard said:
I think he is talking about small percentages not x60.
C++ in .NET variation supports so called mixed mode with both native
code and .NET managed code. I don't think you can sue MS for that.
But it is a rather complex matter.
Arne
A
Arne Vajhøj
Liz said:
Why not ?
Do you think people should only post their experience if they
can release the source code the experience is based on ?
Arne
A
Arne Vajhøj
Randy said:
Win/x86
MacOS X/x86
MacoS X/PPC
Solaris/SPARC
Linux/x86
Linux/PPC
Linux/IA-64
Linux/IBM mainframe
are the supported ones I think.
It has also been build on some other platforms like *BSD/x86,
Solaris/x86 etc..
Arne
R
Richard Heathfield
Arne Vajhøj said:
[elsethread]
Yes, I understand that. Nevertheless, there are so many tools in the shed
already. That's why producers of new tools have to impress their potential
customers quickly.
(Presumably you mean 40 years total.)
Ask 10 programmers to write an app in any language, and I doubt the result
will be good.
It was C++, translated into "managed C++".
Agreed!
[elsethread]
Yes, I understand that. Nevertheless, there are so many tools in the shed
already. That's why producers of new tools have to impress their potential
customers quickly.
(Presumably you mean 40 years total.)
Ask 10 programmers to write an app in any language, and I doubt the result
will be good.
It was C++, translated into "managed C++".
Agreed!
R
Richard Heathfield
Arne Vajhøj said:
Um, quite so. [1]
But the point bears addressing anyway. The suggestion seems to be
"eliminate the recursion by replacing it with iteration, and the code will
speed up". But of course programming languages are all about expressive
power. The original code (in "native" C++) expressed inherently recursive
algorithms recursively, and was thus easy and quick to write. Translating
it into an iterative equivalent for the sake of .Net would have been
(relatively) difficult and slow, and therefore expensive, and there was no
guarantee that the performance gain would have been sufficient to justify
the expense of carrying out the conversion. What's more, the code would
have ended up as a *poorer* expression of the algorithms we were using,
and thus it would have been harder (read: more expensive) to maintain.
[1] Just one nit - one of the "guys" (and the brighter of the two, in fact)
was actually a gal.
Um, quite so. [1]
But the point bears addressing anyway. The suggestion seems to be
"eliminate the recursion by replacing it with iteration, and the code will
speed up". But of course programming languages are all about expressive
power. The original code (in "native" C++) expressed inherently recursive
algorithms recursively, and was thus easy and quick to write. Translating
it into an iterative equivalent for the sake of .Net would have been
(relatively) difficult and slow, and therefore expensive, and there was no
guarantee that the performance gain would have been sufficient to justify
the expense of carrying out the conversion. What's more, the code would
have ended up as a *poorer* expression of the algorithms we were using,
and thus it would have been harder (read: more expensive) to maintain.
[1] Just one nit - one of the "guys" (and the brighter of the two, in fact)
was actually a gal.
R
Richard Heathfield
Arne Vajhøj said:
Er, this might be a misunderstanding. I was not claiming here that .Net
/is/ typically 60x slower. I was merely claiming that, if it /were/, I
think it would still be widely used even so (because it has "Microsoft"
written on the box).
Er, this might be a misunderstanding. I was not claiming here that .Net
/is/ typically 60x slower. I was merely claiming that, if it /were/, I
think it would still be widely used even so (because it has "Microsoft"
written on the box).
R
Richard Heathfield
Arne Vajhøj said:
Well, I hope so. Still, he did say "major issues with performance".
Yeah, I know - I was teasing him a little, that's all.
The problem is that we live in a sound-bite world, where complex matters
are invariably over-simplified. The original claim, "I've only ever heard
one objection to .Net", smacked (to me, at least) of over-simplification,
hence this entire sub-thread. I hope that at least one person's horizons
have been stretched a little as a result.
Well, I hope so. Still, he did say "major issues with performance".
Yeah, I know - I was teasing him a little, that's all.
The problem is that we live in a sound-bite world, where complex matters
are invariably over-simplified. The original claim, "I've only ever heard
one objection to .Net", smacked (to me, at least) of over-simplification,
hence this entire sub-thread. I hope that at least one person's horizons
have been stretched a little as a result.
L
Liz
I think posting 30 messages on a topic positing an implausible 60x
performance deficit while providing **NO** detail about the code is
ridiculous ... when the poster further says he doesn't really care about the
code, what do you think we should conclude, Arne? That he's making a
sincere effort to contribute something worthwhile to the dialogue? Don't
think so ....
R
Richard Heathfield
Liz said:
What you *should* conclude is really up to you. But what you *could*
conclude with a great deal of accuracy is that I started off by making a
simple and perfectly valid reply to someone else's article, and that the
discussion then grew out of all proportion to the importance of the
original point, as it so often does on Usenet.
What you *should* conclude is really up to you. But what you *could*
conclude with a great deal of accuracy is that I started off by making a
simple and perfectly valid reply to someone else's article, and that the
discussion then grew out of all proportion to the importance of the
original point, as it so often does on Usenet.
M
Mr. Arnold
Liz said:
The only place King Little Richard is appreciated in is by his (MS
posse)is in comp.programming. He is a (MS basher) King Little Richard is
and the Supremes. But even his Supremes have better sense to not show.
You should drop him like a hot rock.
R
Randy Howard
If the above list of platforms where you can use Mono is accurate, and
I have no reason to doubt you, then it is /much/ less portable than
either C or C++.
Of the above list, I am only familiar with comments on its
functionality and compatibility with two of them relative to .NET on
Windows platforms, and they have been so far that it is not baked, and
does not allow relatively complex .NET apps written for Windows
platforms to move over easily, or in some cases at all.
Since my impression is that Mono is by no means "baked" yet, and that
Microsoft isn't exactly not developing .NET anymore either, Mono is
chasing a moving target somewhat, so I don't find this particularly
surprising, and don't fault Mono itself. It's an understandable
problem.
M
Miha Markic
You can't actually compare the portability of .net against C(++). .net is
more than just a language, it is a framework, while C(++) you are talking
about is a language + small library.
Furthermore, even those aren't exactly portable due to different library
implementations, right?
Here steps in Silverlight 2.0....
R
Richard Heathfield
Miha Markic said:
Er, why not?
Nevertheless, if you require Functionality F to be available on Platform P,
and are not prepared to go to the trouble of porting a development tool to
Platform P yourself, you have no option but to choose a development tool
that is available on Platform P. If Platform P has a C (or C++)
implementation available that provides the infrastructure (i.e. sufficient
features) for implementing F but no .Net implementation, then you can
implement Functionality F on Platform P using C (or C++), but you cannot
use .Net to do the same thing. Now range over all P (for a given F), and
you have a relative portability measure between C (or C++) and .Net - thus
demonstrating that you can in fact compare the portability of .Net against
C (or C++). But see below.
Both C and C++ are defined by ISO standards. C compilers that conform to
ISO/IEC 9899:1990 are available on a very, very wide range of platforms,
including not just desktop and middle range machines, but also top-end
mainframes and tiny little embedded systems. To a lesser extent, this is
also true of C++. For hosted environments, this also includes the standard
library specified by ISO.
Having said all that, in one sense you are right, because .Net offers
vastly more functionality than either ISO C or ISO C++ (flashy graphics,
mouse-talk, and the like - stuff that you /can/ do in C or C++ but only by
using vendor-supplied or third-party libraries that are not part of the
standard language), and so in that sense they're not really comparable. It
would be like comparing a chainsaw with a machine shop. You can do a lot
more with the machine shop, but on the other hand it's a lot harder to
carry around!
<snip>