views:

920

answers:

4

I recently read a discussion regarding whether managed languages are slower (or faster) than native languages (specifically C# vs C++). One person that contributed to the discussion said that the JIT compilers of managed languages would be able to make optimizations regarding references that simply isn't possible in languages that use pointers.

What I'd like to know is what kind of optimizations that are possible on references and not on pointers?

Note that the discussion was about execution speed, not memory usage.

+3  A: 

There are some benefits of JIT compilation mentioned in Wikipedia:

JIT code generally offers far better performance than interpreters. In addition, it can in some or many cases offer better performance than static compilation, as many optimizations are only feasible at run-time:

  1. The compilation can be optimized to the targeted CPU and the operating system model where the application runs. For example JIT can choose SSE2 CPU instructions when it detects that the CPU supports them. With a static compiler one must write two versions of the code, possibly using inline assembly.
  2. The system is able to collect statistics about how the program is actually running in the environment it is in, and it can rearrange and recompile for optimum performance. However, some static compilers can also take profile information as input.
  3. The system can do global code optimizations (e.g. inlining of library functions) without losing the advantages of dynamic linking and without the overheads inherent to static compilers and linkers. Specifically, when doing global inline substitutions, a static compiler must insert run-time checks and ensure that a virtual call would occur if the actual class of the object overrides the inlined method.
  4. Although this is possible with statically compiled garbage collected languages, a bytecode system can more easily rearrange memory for better cache utilization.

I can't think of something related directly to the use of references instead of pointers.

haggai_e
One concrete big project proof was made with IronPython vs CPython. The latest versions of IronPython beat CPython in every benchmark, with a small or big margin, while retaining 100% compatbility. That's with a several years of optimisations of CPython and a young IronPython project.
Bluebird75
You haven't answered the question... "What I'd like to know is what kind of optimizations that are possible on references and not on pointers?"...
sgreeve
+3  A: 

In C++ there are two advantages of references related to optimization aspects:

  1. A reference is constant (refers to the same variable for its whole lifetime)

    Because of this it is easier for the compiler to infer which names refer to the same underlying variables - thus creating optimization opportunities. There is no guarantee that the compiler will do better with references, but it might...

  2. A reference is assumed to refer to something (there is no null reference)

    A reference that "refers to nothing" (equivalent to the NULL pointer) can be created, but this is not as easy as creating a NULL pointer. Because of this the check of the reference for NULL can be omitted.

However, none of these advantages carry over directly to managed languages, so I don't see the relevance of that in the context of your discussion topic.

hjhill
+3  A: 

In general speak, references make it possible to refer to the same object from different places.

A 'Pointer' is the name of a mechanism to implement references. C++, Pascal, C... have pointers, C++ offers another mechanism (with slightly other use cases) called 'Reference', but essentially these are all implementations of the general referencing concept.

So there is no reason why references are by definition faster/slower than pointers.

The real difference is in using a JIT or a classic 'up front' compiler: the JIT can data take into account that aren't available for the up front compiler. It has nothing to do with the implementation of the concept 'reference'.

xtofl
+1  A: 

Other answers are right.

I would only add that any optimization won't make a hoot of difference unless it is in code where the program counter actually spends much time, like in tight loops that don't contain function calls (such as comparing strings).

Mike Dunlavey