Naomi Greenberg wrote:
>Thank you all for your replies. I agree with everything you've said, but it
>would be helpful to me if there were actual references
>
Any book on compiler optimization. A good one for this is probably:
http://www.amazon.com/exec/obidos/tg/detail/-/1558602860/qid=1089744709/sr=8-1/ref=pd_ka_1/103-7553190-9999844?v=glance&s=books&n=507846
> I could cite proving
>this point, rather than stating opinions, albeit those of the experts.
>
Benchmarks are tricky, in that the *semantics* of the languages are
quite different. For example, many years ago one of the SunOS (that
gives a clue ;>) was quite proud of some enhancement to the system
memory copy routine. I tried to demonstrate the then new easier to use
facility to linking C to f77 code by comparing the simple f77 memory
copy to the OS one ... intending to illustratue why it was worth calling
to C.
My f77 code was something like
subroutine copy(a,b,n)
real a(n),b(n)
do i = 1, n
b(i)=a(i)
end do
return
end
I also had a version which used complex*16.
Both versions beat the highly tuned OS code by a wide margin. Of course,
turns out that the system routine had to worry about overlapping regions
and other pointer related oddities.
After many weeks, the OS developer managed to beat the simple Fortran
code (he rewhacked the C until it produced f77 like object code for the
common case, and then hand coded the other cases).
So was this a "fair" benchmark or not? C semantics (actually Posix, but
the distinction is small for many casual observers) required the extra
logic (which there was no f77 equivalent for, nor could there be and
still be standard conforming).
Most multi-lingual benchmarks suffer from such tradeoffs ... which
flatter one language or another.
If you Management can't understand first principles ... this is probably
the least of your concerns.
Dependency analysis is one of the harder problems (and there are many NP
complete problems in compilation). Pointers make it much harder, and
limit the payoffs. That's as established a fact as factoring large
numbers is computationally hard.
--
Keith H. Bierman [log in to unmask]
Sun Microsystems PAE | [log in to unmask]
15 Network Circle UMPK 12-325 | 650-352-4432 voice+fax
Menlo Park, California 94025 | sun internal 68207
<speaking for myself, not Sun*> Copyright 2003
