Re: [Sheflug] c++ & mem

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Al" == Alex Hudson <home [at] alexhudson.com> writes:

    >> By "efficient code" I meant things like unrolling loops by hand
    >> (Duff's device -- a compiler can _never_ get that right because
    >> compilers don't read hardware data sheets),

    Al> I really don't see why a compiler can't unroll a loop? That's
    Al> not exactly hard. I'm not really sure what the hardware data
    Al> sheet has to do with things, either.

Then go find out the history of "Duff's device."  Of course compilers
can unroll loops.  The point is that unrolling the loop optimally to
match the spec of a hardware device is something a compiler cannot do,
because it can't read the spec.  Future compilers, maybe.  Current
ones, no.

    Al> No-nos how? The idea is that the compiler does this, not the

In C++, yes.  That's what I meant by "no-no".

    Al> human programmer. A compiler generates vastly better asm code,
    Al> and can do intelligent stuff with regards to choosing
    Al> specialisations, etc.

Not as good as hand-tuned C (let alone asm), and not as intelligent as
a human, for short bodies of code.  This was true when Bjarne wrote
C++ -- that's why he didn't design, say, Java -- and it remains true
today, although it's getting much harder to beat a good compiler.  For
both good and bad code generation ;-) -- a modern compiler can do
things that a human would not really be able to do by hand, but if one
of those optimizations is buggy, it's damn hard to debug.  Sometimes
you need the speed, but can't trust the compiler, so you do it
yourself.

    Al> Nope, you've missed the point. I wasn't arguing that having a
    Al> C++ example not working would have led to a quicker solution,
    Al> nor was I arguing that the initial advice given would have
    Al> changed had the test case been different.

You fooled me!  I was certainly arguing the reverse.  We were talking
about useful test cases, not development environments.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.