4 ms·

> You avoid allocations wherever possible If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about al

by progman 10y ago

> You avoid allocations wherever possible If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast that garbage collections don't really matter in most cases. Consider SBCL (compiled Common Lisp) which is almost as performant as Java and C++. http://benchmarksgame.alioth.debian.org/u64q/lisp.html http://benchmarksgame.alioth.debian.org/u64q/lisp.html I used to develop software in C and C++ for many years, and a garbage collector was the thing I wanted the most. GC-free programming is unnecessarily tough in most cases, except you desperately need it for games and embedded systems.

bluetomcat 10y ago
You must worry about allocations anytime you write CPU-bound software which wants to maximise the output per clock cycle. Granted, most software isn't like that, but it's certainly not only games and embedded software on tiny systems.
adrianN 10y ago
Because allocating something on the stack means adding a something to a pointer and puts the object somewhere that is likely to be in the cache during the function and allocating something on the heap usually takes a tree traversal and puts the object far away from the other stuff you might be using. Also, using numbers from a benchmark game is not representative of the performance of real world applications. If you look at the code, you'll find that it's written in a style that avoids heap objects and GC wherever possible. Forcing heap allocation is what makes Java slightly slower than C in many cases.
wott 10y ago
> If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast What? RAM is not fast at all, the latencies have almost not improved in 20 years (compared to the improvement of other subsystems like the CPU, of course).
GFK_of_xmaspast 10y ago
RAII and smart pointers go a long way towards eliminating the need for GC in c++.
- pjmlp 10y ago
  True, but usually one doesn't have control over the code others write to force them to use such tools.

by progman 10y ago

bluetomcat 10y ago

You must worry about allocations anytime you write CPU-bound software which wants to maximise the output per clock cycle. Granted, most software isn't like that, but it's certainly not only games and embedded software on tiny systems.

adrianN 10y ago

Because allocating something on the stack means adding a something to a pointer and puts the object somewhere that is likely to be in the cache during the function and allocating something on the heap usually takes a tree traversal and puts the object far away from the other stuff you might be using. Also, using numbers from a benchmark game is not representative of the performance of real world applications. If you look at the code, you'll find that it's written in a style that avoids heap objects and GC wherever possible. Forcing heap allocation is what makes Java slightly slower than C in many cases.

wott 10y ago

> If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast What? RAM is not fast at all, the latencies have almost not improved in 20 years (compared to the improvement of other subsystems like the CPU, of course).

GFK_of_xmaspast 10y ago

RAII and smart pointers go a long way towards eliminating the need for GC in c++.

pjmlp 10y ago
True, but usually one doesn't have control over the code others write to force them to use such tools.