Significant GC performance penalty

[Paulo Pinto]

On Friday, 14 December 2012 at 20:33:33 UTC, H. S. Teoh wrote:
> On Fri, Dec 14, 2012 at 09:08:16PM +0100, Peter Alexander wrote:
>> On Friday, 14 December 2012 at 19:24:39 UTC, Rob T wrote:
> [...]
>> >It may be that the GC concept works far better in theory than 
>> >in
>> >practice, although due to the performance penalty 
>> >work-a-rounds,
>> >you may end up writing better performing apps because of it,
>> >however that's NOT the intention of having a GC!
>> 
>> When it comes to performance, there is always a compromise with
>> usability. Even malloc performs poorly compared to more manual
>> memory management. Even automatic register allocation by the
>> compiler can lead to poor performance.
>> 
>> The only question is where you want to draw the line between
>> usability and performance.
>
> Yeah. If you want to squeeze out every last drop of juice your 
> CPU's got
> to offer you, you could code directly in assembler, and no 
> optimizing
> compiler, GC or no GC, will be able to beat that.
>

I think it depends on what you're trying to achieve.

If coding for resource constrained processors, or taking 
advantage of
special SIMD instructions, then I agree.

On the other hand if you're targeting processors with multiple 
execution
units, instruction re-ordering, multiple cache levels, NUMA, ..., 
then it is
another game level trying to beat the compiler. And when you win, 
it will
be for a specific set of processor + motherboard + memory 
combination.

Usually the compiler is way better keeping track of all possible 
instruction
combinations for certain scenarios.

Well this is just my opinion with my compiler design aficionado 
on, some guys here might prove me wrong.

--
Paulo