Re: [Sheflug] c++ & mem

["Alex Hudson" <nospam [at] alexhudson.com>]

>     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.

I know the history of Duff's device. I still don't see what your problem is.
It's highly likely that anyone needing to use Duff's device is writing
device drivers, or some such, anyway, and will be telling the compiler what
to do on quite a basic level. Unrolling for(i=a; i<b; i++) reg = mem[i]; is
fairly trivial. Doing it optimally? Are you talking about instruction cache
misses? Or something else? I really don't get your point here...

>     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.

Not as intelligent as a human, no, but probably with a greater armoury of
optimizations and cases at hand. It's the humans job to make algorithmic
optimizations, it's the compiler's job to chop instructions.

>     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.

. but not with regards to the original problem, as you seemed to suggest?

Cheers,

Alex.

---------------------------------------------------------------------
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.