By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,184 Members | 1,162 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,184 IT Pros & Developers. It's quick & easy.

C++ vs. C# vs. Assembly Language

P: n/a
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the overall
performance?

And does anyone code in assembly language anyway??

Thanks.

Nov 15 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Hi,

Assembly language in the form of x86 assembly would seldom be used to
develop a desktop or distributed type application, it is more suited to
system level OS or embedded software for microcontrollers etc. Though well
written Assembly would outperform most compiled languages, if the system is
relying on database access the database becomes the bottle neck so the
Assembly code would not make much difference. Assembly would also carry a
sever overhead on development time due to the complexity and lack of object
oriented constructs.

With regard to C# and unmanaged C++, well I think that this is really a case
of your preference in languages. However, in my opinion, C# will drastically
short-circuit your development time and help provide a more robust system.
The performance penalty incurred by running in a managed system is not that
significant inlight of the benefits gained from garbage collection,
structured exception handling etc. On the other hand managed C++ provides
many of the benefits of C# in terms of development time and code security
while still enabling you to use the C++ libraries you are used to. IMHO, the
major catch with managed C++ is the fact that managed C++ is not verifiable
by the CLR therefore not all code is necessarily secure, while C# allows you
to make the decision as to whether you writing 100% safe and verifiable code
or you are prepared to forfeited verifiability and use unsafe code.

If your reference to Assembly was actually a reference to the IL code, in
that case I believe that it is quite feasible to generate a application
using IL. IL would allow you to make use of features that are yet to be
exposed by some of the higher level .NET languages such as C#, while still
giving you the benefits of object oriented code and structured exception
handling etc. Once again however the IL is much more fine grained therefore
increasing the physical amount of code you will be typing and it is less
readable than C# (though the IL is very readable!).

In all cases, once there is a database involved, I believe that the
performance is largely dependant on you database and database design. And
you should choose the language that most easily translates to the business
problem you are trying to solve.

Hope this helps

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the overall performance?

And does anyone code in assembly language anyway??

Thanks.

Nov 15 '05 #2

P: n/a
As with anything, it will be dependant on the implementation.

You gain alot more than just performance in a managed runtime.

You cannot say A is better than B, you must put this into context and have
identical setups and implementation to test a particular performance area.

So I see these arguments as is unmanaged C++ better than C# as pointless,
you need to be more specific.

"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Hi,

Assembly language in the form of x86 assembly would seldom be used to
develop a desktop or distributed type application, it is more suited to
system level OS or embedded software for microcontrollers etc. Though well
written Assembly would outperform most compiled languages, if the system is relying on database access the database becomes the bottle neck so the
Assembly code would not make much difference. Assembly would also carry a
sever overhead on development time due to the complexity and lack of object oriented constructs.

With regard to C# and unmanaged C++, well I think that this is really a case of your preference in languages. However, in my opinion, C# will drastically short-circuit your development time and help provide a more robust system.
The performance penalty incurred by running in a managed system is not that significant inlight of the benefits gained from garbage collection,
structured exception handling etc. On the other hand managed C++ provides
many of the benefits of C# in terms of development time and code security
while still enabling you to use the C++ libraries you are used to. IMHO, the major catch with managed C++ is the fact that managed C++ is not verifiable by the CLR therefore not all code is necessarily secure, while C# allows you to make the decision as to whether you writing 100% safe and verifiable code or you are prepared to forfeited verifiability and use unsafe code.

If your reference to Assembly was actually a reference to the IL code, in
that case I believe that it is quite feasible to generate a application
using IL. IL would allow you to make use of features that are yet to be
exposed by some of the higher level .NET languages such as C#, while still
giving you the benefits of object oriented code and structured exception
handling etc. Once again however the IL is much more fine grained therefore increasing the physical amount of code you will be typing and it is less
readable than C# (though the IL is very readable!).

In all cases, once there is a database involved, I believe that the
performance is largely dependant on you database and database design. And
you should choose the language that most easily translates to the business
problem you are trying to solve.

Hope this helps

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the

overall
performance?

And does anyone code in assembly language anyway??

Thanks.


Nov 15 '05 #3

P: n/a
Hi Mr Tickle,

Maybe I misunderstand your response here, but I do not believe that I ever
stated A is better than B. If I did I assure you it was entirely
unintentional. I merely tried to give a brief overview comparison of
Assembly, IL, C#, managed and unmanaged C++. And clearly state in conclusion
that the language chosen should be the language that suites the solution.

Regards

Chris Taylor

"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
As with anything, it will be dependant on the implementation.

You gain alot more than just performance in a managed runtime.

You cannot say A is better than B, you must put this into context and have
identical setups and implementation to test a particular performance area.

So I see these arguments as is unmanaged C++ better than C# as pointless,
you need to be more specific.

"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Hi,

Assembly language in the form of x86 assembly would seldom be used to
develop a desktop or distributed type application, it is more suited to
system level OS or embedded software for microcontrollers etc. Though well written Assembly would outperform most compiled languages, if the system

is
relying on database access the database becomes the bottle neck so the
Assembly code would not make much difference. Assembly would also carry a sever overhead on development time due to the complexity and lack of

object
oriented constructs.

With regard to C# and unmanaged C++, well I think that this is really a

case
of your preference in languages. However, in my opinion, C# will

drastically
short-circuit your development time and help provide a more robust system. The performance penalty incurred by running in a managed system is not

that
significant inlight of the benefits gained from garbage collection,
structured exception handling etc. On the other hand managed C++ provides many of the benefits of C# in terms of development time and code security while still enabling you to use the C++ libraries you are used to. IMHO,

the
major catch with managed C++ is the fact that managed C++ is not

verifiable
by the CLR therefore not all code is necessarily secure, while C# allows

you
to make the decision as to whether you writing 100% safe and verifiable

code
or you are prepared to forfeited verifiability and use unsafe code.

If your reference to Assembly was actually a reference to the IL code, in that case I believe that it is quite feasible to generate a application
using IL. IL would allow you to make use of features that are yet to be
exposed by some of the higher level .NET languages such as C#, while still giving you the benefits of object oriented code and structured exception
handling etc. Once again however the IL is much more fine grained

therefore
increasing the physical amount of code you will be typing and it is less
readable than C# (though the IL is very readable!).

In all cases, once there is a database involved, I believe that the
performance is largely dependant on you database and database design. And you should choose the language that most easily translates to the business problem you are trying to solve.

Hope this helps

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the

overall
performance?

And does anyone code in assembly language anyway??

Thanks.



Nov 15 '05 #4

P: n/a
It was to the original poster, sorry, just got in the wrong reply thing.

"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:OC**************@tk2msftngp13.phx.gbl...
Hi Mr Tickle,

Maybe I misunderstand your response here, but I do not believe that I ever
stated A is better than B. If I did I assure you it was entirely
unintentional. I merely tried to give a brief overview comparison of
Assembly, IL, C#, managed and unmanaged C++. And clearly state in conclusion that the language chosen should be the language that suites the solution.

Regards

Chris Taylor

"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
As with anything, it will be dependant on the implementation.

You gain alot more than just performance in a managed runtime.

You cannot say A is better than B, you must put this into context and have
identical setups and implementation to test a particular performance area.
So I see these arguments as is unmanaged C++ better than C# as pointless, you need to be more specific.

"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Hi,

Assembly language in the form of x86 assembly would seldom be used to
develop a desktop or distributed type application, it is more suited to system level OS or embedded software for microcontrollers etc. Though well written Assembly would outperform most compiled languages, if the system is
relying on database access the database becomes the bottle neck so the
Assembly code would not make much difference. Assembly would also
carry
a sever overhead on development time due to the complexity and lack of

object
oriented constructs.

With regard to C# and unmanaged C++, well I think that this is really
a
case
of your preference in languages. However, in my opinion, C# will

drastically
short-circuit your development time and help provide a more robust system. The performance penalty incurred by running in a managed system is not

that
significant inlight of the benefits gained from garbage collection,
structured exception handling etc. On the other hand managed C++ provides many of the benefits of C# in terms of development time and code security while still enabling you to use the C++ libraries you are used to.
IMHO, the
major catch with managed C++ is the fact that managed C++ is not

verifiable
by the CLR therefore not all code is necessarily secure, while C#
allows you
to make the decision as to whether you writing 100% safe and
verifiable code
or you are prepared to forfeited verifiability and use unsafe code.

If your reference to Assembly was actually a reference to the IL code,

in that case I believe that it is quite feasible to generate a
application using IL. IL would allow you to make use of features that are yet to be exposed by some of the higher level .NET languages such as C#, while

still giving you the benefits of object oriented code and structured exception handling etc. Once again however the IL is much more fine grained

therefore
increasing the physical amount of code you will be typing and it is less readable than C# (though the IL is very readable!).

In all cases, once there is a database involved, I believe that the
performance is largely dependant on you database and database design. And you should choose the language that most easily translates to the business problem you are trying to solve.

Hope this helps

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
> Just wondering,
>
> What do you think the difference in performance would be between
>
> (1.) Compiled C#
> (2.) Compiled C++
> (3.) and Assembly Language
>
> And how would the mix be if some if any of these languages had to hit > against a SQL Server database
>
> And would the differences be more or less different is you had to use > ASP.NET?
>
> I guess, what I am asking is how would Assembly Language affect the
overall
> performance?
>
> And does anyone code in assembly language anyway??
>
> Thanks.
>
>
>



Nov 15 '05 #5

P: n/a
After I posted I realized that might be what happened. I apologize for the
hastiness of my post!

Regards

Chris Taylor

"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:eT**************@tk2msftngp13.phx.gbl...
It was to the original poster, sorry, just got in the wrong reply thing.

"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:OC**************@tk2msftngp13.phx.gbl...
Hi Mr Tickle,

Maybe I misunderstand your response here, but I do not believe that I ever
stated A is better than B. If I did I assure you it was entirely
unintentional. I merely tried to give a brief overview comparison of
Assembly, IL, C#, managed and unmanaged C++. And clearly state in conclusion
that the language chosen should be the language that suites the solution.
Regards

Chris Taylor

"Mr.Tickle" <Mr******@mrmen.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
As with anything, it will be dependant on the implementation.

You gain alot more than just performance in a managed runtime.

You cannot say A is better than B, you must put this into context and have identical setups and implementation to test a particular performance area.
So I see these arguments as is unmanaged C++ better than C# as pointless, you need to be more specific.

"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> Assembly language in the form of x86 assembly would seldom be used to > develop a desktop or distributed type application, it is more suited to > system level OS or embedded software for microcontrollers etc. Though well
> written Assembly would outperform most compiled languages, if the system is
> relying on database access the database becomes the bottle neck so
the > Assembly code would not make much difference. Assembly would also carry
a
> sever overhead on development time due to the complexity and lack of
object
> oriented constructs.
>
> With regard to C# and unmanaged C++, well I think that this is really a case
> of your preference in languages. However, in my opinion, C# will
drastically
> short-circuit your development time and help provide a more robust

system.
> The performance penalty incurred by running in a managed system is
not that
> significant inlight of the benefits gained from garbage collection,
> structured exception handling etc. On the other hand managed C++

provides
> many of the benefits of C# in terms of development time and code

security
> while still enabling you to use the C++ libraries you are used to.

IMHO, the
> major catch with managed C++ is the fact that managed C++ is not
verifiable
> by the CLR therefore not all code is necessarily secure, while C# allows you
> to make the decision as to whether you writing 100% safe and verifiable code
> or you are prepared to forfeited verifiability and use unsafe code.
>
> If your reference to Assembly was actually a reference to the IL code, in
> that case I believe that it is quite feasible to generate a application > using IL. IL would allow you to make use of features that are yet to be > exposed by some of the higher level .NET languages such as C#, while

still
> giving you the benefits of object oriented code and structured exception > handling etc. Once again however the IL is much more fine grained
therefore
> increasing the physical amount of code you will be typing and it is less > readable than C# (though the IL is very readable!).
>
> In all cases, once there is a database involved, I believe that the
> performance is largely dependant on you database and database
design.
And
> you should choose the language that most easily translates to the

business
> problem you are trying to solve.
>
> Hope this helps
>
> Chris Taylor
>
>
>
> "nospam" <n@ntspam.com> wrote in message
> news:%2*****************@tk2msftngp13.phx.gbl...
> > Just wondering,
> >
> > What do you think the difference in performance would be between
> >
> > (1.) Compiled C#
> > (2.) Compiled C++
> > (3.) and Assembly Language
> >
> > And how would the mix be if some if any of these languages had to

hit > > against a SQL Server database
> >
> > And would the differences be more or less different is you had to use > > ASP.NET?
> >
> > I guess, what I am asking is how would Assembly Language affect

the > overall
> > performance?
> >
> > And does anyone code in assembly language anyway??
> >
> > Thanks.
> >
> >
> >
>
>



Nov 15 '05 #6

P: n/a
Ok, let's say there was this Mr. Perfect Coder who could type 1000 words per
minute and not make a single mistake.

What would the performance be of Assembly Language against C# and C++?
2 time faster, 4 times faster, 10 times faster?
Would it be fair to say that like 20% of the code make up 80% of the
execution time?
And since the Database would be a possible bottle neck in an ASP.NET
application, say for instance a shopping cart, could assembly language be
used in some form or another or somewhere to help the overall speed of the
web site in processing web based orders?

Thanks.


"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Hi,

Assembly language in the form of x86 assembly would seldom be used to
develop a desktop or distributed type application, it is more suited to
system level OS or embedded software for microcontrollers etc. Though well
written Assembly would outperform most compiled languages, if the system is relying on database access the database becomes the bottle neck so the
Assembly code would not make much difference. Assembly would also carry a
sever overhead on development time due to the complexity and lack of object oriented constructs.

With regard to C# and unmanaged C++, well I think that this is really a case of your preference in languages. However, in my opinion, C# will drastically short-circuit your development time and help provide a more robust system.
The performance penalty incurred by running in a managed system is not that significant inlight of the benefits gained from garbage collection,
structured exception handling etc. On the other hand managed C++ provides
many of the benefits of C# in terms of development time and code security
while still enabling you to use the C++ libraries you are used to. IMHO, the major catch with managed C++ is the fact that managed C++ is not verifiable by the CLR therefore not all code is necessarily secure, while C# allows you to make the decision as to whether you writing 100% safe and verifiable code or you are prepared to forfeited verifiability and use unsafe code.

If your reference to Assembly was actually a reference to the IL code, in
that case I believe that it is quite feasible to generate a application
using IL. IL would allow you to make use of features that are yet to be
exposed by some of the higher level .NET languages such as C#, while still
giving you the benefits of object oriented code and structured exception
handling etc. Once again however the IL is much more fine grained therefore increasing the physical amount of code you will be typing and it is less
readable than C# (though the IL is very readable!).

In all cases, once there is a database involved, I believe that the
performance is largely dependant on you database and database design. And
you should choose the language that most easily translates to the business
problem you are trying to solve.

Hope this helps

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the

overall
performance?

And does anyone code in assembly language anyway??

Thanks.


Nov 15 '05 #7

P: n/a
Assembly language would win, followed by compiled C++ for windows (COM),
followed by .NET. The C++ in .NET works a bit better with some algorythms,
while C# works better with some.

Performance is not the sole matrix in development, however. When you
consistently error on the side of performance, you often end up with a
solution that is less maintainable, which is generally more costly.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************** ********************
Think Outside the Box!
************************************************** ********************
"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the overall performance?

And does anyone code in assembly language anyway??

Thanks.

Nov 15 '05 #8

P: n/a
I think it's also reasonable to imagine in the not-too-distant future that
unmanaged applications will not even be allowed to run under Windows except
in a compatibility sandbox of some kind, so ultimately, security wins out
over performance.
Nov 15 '05 #9

P: n/a
Disclaimer: I am going out on a limb here so please be kind. :)

What you are asking is not easily quantifiable for the arbitrary case. But
lets take a concrete example of a Bresenham line drawing routine. Assuming
your Mr. Perfect coder is equally proficient and has expert skills in
Assembly, C++ and C#, the Assembly implementation would definately out
perform the C++ routine, which inturn out perform a corresponding C#
routine. This would be the case for any CPU intesive routine such as a JPEG
or MPEG encoder/decoder. The performance difference would be dependent on
the processor, however I believe even an expert Assembly programmer would
require multiple itterations to fully optimize the routine that therefore
requiring much more development time to complete the task, most likely the
initial Assembly version would only be slightly better than the C++ version.
The Assembly version will not only be faster it will most likely also
require less memory.

The example I have given here are for a routine that is possible executed
1000's, 100000's even 1000000's times per second so the difference of a few
clock cycles really makes a difference. However when accessing a database I
believe if the code is written by Mr. Perfect coder the DB access is going
to be the bottle neck so a few clock cycles on the processing would not make
much difference. I doubt it is possible to access a normal relational
database millions of times per second so the cycles in code do not make a
real diffence when networks and harddisks are in the equation. However if
you are reading data from a database and then doing a FFT on the data once
again the focus has shifted to the CPU intesive task and Assembly might be
the most performant implementation however a FFT in Assembly is a real
nightmare and I believe could be more than triple the development time of a
C++ implementation. However this would not warrent using Assembler to access
the data from the database, since ultimately you would be making a call to a
API function from dblib or OCI which whether you call it from C++, C# or
Assembly it is not going to execute any faster.

Use the right tool for the job.

CPU intensive tasks requiring highest possible throughput -> Assembly
Constrained Memory such as PICKs or AVRs -> Assembly
Low level kernel mode drivers ->
Assembly/C
Portable efficient source code with performance as priority -> C/C++
Secure robust
-> C#
Most other types of
-> C++/C#

With C# and C++ having the highest level of maintainability. OK, what ever I
have neglected to say I am sure others will fill in.

Hope this helps, if not try give a concrete example of what you want to do
and maybe someone can give you a more exact answer.

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Ok, let's say there was this Mr. Perfect Coder who could type 1000 words per minute and not make a single mistake.

What would the performance be of Assembly Language against C# and C++?
2 time faster, 4 times faster, 10 times faster?
Would it be fair to say that like 20% of the code make up 80% of the
execution time?
And since the Database would be a possible bottle neck in an ASP.NET
application, say for instance a shopping cart, could assembly language be
used in some form or another or somewhere to help the overall speed of the
web site in processing web based orders?

Thanks.


"Chris Taylor" <ch*************@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Hi,

Assembly language in the form of x86 assembly would seldom be used to
develop a desktop or distributed type application, it is more suited to
system level OS or embedded software for microcontrollers etc. Though well written Assembly would outperform most compiled languages, if the system

is
relying on database access the database becomes the bottle neck so the
Assembly code would not make much difference. Assembly would also carry a sever overhead on development time due to the complexity and lack of

object
oriented constructs.

With regard to C# and unmanaged C++, well I think that this is really a

case
of your preference in languages. However, in my opinion, C# will

drastically
short-circuit your development time and help provide a more robust system. The performance penalty incurred by running in a managed system is not

that
significant inlight of the benefits gained from garbage collection,
structured exception handling etc. On the other hand managed C++ provides many of the benefits of C# in terms of development time and code security while still enabling you to use the C++ libraries you are used to. IMHO,

the
major catch with managed C++ is the fact that managed C++ is not

verifiable
by the CLR therefore not all code is necessarily secure, while C# allows

you
to make the decision as to whether you writing 100% safe and verifiable

code
or you are prepared to forfeited verifiability and use unsafe code.

If your reference to Assembly was actually a reference to the IL code, in that case I believe that it is quite feasible to generate a application
using IL. IL would allow you to make use of features that are yet to be
exposed by some of the higher level .NET languages such as C#, while still giving you the benefits of object oriented code and structured exception
handling etc. Once again however the IL is much more fine grained

therefore
increasing the physical amount of code you will be typing and it is less
readable than C# (though the IL is very readable!).

In all cases, once there is a database involved, I believe that the
performance is largely dependant on you database and database design. And you should choose the language that most easily translates to the business problem you are trying to solve.

Hope this helps

Chris Taylor

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the

overall
performance?

And does anyone code in assembly language anyway??

Thanks.



Nov 15 '05 #10

P: n/a
If so, MS will rather make their .net framework sit at the most bottom level
and get out of the win32 api totally. wouldn't that be even faster for the
managed applications?

btw, is Longhorn built in this fashion? LOL.
"Keith Patrick" <ri*******************@hotmail.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...
I think it's also reasonable to imagine in the not-too-distant future that
unmanaged applications will not even be allowed to run under Windows except in a compatibility sandbox of some kind, so ultimately, security wins out
over performance.

Nov 15 '05 #11

P: n/a
Imagine that! And that goes onto a situation where viruses would have to be
digitally signed before they did any damage to your computer...

I can't wait :o)
"Keith Patrick" <ri*******************@hotmail.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...
I think it's also reasonable to imagine in the not-too-distant future that
unmanaged applications will not even be allowed to run under Windows except in a compatibility sandbox of some kind, so ultimately, security wins out
over performance.

Nov 15 '05 #12

P: n/a
This may be speculation but here it is anyway...

http://www.winsupersite.com/faq/longhorn.asp

Q: So what's changing from a developer's standpoint?
A: In the technology generations leading up to Longhorn, Microsoft has been
moving to a .NET-based managed code environment, and the Longhorn generation
will finally mark a clean split with the Win32 APIs of the past. That is,
Win32 will be in maintenance mode, and all new development will occur with
managed .NET APIs. One such API, Avalon, forms the basis for the new Desktop
Compositing Engine (DCE) in Longhorn that replaces GDI and GDI+. Another,
called Aero, provides APIs for the new user interface. All of the new
Longhorn APIs will utilize the XML Application markup language (XAML) to
make Longhorn more accessible to developers than ever before. The idea is to
significantly reduce the number of APIs and make the APIs more standardized.
Today, there are over 76,000 Win32 APIs, and countless wrappers. With
Longhorn, Microsoft hopes to reduce the API set to 8,000 to 10,000.

Another significant change in Longhorn involves device drivers. In the past,
Microsoft allowed customers to use non-signed drivers, which helped
compatibility, but caused stability problems. No more: In Longhorn, users
hoping to take advantage of the system's exciting new capabilities will only
be able to use signed drivers.

Developers interested in Longhorn should examine the Visual Studio .NET
"Whidbey" release, currently in beta, which includes a XAML visual designer.
In October, at the PDC in Los Angelese, Microsoft will provide developers
with the first public release of its Longhorn Software Developer Kit (SDK),
which will include developer-accessible UI components and behaviors.
"Keith Patrick" <ri*******************@hotmail.com> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...
I think it's also reasonable to imagine in the not-too-distant future that
unmanaged applications will not even be allowed to run under Windows except in a compatibility sandbox of some kind, so ultimately, security wins out
over performance.

Nov 15 '05 #13

P: n/a
Back to the original question:

Think of C as a high level compiler. Using pointer arithmetic, you can get
very close to the speed of optimized Assembler code just using C.

Notice I said "optimized." The C compiler does literally hundreds of
mechanical optimizations. Some of these optimizations are to keep the
pipeline full in a particular CPU architecture. Loops are unrolled.
Methods are inlined. It is very complex, and it takes an expert to come
anywhere near close to the speed of C using Assembly language. The general
rule is, if you can read it, it isn't optimized.

C++ is an OO extension of C, sort of. When you add OO, you add virtual
tables to functions, memory management overhead, etc. Things you need for
more high level programming. This slows things down somewhat. Still, if
you were to create the same constructs in Assembler, you couldn't do any
better. OO is there to help people deal with complexity. Assembler adds
tremendous complexity to even the simplest of tasks.

Because Assembler is so difficult to optimize by hand, and because it makes
things more complex, almost anything you write in assembler is going to be
SLOWER than the equivalent C++, unless you are maybe using it to optimize
one tiny portion of your program, or unless you are working without any
budget and time constraints.

Now to C#.

C# is a compiled language. The compiler is a JIT compiler, so it doesn't do
all the optimizations that a C++ optimizing compiler can. There just isn't
time. But it does a pretty darn good job. If you are using "safe" code,
that will limit your overall speed. However, if you can use unsafe code,
pointer arithmetic in particular, you'll find that C# is blazingly fast.

Some numbers:

I've been playing around with a program for solving the Rubik's Cube using
brute force. I wrote it in Java, C# using safe code, and C# using pointers,
each one faster than the last.

C# using pointers: 6x
C# using safe code: 3x
Java (Sun 1.4) using code optimized for speed: 1x

I haven't written it in C/C++, but seeing how much faster it is than Sun
Java for this particular task, I have to think it is getting in the same
ballpark.

"nospam" <n@ntspam.com> wrote in message
news:%2*****************@tk2msftngp13.phx.gbl...
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
(2.) Compiled C++
(3.) and Assembly Language

And how would the mix be if some if any of these languages had to hit
against a SQL Server database

And would the differences be more or less different is you had to use
ASP.NET?

I guess, what I am asking is how would Assembly Language affect the overall performance?

And does anyone code in assembly language anyway??

Thanks.

Nov 15 '05 #14

P: n/a
Jason Smith <ja***@nospam.com> wrote:
Some numbers:

I've been playing around with a program for solving the Rubik's Cube using
brute force. I wrote it in Java, C# using safe code, and C# using pointers,
each one faster than the last.

C# using pointers: 6x
C# using safe code: 3x
Java (Sun 1.4) using code optimized for speed: 1x

I haven't written it in C/C++, but seeing how much faster it is than Sun
Java for this particular task, I have to think it is getting in the same
ballpark.


I'd be interested to see the code you're using there - C# and Java are
roughly the same speed in tests I've done. C# certainly isn't 3 times
as fast "in general".

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #15

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Jason Smith <ja***@nospam.com> wrote:
Some numbers:

I've been playing around with a program for solving the Rubik's Cube using brute force. I wrote it in Java, C# using safe code, and C# using pointers, each one faster than the last.

C# using pointers: 6x
C# using safe code: 3x
Java (Sun 1.4) using code optimized for speed: 1x

I haven't written it in C/C++, but seeing how much faster it is than Sun
Java for this particular task, I have to think it is getting in the same
ballpark.


I'd be interested to see the code you're using there - C# and Java are
roughly the same speed in tests I've done. C# certainly isn't 3 times
as fast "in general".


How about Prolog? If you want fast brute-force searches...

www.ai.uga.edu/mc/courses.html

Nov 15 '05 #16

P: n/a
Did you use the sever optimized Java? In my tests it is substantially
faster than .Net. (The default client Java was slower than .Net, I wonder
why they still ship both.) Also in my test Java beat C++ because it did
some clever inlining.

It would be interesting to get some idea as to why you see the differences.

Anthony

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Jason Smith <ja***@nospam.com> wrote:
Some numbers:

I've been playing around with a program for solving the Rubik's Cube using brute force. I wrote it in Java, C# using safe code, and C# using pointers, each one faster than the last.

C# using pointers: 6x
C# using safe code: 3x
Java (Sun 1.4) using code optimized for speed: 1x

I haven't written it in C/C++, but seeing how much faster it is than Sun
Java for this particular task, I have to think it is getting in the same
ballpark.


I'd be interested to see the code you're using there - C# and Java are
roughly the same speed in tests I've done. C# certainly isn't 3 times
as fast "in general".

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #17

P: n/a
<"Anthony Berglas" <aberglas at frontsys (a spam free .com)>> wrote:
Did you use the sever optimized Java? In my tests it is substantially
faster than .Net. (The default client Java was slower than .Net, I wonder
why they still ship both.)
The client JVM starts up faster and is generally better for short-
running processes. The server JVM is generally better for long-running
processes.
Also in my test Java beat C++ because it did
some clever inlining.

It would be interesting to get some idea as to why you see the differences.


It really depends on exactly what you're doing. For some operations,
the .NET JIT will beat the HotSpot JIT hands down - and for some
operations, the reverse is true. They have some pretty radically
different assumptions, to start with - HotSpot will progressively JIT
with more and more optimisations as it sees one section of code being
used more and more, whereas the .NET JIT is a "one off" JIT. Sometimes
one way works better, sometimes the other does.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.