C++ vs. C# vs. Assembly Language

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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 said:
Just wondering,

What do you think the difference in performance would be between

(1.) Compiled C#
Click to expand...

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++
Click to expand...

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
Click to expand...

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

???


And does anyone code in assembly language anyway??
Click to expand...

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/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp.
Thanks.
Click to expand...

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

Hope this helps,
Stefan
 
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
 
Stefan Simek said:
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.


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.


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


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
Click to expand...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.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.
 
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.
 
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
 
After I posted I realized that might be what happened. I apologize for the
hastiness of my post!

Regards

Chris Taylor
 
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.
 
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!
**********************************************************************
 
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.
 
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
 
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
 
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
 
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.
 
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)
 
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.
 
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.
 
Jason Smith said:
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.
Click to expand...

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