Re: GC performance - GC fragility

In article <47a6a225$1@xxxxxxxxxxxxxxxxxxxxxx>, Bob Dawson says...

Wrong. Code that accesses a memory address will cause that memory
address to be paged in if it is paged out.

Which means an access delay you cannot predict and have no control over, of
course.

Delay for the code needing that memory in the single thread that needs
it. In my highly scalable, multi-threaded application a GC sweep will
halt other threads that don't otherwise need to be halted.


Which is why the .NET GC is generational: so that it can limit the objects
it needs to sweep over.

Unless the GC only ever considers unreachable objects there is
redundancy and overhead. It can do things to reduce that redunancy and
overhead to a certain point, but ONLY to a certain point.

This argument brings us full circle to "these days there is anough spare
CPU and RAM to make GC workable".

But non-GC will still have an absolute advantage.


Not just real-time. Any application is at risk from this depending on
the overall load of the system it is running on.

And calling Free manually makes a program immune from system load? You keep
acting like this is a black/white issue. Clearly, expected system load needs
to be considered in any design effort.

Right, but a GC based approach is predicated on being able to set aside
such considerations to a greater or lesser degree.

Not MY straw man - this is the way that GC is sold.

In fact your almost last point in your own post sells it as such -
allowing the developer to focus on the business problem, implicitly not
being troubled by (and by definition therefore not thinking about)
system details.


I haven't seen that issue in normal business applications.

Then you haven't looked very hard or your "normal business
applications" have very limited needs indeed.

"ymmv"

:)


If you make a memory allocation request that can't be satisfied by the
generation zero cache, then you trigger a generation 0 GC sweep. Direct
cause and effect.

Thread 1 causes threads 2 - 20 to be halted by the GC. If threads 2-20
were self aware they might be thinking "WTF!? What did I do?!?"

Sure, there is a cause and effect. Part of that effect is desirable,
the rest not so much.

Like the bullet that killed Archduke Ferdinand - it had a direct effect:
it killed it's target. But I'm pretty sure the war that followed was
not an intentional, expected or desirable, consequence.

;)



Not if your ensuing allocation requests require larger blocks and your heap
is fragmented.

I free some memory. Is that memory free? Yes. No if's no but's, it's
free.

The question of any subsequent allocation is not in any way related to
whether that free memory is free.



That's your straw man.

No, it's the claimed benefit of GC. You yourself claim it, for one.


But
generally you interact with it by knowing what you're doing (, just like
interacting with FastMM)

Here's the weird thing. Fast MM "just works". I've never directly
interacted with FastMM (other than adding it to my dpr uses list), and
never had to.

It strikes me that if GC is something that "works" then I shouldn't need
to interact with it directly. If I need to interact with it directly
then it isn't working.

Your argument appears at this point to be so unstable that it looks to
have shot itself down.

;)



The whole point about GC - the thing that it hinges on to be successful
- is that it should work without you having to think about it.

That's your strawman again--that GC is somehow a diabolical attempt to take
the programmer out of programming.

It an attempt to take the systems programmer out of applications
programming, as if applications aren't systems.

But again, not MY strawman.


And as I never claimed it did--GC simply removes a lot of the grunt and rote
work.

And replaces it with a different set of grunt and rote work. Hmmm.



And as I said, the reaons for that are not A Good Thing. Come up with a
worthy example and we'll talk.

Maneuverability is inversely linked to stability,
To achieve maximum stability, modern fighters are unstable (to the point of
being humanly unflyable) by design.

You are still talking about something whose efficiency is measured by
it's ability to stay in the air in order to inflict damage and death on
an enemy.

You appear to have missed my point entirely.


If
you want a more historical example, you might consider that guns are more
complex than bows and arrows, breech loaders more complex than muzzle
loaders, repeaters more complex than single-shots

You might like to reflect on the fact that the machine gun was invented
with the specific idea and intention of REDUCING the number of deaths in
battle.

What might seem like a great, simple idea often turns out to be a
nightmare in practice.



All that said--I just filled out my Delphi survey tonight and listed it DEAD
LAST as a priority for adding to Delphi.win32.

Whew!

:D


--
JS
TWorld.Create.Free;
.

Relevant Pages

  • Re: C++ sucks for games
    ... > mistakes it is possible for a programmer to make (although of course memory ... > references and memory management is a bit of a red herring here. ... you would use smart pointers too. ...
    (comp.lang.lisp)
  • Re: ASTs in assembler
    ... Absolutely I don't mean optimizing what has written by the programmer. ... idea of the assembler being able to have a "big picture" of the source. ... Because of the amount of memory modern machines have, ... Why not read macro bodies from macro symbol table? ...
    (alt.lang.asm)
  • Re: A Silly Database Question
    ... I guess it's easy to see why it's always a can or a cylinder. ... The use of multiple platters was an attempt to increase the probability that more 'record's would be 'found'/accessed by a single head seek. ... I had one boss who said if he read one more resume of a system programmer who had invented a new VTOC manipulation program, ... They didn't want to use the generic subroutines for disk access provided by IBM which had memory sizes of thousands of bytes because they were short of 'main memmory' and it was too expensive to bump their main memory from 16Kilo-bytes. ...
    (comp.databases)
  • Re: Garbage collection
    ... and that the allocations retained ... programmer to avoid bugs in MANUALLY done memory management? ... allocated memory, no recursion, and the maximum call depth and memory ...
    (comp.lang.c)
  • Re: programi parsing question
    ... have the right to interact with each other. ... It is worth noting that static typing does not always mean that the ... the need for the programmer to write out types. ... Too bad these programming language are never used "in the industry". ...
    (comp.programming)