C++ vs. C# vs. Assembly Language

[nospam]

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.

[Stefan Simek]

"nospam" <[e-mail]> wrote in message
news:#b*************@tk2msftngp13.phx.gbl...

Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
C# gets compiled to MSIL, which is a machine independent code. The code is
JIT-ted (just-in-time compiled) during runtime, into native code.
(2.) Compiled C++
The C++ compiler generates different output depending on if it's used with
or without .NET (/clr compiler option). With the /clr option, the output is
much the same as from C# (except for much better managed-unmanaged interop
capabilities and much worse code readability). Without it, it gets compiled
directly to native assembly code.
(3.) and Assembly Language
What do you mean by assembly language? If you mean x86 assembler, then I
really think it's by far the worst way to go. If you mean MSIL, I guess it
would be pointless to write code in it, because it's pretty "high-level" and
you probably couldn't write better code than that generated by C# or other
compiler...

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??
Well, so I guess you are talking the x86 assembly... First, I don't really
understand the way you would like to access SQL Server and even less ASP.NET
from it, which requires managed environment (assembler isn't and never could
be). As for the speed of the code, you would probably find out that your
assembly code is slower than the one generated by any of the compilers, as
the compilers know the ways how does the processor execute instructions,
cache data, etc. Cache misses, page faults and similar things are the
biggest performance hogs in the modern world. It's hard to write code in
assembly with all such things in mind, and a compiler will make all these
things easily. Not to even mention things such as object oriented
programming, which you'll never be able to do in assembly. For more
reference, see
http://msdn.microsoft.com/library/de...anagedcode.asp.

Thanks.

Please don't post to so many groups. By my opinion, this question belongs to
microsoft.public.dotnet.framework.performance.

Hope this helps,
Stefan

[Stefan Simek]

"nospam" <[e-mail]> wrote in message
news:#b*************@tk2msftngp13.phx.gbl...

Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
C# gets compiled to MSIL, which is a machine independent code. The code is
JIT-ted (just-in-time compiled) during runtime, into native code.
(2.) Compiled C++
The C++ compiler generates different output depending on if it's used with
or without .NET (/clr compiler option). With the /clr option, the output is
much the same as from C# (except for much better managed-unmanaged interop
capabilities and much worse code readability). Without it, it gets compiled
directly to native assembly code.
(3.) and Assembly Language
What do you mean by assembly language? If you mean x86 assembler, then I
really think it's by far the worst way to go. If you mean MSIL, I guess it
would be pointless to write code in it, because it's pretty "high-level" and
you probably couldn't write better code than that generated by C# or other
compiler...

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??
Well, so I guess you are talking the x86 assembly... First, I don't really
understand the way you would like to access SQL Server and even less ASP.NET
from it, which requires managed environment (assembler isn't and never could
be). As for the speed of the code, you would probably find out that your
assembly code is slower than the one generated by any of the compilers, as
the compilers know the ways how does the processor execute instructions,
cache data, etc. Cache misses, page faults and similar things are the
biggest performance hogs in the modern world. It's hard to write code in
assembly with all such things in mind, and a compiler will make all these
things easily. Not to even mention things such as object oriented
programming, which you'll never be able to do in assembly. For more
reference, see
http://msdn.microsoft.com/library/de...anagedcode.asp.

Thanks.

Please don't post to so many groups. By my opinion, this question belongs to
microsoft.public.dotnet.framework.performance.

Hope this helps,
Stefan

[Chris Taylor]

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" <[e-mail]> 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.

[Chris Taylor]

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" <[e-mail]> 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.

[Daniel O'Connell]

"Stefan Simek" <si**********@kascomp.nospam.sk> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...

"nospam" <[e-mail]> wrote in message
news:#b*************@tk2msftngp13.phx.gbl...

Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
C# gets compiled to MSIL, which is a machine independent code. The code is
JIT-ted (just-in-time compiled) during runtime, into native code.

(2.) Compiled C++

The C++ compiler generates different output depending on if it's used with
or without .NET (/clr compiler option). With the /clr option, the output

is much the same as from C# (except for much better managed-unmanaged interop
capabilities and much worse code readability). Without it, it gets compiled directly to native assembly code.

(3.) and Assembly Language
What do you mean by assembly language? If you mean x86 assembler, then I
really think it's by far the worst way to go. If you mean MSIL, I guess it
would be pointless to write code in it, because it's pretty "high-level"

and you probably couldn't write better code than that generated by C# or other
compiler...

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

Well, so I guess you are talking the x86 assembly... First, I don't really
understand the way you would like to access SQL Server and even less

ASP.NET from it, which requires managed environment (assembler isn't and never could be). As for the speed of the code, you would probably find out that your
assembly code is slower than the one generated by any of the compilers, as
the compilers know the ways how does the processor execute instructions,
cache data, etc. Cache misses, page faults and similar things are the
biggest performance hogs in the modern world. It's hard to write code in
assembly with all such things in mind, and a compiler will make all these
things easily. Not to even mention things such as object oriented
programming, which you'll never be able to do in assembly. For more
reference, see
http://msdn.microsoft.com/library/de...anagedcode.asp.
It would be possible, in theory, to access SQL server via ODBC, but it would
be a very unpleasent experiance. You can do anything in assembly that youcan
do in C++, if you are willing to spend a lot of time working on it.

Generally you would only use assembly in cases where you can beat the
compiler: rendering routines, mathmatic operations, etc. In other cases a
good compiler will always beat a human, there just really is far to much
information to handle.

Thanks.

Please don't post to so many groups. By my opinion, this question belongs

to microsoft.public.dotnet.framework.performance.

Hope this helps,
Stefan

[Daniel O'Connell]

"Stefan Simek" <si**********@kascomp.nospam.sk> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...

"nospam" <[e-mail]> wrote in message
news:#b*************@tk2msftngp13.phx.gbl...

Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
C# gets compiled to MSIL, which is a machine independent code. The code is
JIT-ted (just-in-time compiled) during runtime, into native code.

(2.) Compiled C++

The C++ compiler generates different output depending on if it's used with
or without .NET (/clr compiler option). With the /clr option, the output

is much the same as from C# (except for much better managed-unmanaged interop
capabilities and much worse code readability). Without it, it gets compiled directly to native assembly code.

(3.) and Assembly Language
What do you mean by assembly language? If you mean x86 assembler, then I
really think it's by far the worst way to go. If you mean MSIL, I guess it
would be pointless to write code in it, because it's pretty "high-level"

and you probably couldn't write better code than that generated by C# or other
compiler...

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

Well, so I guess you are talking the x86 assembly... First, I don't really
understand the way you would like to access SQL Server and even less

ASP.NET from it, which requires managed environment (assembler isn't and never could be). As for the speed of the code, you would probably find out that your
assembly code is slower than the one generated by any of the compilers, as
the compilers know the ways how does the processor execute instructions,
cache data, etc. Cache misses, page faults and similar things are the
biggest performance hogs in the modern world. It's hard to write code in
assembly with all such things in mind, and a compiler will make all these
things easily. Not to even mention things such as object oriented
programming, which you'll never be able to do in assembly. For more
reference, see
http://msdn.microsoft.com/library/de...anagedcode.asp.
It would be possible, in theory, to access SQL server via ODBC, but it would
be a very unpleasent experiance. You can do anything in assembly that youcan
do in C++, if you are willing to spend a lot of time working on it.

Generally you would only use assembly in cases where you can beat the
compiler: rendering routines, mathmatic operations, etc. In other cases a
good compiler will always beat a human, there just really is far to much
information to handle.

Thanks.

Please don't post to so many groups. By my opinion, this question belongs

to microsoft.public.dotnet.framework.performance.

Hope this helps,
Stefan

[Mr.Tickle]

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" <[e-mail]> 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.

[Mr.Tickle]

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" <[e-mail]> 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.

[Chris Taylor]

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" <[e-mail]> 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.

[Mr.Tickle]

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" <[e-mail]> 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.
>
>
>

[Chris Taylor]

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" <[e-mail]> 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.
> >
> >
> >
>
>

[nospam]

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" <[e-mail]> 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.

[Cowboy \(Gregory A. Beamer\)]

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" <[e-mail]> 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.

[Keith Patrick]

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.

[Chris Taylor]

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" <[e-mail]> 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" <[e-mail]> 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.

[keyur shah]

Hi,

I used to work with Assembly language, and definitely the code written
in Assembly works much faster and is more compact than that generated by
any High Level Languages, or thru code generated by CLR for MSIL.

So, Assembly is best as far as performance goes. But, yes it doesnt have
that flexibility that you enjoy with the tools that helps you code,
trace, debug, finetune the applications.

Today is the world of faster processors, more memory, and sophisticated
tools.

Hope this information helps.

Keyur Shah
Verizon Communications
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[nospam]

Did you ever use Assembly to help you in speeding up your database access?

"keyur shah" <ke***@softwareklinic.com> wrote in message
news:u4*************@TK2MSFTNGP11.phx.gbl...

Hi,

I used to work with Assembly language, and definitely the code written
in Assembly works much faster and is more compact than that generated by
any High Level Languages, or thru code generated by CLR for MSIL.

So, Assembly is best as far as performance goes. But, yes it doesnt have
that flexibility that you enjoy with the tools that helps you code,
trace, debug, finetune the applications.

Today is the world of faster processors, more memory, and sophisticated
tools.

Hope this information helps.

Keyur Shah
Verizon Communications
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jeff Louie]

At some point I have done all three, but just the thought of coding a
GUI database app in assembly makes me nauseated :) C++ COM is fast, but
not for everyone. C# is going to more reliable and easier to maintain.
That said, a lot of database applications are written using drag and
drop 3GL.

Regards,
Jeff

And does anyone code in assembly language anyway??<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[warren]

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.

[Will Clark]

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.

[Jonathan Hodges]

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.

[Jason Smith]

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" <[e-mail]> 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.

[Jon Skeet [C# MVP]]

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

[Michael A. Covington]

"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

[Anthony Berglas]

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

[Jon Skeet [C# MVP]]

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