Re: GC performance - GC fragility

"Jolyon Smith" wrote

A compiler does a job that never changes - it translates source code
into executable code.

Not anymore--it evaluates your source code and determines, based on that and
other factors (target cpu, optimization settings, debugging settings, etc.)
what code it should emit. Update the compiler and the emitted code may
change without any change in the 'source'.

A good compiler is one
that produces a better output or produces the same output faster.

or that understands how to compile higher level expressions, such as foreach
(compiler: take care of all the required casting for me), generics
(compiler: consider this a template and generate actual source when and how
you need to), or garbage collection (compiler: add the necessary code to
manage memory deallocations for me).

A garbage collector never knows what it might have to do and should do
things differently depending on the type of application, the
architecture and any other number of factors that the GC itself is
unable to determine. i.e. a one-size fits all solution is the only one
that can fly.

That's a lot like saying that a graphics card can't work because it can't
possibly know what you want to depict. It's simply the challenge that this
specialized area needs to continue addressing. To claim them as unsolvable
is simply a man will never fly type statement.

there will always be that overhead, and that overhead can ALWAYS be
taken out by using DMM.

So long as the system remains simple enough that that's within human
capability. But take the example of modern fighter aircraft: the pilot's
controls no longer connect to any control surface directly; instead they're
interpreted by a computer as instructions for how _it_ should fly the plane.
The craft is too unstable for a human pilot to fly it. Like it or not,
that's the way software is going as well. The price for increased complexity
and capability is reliance on smarter subsystems.

But you didn't get to choose - you just say "I need an edit box". The
annoying implementation details (which one, how to use it) are handled
by the runtime.

A GC takes those decisions (in terms of memory management obviously, not
edit) away from the person best placed to make them, and instead co-opts
a committee that hopes to yield appropriate decisions for everyone
submitting a request to that committee.

And that's the crux of the argument: is the individual programmer really
always in the best place to decide how memory should be handled, or should
the runtime system--which has knowledge of the runtime conditions that the
programmer cannot know, take up this job?

Truth is, the longer I think about it, the weirder the argument for manual
memory management becomes, because the truth is that all we're fighting
about is virtual memory anyway. Request memory from Windows, you don't get a
pointer to anything real, but rather the equivilent of a hat check--a number
that you can hand to Windows who can find your 'memory' for you: something
that might be located anywhere in windows actual data address space (not the
virtual space your program sees), or may not even be loaded in memory at
all. We're already out of the actual memory management business.

All we're talking about now is a wrapper layer with a simplified interface.
Actual memory management left the building years ago.

Well, by definition a sound card or graphics card can't be specialized
either. They have no idea what you're output means. But seen from a
different angle sound is sound, graphics is graphics, and memory is memory.

bobD


.

Relevant Pages

  • Re: WWDC -- MacBook Pro?
    ... ....but once the program has loaded it into its program memory, ... boundaries, int16 are aligned on 2 byte boundaries, int32 are ... people are always able to come up with the compiler ... Case B, same glass, same ice code water.  ...
    (comp.sys.mac.system)
  • Re: Javas performance far better that optimized C++
    ... The compiler is extremely stupid. ... no memory leaks are guaranteed. ... However I have GC in my .NET programming. ... "C.9.1 Automatic Garbage Collection ...
    (comp.lang.cpp)
  • Re: Compiler and How It Handles Scope
    ... VB's compiler isn't really "state of the art" David. ... memory, no matter how many processes map the code into their virtual address ... words, no real distinction is made between Public/Private variables, or even ... > Modules can contain Public and Private variables, ...
    (microsoft.public.vb.winapi)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... that later locks the same mutex. ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Re: Delphi for XCode?
    ... memory, and that it moves blocks when they are promoted to the next generation, ... Of course you can have the compiler execute e.g. an array of events. ... But what does COM have to do with MY interfaces? ... Mono is using Boehm as well. ...
    (borland.public.delphi.non-technical)
Loading