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
Name:
Anonymous2011-06-26 3:20
The same could be said about the forced indentation of code.
Name:
Anonymous2011-06-26 6:53
The problem I have with proponents of GC is that they take a very militant stance against manual memory management: as if manual memory management, programming languages which feature manual memory management, and programmers who use such languages must be eradicated from the face of the Earth, as if they were some kind of disease.
This just seems highly illogical.
Name:
Anonymous2011-06-26 10:23
OH GOD HOW FUCKING HARD IS IT TO CALL free() WHEN YOU'RE FUCKING DONE WITH THE MEMORY YOU JUST malloc()'ED. VERY SIMPLE, I DON'T SEE ANY PROBLEM HERE. GOD FUCKING DAMN IT AIN'T THAT HARD WHAT THE GODDAMN FUCK.
Name:
Anonymous2011-06-26 10:34
>>4
Cycling references. Where is your free() now? Or right, I see. It is right here, in the middle of Segmentation Fault
Now go and run valgrind with x100 slowdown while I simply put #include <boehm-gc.h> and Segmentation Fault
ITT: faggots who never designed their own cache-efficient incremental garbage collector.
I can't blame ya though. You can't get a decent CS education nowadays.
Name:
Anonymous2011-06-26 13:49
>>5
Cycles are never an issue in real software where strong memory ownership rules are in place. You've obviously never written any software of any sufficient complexity.
>>8
I keep hearing about this mythical GC that isn't really all that hard to write and is nearly as fast as manual memory management without causing GC pause. I wish someone would implement it somewhere!
>>11
Can't you free/destroy things manually in Ruby? Any GC'd language worth its salt should have a way of bypassing the GC and destroying objects manually.
>>1 Automatic GC starts up randomly, which is a huge problem in time critical applications, such as in the financial markets.Now that's bullshit. Modern garbage collectors are incremental and even allow other threads/CPUs to mind their own business while collecting. Whether the JVM distributed by Oracle makes use of such a modern garbage collector is, thankfully, none of my business.
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.If you think that's all GC is about, then you are one misguided mortal. If done right, a moving (or copying) garbage collector can help decrease memory fragmentation by getting rid of the gaps created by freed objects.
Name:
Anonymous2011-06-26 19:00
I have not written something large in a manual memory language that did not include some kind of buggy slow informally specified form of automatic memory management.
Programmers are INHERENTLY lazy. If you don't give them the 'lazy' tools, they will reinvent them poorly. Evidence: half of Boost is an attempt to make up for manual memory management, and the inherent laziness of programmers means that instead of using these tools wisely, they mainly just copy memory. It is IDIOMATIC in C++ to copy memory instead of sharing it, and this is TERRIBLE problem when it comes to getting your program to do anything useful.
The simple facts of the matter are these:
- that how memory is handled has almost nothing to do with the problems we try to solve with computers. Why not explicitly manage CPU registers as well?
- that the ability to share references is essential to creating decent abstractions, and that there are a couple of well accepted ways of implementing this on modern hardware.
- that manual memory management creates unreasonable paranoia in programmers in the long term and stunts their thinking.
- that all evidence suggests that manual memory management greatly increases the defect rate of programs.
>>14
Your post sounds like a great first half of a manifesto.
Name:
Anonymous2011-06-26 19:04
>>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.
>>16 Wallstreet and Forex
Oh, you mean those people who bring unsteadiness to their own homeland's economic system for their own puny little gains by taking decisions using the 5th derivative of a time-dependant function?
How I rejoice in anticipation of the fall of the American hegemony.
>>20
In today's world where you're probably writing ruby for the web and posting about it on HN. The thing about tech bubbles is people aren't just stupid with their money, they're really fucking dumb about technology too.
>>21
Yeah... look at where the money they make comes from: a vast number of disparate sources. It's hardly disruptive.
Name:
Anonymous2011-06-26 19:18
>>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.
>>23
Cool thinly veiled superiority complex w.r.t. >>15, bro. Tell me, do you use Gentoo with your own custom compiler flags?
Humour aside, the garbage collector is seldom the bottleneck. If the programming language is too stupid to do escape analysis or to use memory efficiently, well you should have picked a better one. If the garbage collector occupies more than 0.5% of the CPU's time, then maybe you shouldn't be allocating and deallocating so many objects -- memory pools exist for a reason.
Lua gives you several good ways of optimizing memory management.
- you can provide your own manager
- you can easily create weak keys or values in tables
- the distinction between 'userdata' and 'light userdata' gives you fine control over what objects you wrote in C get garbage collected and what happens when/if they do.
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.
Name:
Anonymous2011-06-26 19:44
>>28
Haskell not following those rules is 10x safer than C++ following those rules and 10x more powerful and cheaper to develop than Ada.
you don't have to sacrifice power to safety
Name:
Anonymous2011-06-26 19:47
>>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.
Name:
Anonymous2011-06-26 19:57
Also, wrt everyone's intimate knowledge of finance programming, I know jane street uses OCaml (which is gc).
Name:
Anonymous2011-06-26 19:59
>>30 Nearly every statement in LUA causes several L2 cache misses and branch mispredictions,
DERP EVERY STATEMENT MUST BE OPTIMIZED WAT IS A BOTTLENECK?
>Not even JIT can get around this problem with LUA
um, is not LuaJIT the fastest interpreted language implementation of the day?
Nobody is claiming that you write your physics engine in Lua, just that you use it instead of XML or some other POS data serialization standard for configuration and non-real-time logic like menus and some aspects of game logic and AI.
Also, most C++ game developers I know have this really retarded idea that ALL functionality MUST HAPPEN THIS FRAME. Because they don't understand things like continuations/coroutines, they can't conceive of an algorithm that you can just pause and come back to. Like, they think the idea of a separate routine of computation is inherently tied to multithreading rather than seeing multithreading as an optimization technique only.
Low level programming is just brain-poison.
Name:
Anonymous2011-06-26 20:04
>>32
Whatever. You GC people will obviously never change, and you won't stop until all of us low-level programmers and manual-memory management aficionados have been gassed and burnt in an oven.
Name:
Anonymous2011-06-26 20:09
>>33 Whatever. You GC people will obviously never change, and you won't stop until all of us low-level programmers and manual-memory management aficionados have been gassed and burnt in an oven.
You said it.
Name:
342011-06-26 20:14
>>33
Go out of your cave. The extra cycles some systems pays for having a GC are much cheaper than hiring programmers to use nm | c++filt and addr2line.
Name:
Anonymous2011-06-26 20:28
how is the C stack not a shitty form of automatic memory management? And isn't it normal for C++ programmers to try to use its stupid mechanisms for the heap as well?
I would just like to interject for a moment. I'm not yet clear on what position >>16,23,28,30 is defending. Is he saying that garbage collection is inherently evil or is he just saying that for some applications, using a garbage collector is unwise?
Name:
Anonymous2011-06-26 20:45
>>33
>you won't stop until all of us low-level programmers and manual-memory management aficionados have been gassed and burnt in an oven.
Way to enforce Godwin's Law there buddy.
Name:
Anonymous2011-06-26 21:44
>>38
Yes, the later. Essentially, all I'm saying is that GC isn't the end-all be-all of memory management--it's not suitable for ALL scenarios. I'm tired of people pushing GC for EVERYTHING.
>>28
C and C++ are not suitable for it either. You want a language whose behaviour is always well defined, and has manual memory management.
You wouldn't use C/C++ either, just a subset of it, so why don't you just use something else? (finding such language is left as an exercise for the reader)
>>40
It's not, I agree, but not using a GC should be the exception, not the rule. I'm tired of manual memory management bugs and memory leaks, and people thinking that GCs are not needed/slow.
That said, there exist deterministic, real-time GCs that can be used in soft real-time systems, but, yes, for hard real-time systems, it's probably better to statically allocate all the memory.
The problem I have with proponents of x is that they take a very militant stance against x: as if x, y, and programmers who z must be eradicated from the face of the Earth, as if they were some kind of disease.
Name:
Anonymous2011-07-12 22:13
NAND:Niggers Against Niggers, tru Dat
Name:
Anonymous2011-07-14 4:44
>>47
Agree! There's no reason for separate stack memory, especially with modern generational GCs with amortized O(1) allocation speed. If you allocate your stack frames with your GC, you can get a bunch of other shit for free, like tail-call elimination (when compiled to continuation-passing style), closures, first-class continuations, etc.
Still, i would not overuse malloc, like some people do in cases when you can in fact just put an array on the stack / data area and be happy.
Name:
Anonymous2011-07-14 9:45
Im looking for a print function, it cant be printufu (thats japanese for printf) or any stdio function. It has to be of 2 or more parameteru (thats japanese for 2 parameters) and has be be chibi (small) sized. And has to be really kawaii (cute). Also It has to be about 10-20 bux. And you have to post documentation of it first (i want to make shure it's kawaii [cute]). And it would be nice if it came with matching input reading (WITH error handling). OH! and it CANNOT have any complicated syntax, or be made out of C. It has to be made of C++, or something like that. Also it would be nice if it was made in japan. and not in china or corea (korea) or whatever. I have found a function similar to the one im describing in sourceforge, but it was 1 parameteru, and i dont want my formatou (formatting) to touch my other things (it can get mixed up and i would not like that, plus 2 paraneters looks more kawaii)
>>67
(let ((x (list 1))
(y (list 1)))
(set-cdr! x x)
(set-car! y y)
(set-cdr! y y)
(values x y))
; => #0=(1 . #0#), #1=(#1# . #1#)
In refcounting, `x' refers to itself, its reference count will always be at least 1. Same for `y'. Congratulations, you've got a memory leak!
free_list(x);
{ free(CAR(x); free_list(CDR(x)); free(CDR(x)); }
{ /* SOME_OBJECT free'd */
free_list(CDR(x)); /* The cdr of `x' is `x' */
free(CDR(x)); }
{ /* SOME_OBJECT free'd */
{ free(CAR(x)); /* Double free */
/* Segfault */ } }
If you don't free the content, it will just loop forever. Also, y=#1=(#1# . #1#); free_list(y); will first free itself, then dereference a free'd pointer.
Name:
Anonymous2011-07-21 17:09
http://www.loper-os.org/?p=37 I see this as a convincing argument for “silicon big government.” Move garbage collection, type checking, persistence of storage, and anything else which is unambiguously necessary in a modern computing system into hardware – the way graphics processing has been moved. Forget any hypothetical efficiency boost: I favor such a change for no other reason than the fact that cementing such basic mechanisms in silicon would force people to get it right. On the first try – the way real engineers are expected to. Yes, get it right – or pay dearly.