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
Dec 28 '07
184 6797
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
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
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
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
Jeff,
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.
If that is really so, you should good follow the advices which by instance
Jon has given in this thread.
An average VB6 application should be much slower in overall throughput then
a .Net application (with the exception of applications using heavily late
binding in whatever way). A C application is not comparable because that can
even be software which is not real meant for Net like by instance drivers.
Cor
Jeff Gaines <wh*********@newsgroups.nospamwrote:
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.
If you can provide *evidence* of that, you'll be the first to do so in
this thread...
--
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
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>
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>
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
"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
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.
"Jeff Gaines" <wh*********@newsgroups.nospamwrote in message
news:xn****************@msnews.microsoft.com...
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
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.
"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."
On Dec 29, 9:42*pm, Richard Heathfield <r...@see.sig.invalidwrote:
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. 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.
>
--
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
On Dec 29, 11:08*pm, Richard Heathfield <r...@see.sig.invalidwrote:
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/
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.
>
--
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
On Dec 30, 9:12*am, CBFalconer <cbfalco...@yahoo.comwrote:
"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. *
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.
>
--
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 fromhttp://www.teranews.com- Hide quoted text -
- Show quoted text -
spinoza1111 said:
On Dec 29, 9:42 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>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
>
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
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
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
On 29/12/2007 in message <MP*********************@msnews.microsoft.com>
Jon Skeet [C# MVP] wrote:
>Jeff Gaines <wh*********@newsgroups.nospamwrote:
>>>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.
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?
--
Jeff Gaines
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/
"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
Jeff Gaines <wh*********@newsgroups.nospamwrote:
<snip>
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?
Calculating factorials is fairly useless, and sorting tends to be done
by library calls rather than in your own code.
The suggestions by Stephen Howe are fairly reasonable though - although
I suspect they'll be IO limited rather than CPU limited. Mind you,
that's often likely to be the case in real code as well...
I'm happy to do the C# - it would be good to see VB6, C and C++
solutions. It would also be nice to look at the complexity/readability
of the solutions afterwards, as well as the performance...
--
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 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
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. :)
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/
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/
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
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
"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.
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
Bart C <bc@freeuk.comwrote:
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
o The languages all being MS - no (see http://boo.codehaus.org for example)
<aside>
I remember looking at boo, what feels like an age ago, and you just
reminded me of it... re-reading the manifesto, it is interesting how
much of this is now addressed in C# 2 (generators/yield), C# 3
(functional approach, var, etc), and MSBuild (compilation pipeline).
OK, some others aren't there (duck typing [although it has always been
in VB], syntactic macros [unlikely to appear]), and the return-type
inference isn't really there (except for lambdas) - but there is
definitely some convergence...
</aside>
Marc
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 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
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
"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.
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
"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/>
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
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/>
Herfried,
Please (you know what I want to write)
Cor
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
"Jeff Gaines" <wh*********@newsgroups.nospamschrieb:
>>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?
This can be done using VC++ in C mode, for example. You can define forms as
Win32 dialog resources and use these resources in your Win32 C projects.
Note that most of the Win32 API is C-based and does not require C++. I am
sure that similar tools exist for other forms packages too.
--
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]" <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/>
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
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
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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: thecrow |
last post by:
Alright, what the hell is going on here?
In the following code, I expect the printed result to be:
DEBUG: frank's last name is burns.
Instead, what I get is:
DEBUG: frank's last name is...
|
by: Brandon J. Van Every |
last post by:
What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have...
|
by: mike420 |
last post by:
I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro...
|
by: Reed L. O'Brien |
last post by:
I see rotor was removed for 2.4 and the docs say use an AES module
provided separately... Is there a standard module that works alike or
an AES module that works alike but with better encryption?...
|
by: Philippe C. Martin |
last post by:
I apologize in advance for launching this post but I might get enlightment
somehow (PS: I am _very_ agnostic ;-).
- 1) I do not consider my intelligence/education above average
- 2) I am very...
|
by: Dario |
last post by:
The following simple program behaves differently
in Windows and Linux .
#include <stdexcept>
#include <iostream>
#include <string>
using namespace std;
class LogicError : public logic_error {...
|
by: Sarah Tanembaum |
last post by:
Beside its an opensource and supported by community, what's the fundamental
differences between PostgreSQL and those high-price commercial database (and
some are bloated such as Oracle) from...
|
by: Neal |
last post by:
Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
quite good article.
|
by: typingcat |
last post by:
First of all, I'm an Asian and I need to input Japanese, Korean and so
on. I've tried many PHP IDEs today, but almost non of them supported
Unicode (UTF-8) file.
I've found that the only Unicode...
|
by: Midnight Java Junkie |
last post by:
Dear Colleagues:
I feel that the dumbest questions are those that are never asked. I have
been given the opportunity to get into .NET. Our organization has a
subscription with Microsoft that...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |