Re: Where would you like to spend that resource? (WAS: yup!)

In article 91-08-092 pardo@cs.washington.edu writes:
>
>
>wulf@capa.cs.Virginia.EDU writes:
>>[The person who wrote
>>
>>> I'll give up substantial speed even in the final product to gain
>>> productivity
>> is missing the point. S/he doesn't have to give up *anything*,
>> his/her customer does. The customer is giving up either
>> functionality or the ability to use the left-over resources.]
>
>Perhaps I am missing the point. I say many things and I'm often
>convinced otherwise after I've said them. I think it's called
>``getting an education'' :-)
>
>Still, the world in which I live has products that come out after
>deadline and with bugs. By design or accident, most of the machines I
>run on have spare cycles most of the time. I like programs that are
>fast, but I especially like programs that are correct.
>
>Note: I'm not making any argument about *optimizers*, I'm expressing an
>opinion about the (lack of) necessity of speed.


Perhaps we need a much clearer statement of what you are saying before we
end up with a 12-sided discussion with no two people on the same side. I
think we're just talking past each other here.


Your original statements were definitely in the context of optimizers, and
that is what everyone has responded to.


Your [deleted] discussion about array bounds checking, etc. is interesting,
but I am not sure that it is part of the original discussion. Either the
language standard mentions bounds checking at run time, or it doesn't. If it
doesn't, the compiler writer should provide it as an option. The user of the
compiler can decide when to use it and when to turn it off. Perhaps it will
be used during testing, and then turned off when the product is shipped. The
extra cycles spent checking bounds during testing are not "wasted", and I
don't think Dr. Wulf or anyone else said or implied that they were. Nor is it
wasted time to run 1000 tests instead of 500 tests, assuming the tests are
not redundant. There seems to be no controversy over this use of CPU cycles.


Your original posting implied to me that you were concerned with the time
wasted optimizing code during the software development stage. The optimizer
can be turned off during this stage, and only turned back on during final
testing to insure that optimization has not broken anything. Unless there is
a considerable penalty in running an optimizing compiler with the
optimizations suppressed, as opposed to running a compiler that never had any
optimizations in its design, this seems to be another non-issue.


There appears to be a false dilemma of correctness versus speed. If this
dilemma can be substantiated with respect to optimizing compilers, please do
so. Otherwise, I am not sure what you are talking about any more. (This IS
"comp.compilers", so ideas for new and safer languages and/or architectures
are not what I am talking about.)


Run-time checks don't fall into the dilemma because they are either required
by the language (and eliminating them is incorrect, not optimization) or they
are requested by the user as an option (same argument in this case.) Again,
neither Dr. Wulf nor anyone else stated that language designers should throw
safety to the winds because we'll get a few cycles of benefit for doing so.
Although I will go out on a limb and state that I don't want languages or
architectures that always do run time safety checks that I cannot turn off --
not general purpose languages and architectures, that is. Mission critical
systems and languages for them are a different story, of course. I would
prefer my run of the mill PCs and workstations to run software that was
tested with safety checks and shipped without them.


When I get a piece of software from a vendor, I hope it was optimized before
shipping. And if your machines always have free cycles, as you stated, there
are researchers in distributed systems who are busy plotting how to steal
those cycles from you. No computing resource has been been had in excess for
very long; surely that is one lesson from the history of computing upon which
we can all agree?
--
clc5q@virginia.edu (Clark L. Coleman)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.