Re: GC performance - GC fragility

"Jolyon Smith" wrote

It's very easy to contrive simple examples that "prove" the benefit of
GC by removing "extraneous" implementation details from code allowing it
to "concentrate" on the business requirements.

QED <g>. Yes, that's the argument in a nutshell, and it has nothing to do
with the specifics of what the business use is--only that that use gets
allowed to occupy more of the code, and more of the programmer's attention.

It absolutely makes it impossible
to decide whether it is more efficient.

Obviously not--but then the non-GC example isn't very clear about its
efficiency either--we'd have to examine the underlying compiled code to
really make a judgment about that. But the argument you're making also
applies to _any_ coding technique or tool at a greater level of abstraction
than machine code, and was used in the same way against operating systems
(faster and more efficient to speak to the hardware directly), device
virtualization via drivers, higher level languages, runtimes, OO design,
layered architectures, etc.

And that argument is valid at every step along the way, but still keeps
losing in practice because of three historical trends:
--the tools keep getting better, reducing their inefficiency (cost-of-use).
--the absolute penalty for inefficiency keeps going down due to increased
computing power, and
--the complexity of programming challenges keeps going up

So on the whole the penalty for using a system that handles some of the
technical details keeps going down, and the need for such systems keeps
going up. GC is simply such a tool, and not qualitatively different in any
way from the others we already use.

I need a loop - what's the best construct of loop to employ given what
*I* know about the data being looped over - something that the COMPILER
_CANNOT_ know.

In Delphi, a for i := 0 to x loop is commonly adjusted by the compiler to
for x downto 0 because the compiler sees that as more efficient. The bottom
line is that unless you're handcoding everything in assembler directly to
the hardware, you're not taking care of all the technical details yourself.

Equally the compiler cannot know what memory allocation/deallocation is
going to be optimal.

Possibly not. But it can know what is generally considered 'best practice'
at the current state-of-the-art, and do that consistently and perfectly.

Now it may be that (going back to my historical vectors)
(1)--any particular GC implementation is not yet good enough to meet a
specific program need
(2)--the hardware on which the system has to run makes that inefficiency
painful, and
(3)--the programmer has ample time to manually specify what a programming
environment could be doing for him, or else the problems of (1) and (2) are
so severe that it actually makes business sense to pay for the manual
approach.

I have seen plenty that have required tweaks to implementation details
to improve performance. Thankfully, with code that contains those
details, the details are available to be changed.

This would argue that points (1) and (2) may be true for that program,
though in my own experience algorithmic adjustments to programs are much
more commonly required than minor tweaks to technical details in how the
algorithm is implemented. That is, if a probram preforms poorly, I want to
see whether its doing the wrong things before I check if it's doing things
corrrectly.

And I doubt that "improved expressiveness" would help address
any bugs either

That's the first I've heard anyone claim that code expressiveness had
nothing to do with quality. Here's what I'd consider more the current
'conventional wisdom' of our time:
"So the expressiveness argument is quite compelling if you simply view it as
a code generation metric: the more expressive the language, the more code it
can generate for you for the same number of characters typed. That means you
do your job faster, and more importantly, with fewer errors."
http://higherlogics.blogspot.com/2007/05/expressiveness-whats-all-fuss.html

Much harder to fix is an error in the "expression of the business
problem" itself.

Agreed--so why spend time on a problem (memory management) that the customer
doesn't really care about at all, especially if the system could handle it
for you?

"business problems" (and in point of fact - software is never about "the
business problem". Software is - by definition - about "the problem of
devising software to address a business NEED").

Whereas memory management concerns are about solving an IT technical issue,
and one that is just as subject to automation as any business problem we
attack.

Some people seem to think we should be able to write the spec and let
the computer figure out the CPU instructions needed to meet the spec
(and how often do problems arise because of errors in the spec? how
many times has the translation from Business Problem to Software
actually IDENTIFIED those errors?)

Why wouldn't a spec compiler simply find those errors faster? And yes, I do
think that that's the way things are going.

This notion that "we can write software without having to bother
ourselves with the troublesome details of writing software" is hogwash

As above: this has been the common cry against every advance in CS since the
invention of assembler.

GC is a tool--no more, no less. And while it certainly isn't right for
everything, it has been around for 40 years now
(http://www.ibm.com/developerworks/java/library/j-jtp10283/), and it seems
to be getting pretty good.


.NET newsgroup. Anyone prosthelytising (sp?) GC here must be
assumed to be doing so because they think it is intrinsically "A Good
Thing" and wish to see it added to Delphi).

For evidence that that's not the case, see Craig's response to my post. And
as for me, while I do think GC is a good thing, I have a lot of other
changes I'd like to see in D.win32 or win64 that would be much higher on my
list.

bobD


.

Relevant Pages

  • C language now truly universal
    ... C language now truly universal ... a C compiler for z/VSE (an ... IBM mainframe operating system), and would like to ... Has a documented programming API. ...
    (comp.lang.c)
  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: why qwerty keyboard has NOT been used in ColorForth
    ... Forth minus source code and compiler and with a key table interpreter ... that could show dissasembled native opcodes and named Forth word ... The way Chuck put it, he wanted to explore the notion of reduced size ... It is what is known as bare metal programming. ...
    (comp.lang.forth)
  • Re: Legit Warnings or not
    ... vs. equality) are parts of the semantics, ... rather than to rely on the compiler. ... I want Ada to remain a universal programming ...
    (comp.lang.ada)