Compile time of C++ vs C#...

Main Page | Report this Page

Computers Forum Index » Computer Compilers » Compile time of C++ vs C#...

Page 1 of 1

Compile time of C++ vs C#...

Author

Message

Shirsoft...

Posted: Tue Sep 01, 2009 8:15 pm

Guest

Hi,

I am curious to know why C# code much faster than a similar sized C++
code. How does MSIL help? Does having a common base class like object
help in reducing compile times?

Thanks,
Shireesh
[The optimizer is usually the slowest part of a compiler and I would guess that
MSIL offers fewer opportunities than native code. -John]

Marco van de Voort...

Posted: Wed Sep 02, 2009 9:49 am

Guest

On 2009-09-01, Shirsoft <shirsoft at (no spam) gmail.com> wrote:

Quote:

I am curious to know why C# code much faster than a similar sized C++
code. How does MSIL help? Does having a common base class like object
help in reducing compile times?

Which C++ compiler? Does it support precompiled headers?

Quote:

[The optimizer is usually the slowest part of a compiler and I would guess that
MSIL offers fewer opportunities than native code. -John]

I'd bet on not parsing include files and not restarting the compiler binary
for every compilation unit.

Hans-Peter Diettrich...

Posted: Wed Sep 02, 2009 5:23 pm

Guest

Shirsoft schrieb:

Quote:

I am curious to know why C# code much faster than a similar sized C++
code. How does MSIL help? Does having a common base class like object
help in reducing compile times?

The less ambiguous syntax, simplified preprocessor and true precompiled
header files (assemblies) speed up C# compilation.

Quote:

[The optimizer is usually the slowest part of a compiler and I would guess that
MSIL offers fewer opportunities than native code. -John]

ILASM also doesn't have to create code for an horrible instruction set
(e.g. x86), has no register allocation pressure or instruction ordering
requirements. All this is done by the JIT compiler.

DoDi

BGB / cr88192...

Posted: Thu Sep 03, 2009 12:16 am

Guest

"Shirsoft" <shirsoft at (no spam) gmail.com> wrote in message

Quote:

I am curious to know why C# code much faster than a similar sized C++
code. How does MSIL help? Does having a common base class like object
help in reducing compile times?

invoking my experience as a compiler writer, I can give a fairly solid
guess:
the parser.

basically, in C and C++, a non-trivial amount of time and effort goes into
getting the code parsed (in my case, parser-related tasks are the majority
of the total time).

the main reason for this: headers.

now, in a language like C#, there are no headers or inclusion.
instead, it is possible to pool everything, and essentially process the
entire assembly at once, and the parser manages to work, initially, with an
incomplete understanding of the language (apparently, I am not entirely
certain how it works though...).

my guess is that it potentially uses 2 passes to do parsing:
a first pass to basically figure out all of the declarations (the top-level
structure for the assembly, skipping over function contents, ...);
a second pass to basically parse all of the code (at this point, it knowing
the top-level structure, so it can employ an exact parser).

the first pass may not actually do a full parser (just guessing here), but
may rather use a heuristic/approximate parser, where it looks for items of
interest (via pattern matching) but ignores everything else.

I partially guess this by noting that C# imposes a few restrictions on the
syntax similar to those I employ for my automated header-generation tools,
which similarly use a pattern-matching parser strategy (it does not parse
the full syntax, rather it looks for things which look like declarations,
and I constrain the declarations such that the tool finds them).

noting that MS's stuff uses pattern-matching at the machine code level,
little is to say they don't do similarly for processing C# syntax as well.

hence, much faster parsing.

at this point, it can do whatever, and spew out the bytecode.
I don't suspect all that much work is done at this point (judging from my
compiler, it is very possibly just a few sorts of micro-optimizations, and
more or less flattening the AST's into bytecode).

Quote:

Thanks,
Shireesh
[The optimizer is usually the slowest part of a compiler and I would guess
that
MSIL offers fewer opportunities than native code. -John]

judging from MSVC's ASM output on x64, well, their optimizer is not exactly
the best around...

basically, I infer that it doesn't even figure out some really basic/obvious
things, so I have some doubts that their optimizer is exactly what is using
up a lot of the time.

what gives me this impression:
movss [rsp+20h], xmm0
movss xmm0, [rsp+20h]

be ready to see things like this, a lot...

I suspect their optimizer is unable to figure out things like, for example,
that the value of a given variable is still located in a register, ...

similarly, they seem to copy structs around via this particular gold nugget:
"
mov rsi, ...
mov rdi, ...
mov rcx, ...
rep movsb
"...

as opposed, to, say, moving the data around using registers.
granted, I have done little to test or prove that register-based moving is
faster, but I would think it would be.

for example, for a 16 byte struct:
movups xmm0, [...]
movups [...], xmm0

(or 'movaps', if it can be determined that the memory is aligned).

actually, apparently many of their optimizations are not so much about
generating highly optimized code, but rather in turning off things that are
rather questionable and serve to do little more than eat clock cycles
("well, who knows, maybe a user will do a division by zero and expect to get
a nice little status code from errno...").

my guess is that, for whatever reason, MS is just not "that" concerned about
performance on x64.

(and, I have noticed that my code manages to run maybe 2x-3x slower than x86
and gcc, from what I can tell...).

so, yeah, I am left doubting that this is where most of the compile-time is
going.

Stephen Horne...

Posted: Thu Sep 03, 2009 5:15 am

Guest

On Tue, 1 Sep 2009 13:15:35 -0700 (PDT), Shirsoft <shirsoft at (no spam) gmail.com>
wrote:

Quote:

Maybe, but I would have thought templates have a lot to answer for WRT
compile times in C++. C# has generics, but they probably use a
relatively simple model - the generic is compiled separately, but a
closure-like structure is used to fill in instance parameters. C++
templates are more like a kind of broken Haskell that gets interpreted
at compile-time to generate new code.

Obviously Haskell can be compiled, and templates could in principle be
compiled in much the way that many (most?) scripting languages are
compiled to a virtual machine model these days even when used
interactively. I dare say recent compilers do a lot to optimise
template handling. Still, I expect there's a fair amount of overhead
there just from using the standard library. And if you have a template
library that's prone to bloat, of course, you have a slow build
because of all the template instantiations that are being generated
and optimised.

Olivier Lefevre...

Posted: Fri Sep 04, 2009 3:41 am

Guest

You may be comparing apples to oranges. Managed languages like C# and
Java running on a VM offer two kinds of compilers: a
source-to-bytecode compiler that is called by the user and one or more
bytecode-to-native code compilers (often called JIT compilers) that
are under the control of the VM. The former (by design) perform next
to no optimizations while the latter may do so. The C++ compiler is
more akin to an optimizing JIT compiler than it is to the bytecode
compiler.

-- O.L.

Page 1 of 1

All times are GMT The time now is Mon Nov 23, 2009 6:55 pm Computers Forum Index