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
