gc


On Thu, Jun 23, 2011 at 07:37, Johan  Lundberg <joe...@gmail.com> wrote:
I have a novel idea concerning all manner of "helpful" memory
management, like Garbage collection (GC) and Reference counting: Drop
it, bury it, forget it.
>
Manual memory management is really not difficult. All you need to know
can be summarized on one sheet of paper. Make a few mistakes and in a
couple of days you will have figured it out. Your programs will be
fast and predictable.
>
Automatic GC starts up randomly, which is a huge problem in time
critical applications, such as in the financial markets. Someone at
Oracle told me that 98 percent of all JVM optimization investments
concerns the garbage collector. This, and the fact that automatic GC
makes programmers lazy and unaware, is a very high price for the
miniscule convenience of not having to release memory. Reference
counting is slightly better in that it is predictable but it is very
confusing to many programmers. Unless you have a very powerful
development and simulation environment it is therefore more prone to
memory leaks than manual memory management.
The same arguments can be made for programming using just
NAND gates, which can be summarized on just a post-it note.

It turns out that, compared to writing programs using NAND gates,
when I write programs in Go, I can write the program in less time,
the program is more likely to be correct, and the program is easier
to debug and fix if not.  It is true that the program is slower and
less predictable than if I'd written it using just NAND gates, and
not having to think about NAND gates probably does make me
lazy and unaware at some level.  For the programs I am writing,
the advantages of using Go outweigh the disadvantages of not
using NAND gates.

Of course, programmers and programming environments differ,
so if you find that NAND gates are a better fit for your work,
no one here is going to force you to use Go.

Russ

>>13
Wallstreet and Forex developers specifically don't use Java or other GC languages. Your so called incremental GC still has overhead and does not provide strong real-time guarantees.

Financial developers us C, C++, and recently have been doing GPGPU programming with OpenCL and CUDA.

They even optimize the geolocation of their servers to exploit latency delays between exchanges.

Things like GC, even your so called incremental GC, only serve to get in the way.

>>19
No, the rest of the sentence follows from the premise that I quoted.

Namely, just because you have not written someone that didn't include some form of buggy automatic memory management doesn't mean everyone can't write stuff that is free of buggy automatic memory management.

The rest of your post is full of similar logical fallacies based upon your experience.

>>20
Kind of hard to switch a program over to manual memory management when it comes time to optimize--usually, that involves switching to a completely different language. Belayed pessimization is the leaf of no good, and when your experience tells you that you're going to have to fucking squeeze as much performance out of the hardware as possible as part of your project's requirements, not optimizing early is madness.

Garbage collection, and GC languages will never ever be suitable for safety critical systems.

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1642624
http://spinroot.com/p10/

The Power of Ten -- Rules for Developing Safety Critical Code, IEEE Guidelines

1 Restrict to simple control flow constructs.
2 Give all loops a fixed upper-bound.
3 Do not use dynamic memory allocation after initialization.
4 Limit functions to no more than 60 lines of text.
5 Use minimally two assertions per function on average.
6 Declare data objects at the smallest possible level of scope.
7 Check the return value of non-void functions, and check the validity of function parameters.
8 Limit the use of the preprocessor to file inclusion and simple macros.
9 Limit the use of pointers. Use no more than two levels of dereferencing per expressions.
10 Compile with all warnings enabled, and use one or more source code analyzers.

At least with languages where manual memory management is the way things are done, you can pre-allocate or statically all of your buffers and set upper bounds.

Not possible with GC languages, especially considering many GC language standard library functions/methods perform dynamic memory allocation internally.

>>26
LUA is fucking garbage. LUA is known as FFOC. The Forced Flushing of Cache. Nearly every statement in LUA causes several L2 cache misses and branch mispredictions, due to the nature of LUA's ingrained tables for lookups. Not even JIT can get around this problem with LUA, because the table lookups must be there to ensure correct LUA behavior.

Game developers have pretty much abandoned LUA, as well as Python, when it comes to scripting in new games. Both languages do not scale to multiple cores and are all but useless on the in-order pipelines of DSP/VLIW/SIMT pipelines of secondary processors common on current and upcoming game consoles and handhelds.

Surprisingly, some game developers are moving back to using their own s-expression/lisp-like DSLs that generate C/C++ code that is then compiled into the application. The Uncharted series and Killzone 2 & 3 series of games on the PS3 do this, for example.