[Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.

[John Wallace]

On Nov 30, 7:24 pm, "John Reagan" <johnrrea... at earthlink.net> wrote:
> "John Wallace" <johnwalla... at yahoo.co.uk> wrote in message
>
> news:d6cc754e-de17-4506-8460-eb282a1e7d2c at m35g2000vbi.googlegroups.com...
> On Nov 27, 5:47 am, "John Reagan" <johnrrea... at earthlink.net> wrote:
>
> >"you get all the loop optimization, routine inlining, dataflow
> >analysis, etc. that you get on Alpha."
> >Whilst these may have been leading edge once upon a time, surely
> >surely surely (?) they are fairly standard stuff these days, no? Does
> >gcc 4 do those to any useful extent, for example? Does Visual Studio
> >do those (either on x86 or on IA64)?
>
> I was commenting on a statement that our Itanium code-generator is less than
> the Alpha version.  It isn't.
>
> Yes such optimizations are often common but on most Unix systems I've seen
> such optimizations are off by default.
>
> GEM also does various forms of loop analysis, software pipelining, some
> limited speculation on Alpha (where there isn't any hardware support like
> Itanium's data speculation and NaTs).
>
> >And with IA64 you also afaict get a variety of often unavoidable run-
> >time penalties (alignment faults etc being the classic example) which
> >were largely things that Alpha users didn't need to worry too much
> >about, and are things that AMD64 users don't need to worry too much
> >about.
>
> Unavoidable?  Just align your data or tell the compiler the data isn't
> aligned.
>
> Remember that except for compiler bugs, alignment faults comes from the user
> lying to the compiler.  The compiler thinks the data is aligned but the
> program cheated and violated a rule (like stuffing some odd-byte address
> into an "int*").  Either align the data or if you can't, tell the compiler
> what you did and we'll avoid the alignment fault.
>
> Those alignment faults even on AMD64 cost time and hardware.  They just cost
> time on Alpha since there is no hardware support to deal with them.  They
> ALL get sent at least to the PAL code.  On Itanium, the hardware can fix up
> some if they fall in the same quadword or get sent to the OS as there is no
> PAL code.  All of the slowdown for alignment faults on Itanium is not due to
> the chip, but due to all the overhead that OpenVMS has to do to resolve the
> misaligned memory reference.  If Alpha didn't have low-level PAL code, it
> would be just as bad if not worse.
>
> John

Thanks for that.

Can I just pick up on one bit this time:
"alignment faults comes from the user lying to the compiler"

That's obviously true from your point of view as a compiler person,
but for the vast majority of folk out there, it would be more accurate
to say:
"alignment faults comes from the >>developer<< lying to the compiler"

And if the end user and the application developer are different
organisations, different companies, etc, getting this fixed may be non
trivial even if it's technically trivial to fix (which it may not
always be). So somebody's promised IA64 performance increase may or
may not be achievable without effort, whereas a mainstream chip is
likely to deliver the performance as advertised, starting from day one
(otherwise someone would get into trouble).

I guess IT's often like that; YMMV etc.