5 ms·

> The garbage collector has nothing to do with things like memory struct alignment. Exactly - that's my point - with garbage collectors you can't do things lik

by berkut 14y ago

> The garbage collector has nothing to do with things like memory struct alignment. Exactly - that's my point - with garbage collectors you can't do things like align to 16-byte boundaries for SSE, or so they fit in cache lines... > And garbage collector makes concurrent allocation easier, not harder. If it pre-allocates a huge amount of memory (i.e. a memory arena), yes. If it has to allocate the memory from the OS (i.e. it hasn't got any more available to the application), then it's a further painfully slow allocation. Allocating that extra memory is an extra step for the GC language (GC allocates amount at startup, but then when the program executes that isn't enough so needs to allocate more), whereas the C/C++ version can do it all in one allocation. > And garbage collection doesn't prevent stack allocation. I didn't say it didn't, I said Java did. > You seem to have no idea what you're talking about. If you say so.

barrkel 14y ago
I don't really understand why you think GCs are so limited, when you are comparing them not to the runtime heap provided by a C or C++ vendor, but instead some custom scheme. To level the playing field, you should be considering a GC specialized to the purpose. There's no reason why a GC can't allocate certain things specially, or have a specified initial heap size. And GC actually makes it easier to make better use of L1/L2 cache without needing specific optimization, because caches are nice sizes to use for generations in generational GC - they're extremely quick to collect. Saying that games and embedded systems "allocate a fixed size of memory up front and NEVER free it, re-using it instead" is almost meaningless. They are necessarily implementing their own GC or memory allocator; pretty much the definition of an allocator is something which controls how memory is reused. The only thing they've insulated themselves from is the vendor or OS's memory allocator, by writing their own allocator. This can make lots of sense when your application is all written by a single relatively small team, and has nicely understandable lifetimes for various bits of memory - games are a good example, because memory can typically be classed as existing for the entire game, a level, a frame, or a call stack. When you have such a specialized use case, it makes sense to take advantage of it. But not all, or even most, applications are like that.
- berkut 14y ago
  I'm not saying it's not theoretically possible for GC'd languages to do that, I'm just saying in my experience of some of them (Python, Lua, Java) limitations of the language in terms of how/where/when to allocate memory has limited its use significantly for the domain I work in. > Saying that games and embedded systems "allocate a fixed size of memory up front and NEVER free it, re-using it instead" is almost meaningless. I was using that as an example of being in complete control of the memory... > But not all, or even most, applications are like that. Well again, it must be the domains I've worked in, because at least when doing embedded and desktop software, it's often been a big concern.

by berkut 14y ago

barrkel 14y ago

I don't really understand why you think GCs are so limited, when you are comparing them not to the runtime heap provided by a C or C++ vendor, but instead some custom scheme. To level the playing field, you should be considering a GC specialized to the purpose. There's no reason why a GC can't allocate certain things specially, or have a specified initial heap size. And GC actually makes it easier to make better use of L1/L2 cache without needing specific optimization, because caches are nice sizes to use for generations in generational GC - they're extremely quick to collect. Saying that games and embedded systems "allocate a fixed size of memory up front and NEVER free it, re-using it instead" is almost meaningless. They are necessarily implementing their own GC or memory allocator; pretty much the definition of an allocator is something which controls how memory is reused. The only thing they've insulated themselves from is the vendor or OS's memory allocator, by writing their own allocator. This can make lots of sense when your application is all written by a single relatively small team, and has nicely understandable lifetimes for various bits of memory - games are a good example, because memory can typically be classed as existing for the entire game, a level, a frame, or a call stack. When you have such a specialized use case, it makes sense to take advantage of it. But not all, or even most, applications are like that.

berkut 14y ago
I'm not saying it's not theoretically possible for GC'd languages to do that, I'm just saying in my experience of some of them (Python, Lua, Java) limitations of the language in terms of how/where/when to allocate memory has limited its use significantly for the domain I work in. > Saying that games and embedded systems "allocate a fixed size of memory up front and NEVER free it, re-using it instead" is almost meaningless. I was using that as an example of being in complete control of the memory... > But not all, or even most, applications are like that. Well again, it must be the domains I've worked in, because at least when doing embedded and desktop software, it's often been a big concern.