Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Baby's First Garbage Collector

journal.stuffwithstuff.com

Post reply on HN
Print view View original

21–30 of 90 posts

Re: Baby's First Garbage Collector

#21

Post by recuter »

So every once in a while I come across old timey C optimizations in the spirit of Duff's device or bit twiddling to swap variables, 'etc 'etc...

While they have a certain kind of charm to them they seem to be almost universally bested by increasingly mature compilers and complex (or virtualized) hardware.

So I'm kind of coming to the conclusion that clever pointer arithmetic games and even manual malloc/free are increasingly futile unless you're targeting embedded devices. If a young language like Go gets you at least in the same ballpark as C with a relatively immature GC and even toy implementations like the OP take you rather far these days... when is coding without a garbage collector even really defensible anymore?

I'm not trolling. I think pointer arithmetic is neat and the aforementioned "optimizations" are magical and possibly my generation has missed out on something wonderful. Seems it just isn't often practical to do that sort of thing anymore.

Edit: I'd like to stress that I wasn't talking in absolutes, and asking rather than telling. I'm not sure how to phrase my post better, made some edits nonetheless.

Re: Baby's First Garbage Collector

#23

Post by logancapaldo »

cperciva wrote: post #11
rayiner wrote: post #8

Earlier quoted context omitted.

You don't need to give up pointers, or pointer arithmetic, just the ability to obscure what a pointer points to. Casting to void does not do this (and indeed, has no run time effect at all). Metadata is associated with the pointed-to block of memory, so as long as the address is recognizable as a pointer at runtime, you can do GC. Some of the things that break GC aren't even technically valid C code. For example, say…

it's illegal to dereference a pointer past the end of an allocation. Yes, but there's a legal way to do this. reference the other two areas with offsets relative to the first area If you cast the pointers to uintptr_t, and perform your arithmetic on uintptr_t and cast your final pointer back (void * ) before using it, what you've done is perfectly legal and safe (albeit weird) since uintptr_t is an unsigned integer t…

What if it's not a DWIM compiler? I'm pretty sure (happy to be corrected) pointer integer conversions are implementation defined. Therefore casting between could perform some reversible operation that ensured round tripping worked, but does not require that ptr(a - b) == a - b even though a == int(ptr(a)) holds.

Re: Baby's First Garbage Collector

#24

Post by vinkelhake »

recuter wrote: post #21

So every once in a while I come across old timey C optimizations in the spirit of Duff's device or bit twiddling to swap variables, 'etc 'etc... While they have a certain kind of charm to them they seem to be almost universally bested by increasingly mature compilers and complex (or virtualized) hardware. So I'm kind of coming to the conclusion that clever pointer arithmetic games and even manual malloc/free are incr…

What you are asking for is essentially areas of computing where you want to get the most out of the hardware. Non-casual games is one such area. Some parts of finance is another.

I'm not sure why you are referring to it as "games". The high-level programming you can enjoy today rely on efficient low-level implementations. You might not see them, but they are still there and still being developed.

Re: Baby's First Garbage Collector

#26

Post by scott_s »

recuter wrote: post #21

So every once in a while I come across old timey C optimizations in the spirit of Duff's device or bit twiddling to swap variables, 'etc 'etc... While they have a certain kind of charm to them they seem to be almost universally bested by increasingly mature compilers and complex (or virtualized) hardware. So I'm kind of coming to the conclusion that clever pointer arithmetic games and even manual malloc/free are incr…

Someone has to implement those garbage-collected languages. If you ever want to be one of those someones, you need to learn manual memory management and raw-memory manipulation.

Re: Baby's First Garbage Collector

#27

Post by dysoco »

kerkeslager wrote: post #25
dysoco wrote: post #22

Now THIS is the kind of articles I want to see in HN. Saved for later reading, seems very interesting and well explained.

Did you see this a few weeks ago? http://patshaughnessy.net/2013/10/24/visualizing-garbage-col...

Nope, thanks for the link!

Re: Baby's First Garbage Collector

#28

Post by Someone »

rayiner wrote: post #15
cperciva wrote: post #11

Earlier quoted context omitted.

it's illegal to dereference a pointer past the end of an allocation. Yes, but there's a legal way to do this. reference the other two areas with offsets relative to the first area If you cast the pointers to uintptr_t, and perform your arithmetic on uintptr_t and cast your final pointer back (void * ) before using it, what you've done is perfectly legal and safe (albeit weird) since uintptr_t is an unsigned integer t…

Right. You could also convert a pointer to a uintptr_t, XOR it with some value, then at some later point XOR it again to get back the original address and cast it back to a pointer and dereference it, and it would be legal despite breaking GC. However, a number of things that also break GC, like your first example, also happen not to be legal C even though they'll probably work on any existing implementation.

That's very close to the classical example of code that maims pointers: the doubly linked list that uses only one 'pointer' in each node (http://www.geeksforgeeks.org/xor-linked-list-a-memory-effici...)

Re: Baby's First Garbage Collector

#29

Post by lelandbatey »

recuter wrote: post #21

So every once in a while I come across old timey C optimizations in the spirit of Duff's device or bit twiddling to swap variables, 'etc 'etc... While they have a certain kind of charm to them they seem to be almost universally bested by increasingly mature compilers and complex (or virtualized) hardware. So I'm kind of coming to the conclusion that clever pointer arithmetic games and even manual malloc/free are incr…

I was introduced to programming through python. Now that I'm in school, I've been doing most of my work in C++. I have to say, as much as I like programming in python, my knowledge of programming is made so much better because I've had to write C++. From an educational perspective, I think non-GC languages will always have a place (if only for teaching about computers).

In production environments, I don't think that any programming practice should ever need to be "defended." Non-GC languages have their ups and downs, just as GC'ed languages have their ups and downs. Saying "it's indefensible to use one over the other" feels like saying "it's indefensible to fly somewhere instead of driving there." It doesn't make sense, since each is useful for some things and not others.

Once again, when asked the question "which tool is better" my answer is "the one that's best for the job."

Post reply on HN