«

Le 26/01/11 13:50, James Kuyper a écrit :
>
> Let's say that you have a program that takes 10 seconds to perform an
> operation that you have to wait for before you can do anything else
> useful. Thanks to some 20,000 separate decisions made by 5000 different
> hardware and software designers about how each individual hardware and
> software component of your system should be designed, that operation
> does NOT take a a full minute to execute; those individual decisions
> saved you an average of only 2.5 milliseconds each. If each of those
> designers had taken the attitude that "no one cares about saving 2.5
> milliseconds", most of those decisions might have been made differently.
> Do you think that would have been the right thing for those designers to
> have done?
>
>

Thanks. You have just explained why gcc takes always longer and longer
to compile the same stuff with each new release.

At each decision tree node some gnu guy says

"This new extra optimization just takes 2.5 ms! That's nothing"

And there we go.

James Kuyper <> writes:

> On 01/25/2011 11:24 PM, Ben Bacarisse wrote:
>> "Bartc"<> writes:
>>
>>> "Eric Sosman"<> wrote in message
>>> news:ihnu1r$833$...
>>>> On 1/25/2011 5:30 AM, Bartc wrote:
>>>>> [...]
>>>>> A billion times 1msec times 100 times a day comes to about 3 years'
>>>>> savings -- per day. One entire lifetime saved per month.
>>>>
>>>> ... and if you can't see the absurdity inherent in that
>>>> calculation, you ought to give up programming and go into politics.
>>>
>>> Looks like I need to go into politics then.
>>>
>>> BTW what *is* the absurdity? You mean saving 3 years, in only one day?
>>> That's spread over more than one person!
>>>
>>> (The figures were Ben's, who claimed they added to near zero. Changing the
>>> billion to a million, and the 1msec to 1 second, makes them more realistic
>>> (some products I use *do* have a response time of a second or more, and are
>>> manufactured in the hundreds of thousands), but the resulting saving is the
>>> same.)
>>
>> Let's say You have a spare hour in which to read. Do you care if it is
>> from 12 to 1pm or it if made up of 3600 separate seconds scattered
>> throughout the day? It's the same total time after all. I contend that
>> time does not always add up in the obvious way. The fractions gained
>> here and there can't always be used as if there were run together.
>
> Let's say that you have a program that takes 10 seconds to perform an
> operation that you have to wait for before you can do anything else
> useful. Thanks to some 20,000 separate decisions made by 5000
> different hardware and software designers about how each individual
> hardware and software component of your system should be designed,
> that operation does NOT take a a full minute to execute; those
> individual decisions saved you an average of only 2.5 milliseconds
> each. If each of those designers had taken the attitude that "no one
> cares about saving 2.5 milliseconds", most of those decisions might
> have been made differently. Do you think that would have been the
> right thing for those designers to have done?

No, and I don't see how you suspect me of such an attitude. My argument
is solely with the oft-quoted (and to my mind naive) arithmetic that I
originally commented on. That arithmetic could be used to argue *against*
writing efficient software (just as it can also be used to argue in it's
favour). It is sometimes worth taking care of efficiency even when then
sum of time saved by others won't add up to the time spent optimising it
(and, equally, it sometimes is worth it).

--
Ben.

"Ben Bacarisse" <> wrote in message
news:0.2c31fa0ec98afd51ac22.20110126171740GMT.8739 ...

> If you define "valid" I might be able to comment. I am not saying that
> 1,000 times 1ms != 1s. I am saying that 1,000 separate milliseconds are
> not always as useful as the single second (even when scaled by some
> value multiplier as you suggest).

What you're saying is that it's OK to waste an entire lifetime, provided
it's shared out as tiny units of time between large numbers of people..

Actually, 1 or 2 msecs really wouldn't make much difference.

But hundreds of milliseconds certainly do, especially with the response
times of electronic equipment, some of which can be rendered unusable (you
press a button; nothing happens. You press it again after one second, then
again. Suddenly all presses are actioned at once, and you've probably
deleted something you shouldn't. Or at best have to start again (meanwhile
you've got kids screaming because their show hasn't come on instantly..)

On my car, there is a lever that you pull towards you to turn on full beam
headlights. To flash a courtesy signal, you pull it part-way, but this point
is difficult to judge. The point is, there is a 200-250ms delay between
actuating the switch, and the blue indicator lighting on the dashboard. You
move the lever, the light hasn't come on, you move it some more, but now it
latches, and the lights are blinding the other driver! So now I usually
don't bother.

A lot of this will be just bad programming, but I'm sure some of it is just
sluggish performance due, not to hardware limitations, but to programmers
with the wrong attitudes.

--
Bartc

On 01/26/2011 09:23 AM, Ben Bacarisse wrote:
....
> No, and I don't see how you suspect me of such an attitude. My argument
> is solely with the oft-quoted (and to my mind naive) arithmetic that I
> originally commented on. That arithmetic could be used to argue *against*
> writing efficient software (just as it can also be used to argue in it's
> favour). It is sometimes worth taking care of efficiency even when then
> sum of time saved by others won't add up to the time spent optimising it
> (and, equally, it sometimes is worth it).

The point I was trying to make is that the math being used is perfectly
valid. However, the total time savings must be multiplied by the value
per second of the time being saved, before being compared with the
developer's time times the value per hour of that time. For human
beings, there's considerable variation in that value, even for a single
person, depending upon what they would otherwise be doing with that
time. For other contexts, such as device controllers, wide variations in
the value of the time saved is the norm, not the exception. However, it
remains perfectly valid to add up large numbers of very small amounts of
time, before performing that multiplication (properly speaking, you
should use the marginal value of the time, rather than the average value).

--
James Kuyper

James Kuyper <> writes:

> On 01/26/2011 09:23 AM, Ben Bacarisse wrote:
> ...
>> No, and I don't see how you suspect me of such an attitude. My argument
>> is solely with the oft-quoted (and to my mind naive) arithmetic that I
>> originally commented on. That arithmetic could be used to argue *against*
>> writing efficient software (just as it can also be used to argue in it's
>> favour). It is sometimes worth taking care of efficiency even when then
>> sum of time saved by others won't add up to the time spent optimising it
>> (and, equally, it sometimes is worth it).
>
> The point I was trying to make is that the math being used is
> perfectly valid.

Ah. You asked me if I though developers would be right to take the
attitude that "no one cares about saving 2.5 milliseconds". I think
it's understandable that I did not get that you were just talking about
the validity of the arithmetic.

If you define "valid" I might be able to comment. I am not saying that
1,000 times 1ms != 1s. I am saying that 1,000 separate milliseconds are
not always as useful as the single second (even when scaled by some
value multiplier as you suggest). I believe that in some situations
there is a non-liner scale that devalues small savings. I accept that I
can't offer any evidence in support of this (though it is in principle
testable) so we might just have to agree to disagree unless, of course,
you have evidence that such non-linear value functions never apply.

> However, the total time savings must be multiplied by
> the value per second of the time being saved, before being compared
> with the developer's time times the value per hour of that time.

This was absent from what I was objecting to as being overly simplistic.
The usual argument is to assume that all time for all people (and
organisations) in all contexts has equal value (or cost). I would
probably still have commented had this been in the original post, but
even this small change makes the notion far more realistic.

> For
> human beings, there's considerable variation in that value, even for a
> single person, depending upon what they would otherwise be doing with
> that time. For other contexts, such as device controllers, wide
> variations in the value of the time saved is the norm, not the
> exception. However, it remains perfectly valid to add up large numbers
> of very small amounts of time, before performing that multiplication
> (properly speaking, you should use the marginal value of the time,
> rather than the average value).

I thought we had been talking about marginal times. I certainly agree
(if I understand your usage of the term) that we should be doing so.

The only trouble I have in agreeing with everything you say is the term
"perfectly valid". It could range in meaning from "mathematically valid
but not always meaningful" (my view) to "always yields useful
information for deciding on the value of an optimisation".

--
Ben.

On 01/26/2011 12:17 PM, Ben Bacarisse wrote:
> James Kuyper<> writes:
>
>> On 01/26/2011 09:23 AM, Ben Bacarisse wrote:
>> ...
>>> No, and I don't see how you suspect me of such an attitude. My argument
>>> is solely with the oft-quoted (and to my mind naive) arithmetic that I
>>> originally commented on. That arithmetic could be used to argue *against*
>>> writing efficient software (just as it can also be used to argue in it's
>>> favour). It is sometimes worth taking care of efficiency even when then
>>> sum of time saved by others won't add up to the time spent optimising it
>>> (and, equally, it sometimes is worth it).
>>
>> The point I was trying to make is that the math being used is
>> perfectly valid.
>
> Ah. You asked me if I though developers would be right to take the
> attitude that "no one cares about saving 2.5 milliseconds". I think
> it's understandable that I did not get that you were just talking about
> the validity of the arithmetic.
>
> If you define "valid" I might be able to comment. ...

In this context, validity might not be precisely the right term, but
what I mean is that it is fact reasonable and appropriate to perform
that multiplication as part of the process of deciding whether it's
appropriate to bother performing an optimization. At least, conceptually
- hard numbers to put into the calculation are often difficult or
impossible to obtain, but the basic concept that saving a an
infinitesimal amount of time on sufficiently many different occasions
can be worth doing, even though each of the individual time savings are
too small to even be perceived, is something that it is important to be
aware of.

> ... I am not saying that
> 1,000 times 1ms != 1s. I am saying that 1,000 separate milliseconds are
> not always as useful as the single second (even when scaled by some
> value multiplier as you suggest). I believe that in some situations
> there is a non-liner scale that devalues small savings.

I disagree. To me, the typical situation is that the value of taking a
certain amount of time to perform a task can, at least conceptually, be
described as a function of that amount of time, V(t). V(t) is usually a
decreasing function (the parts of the curve where it isn't (if any)
aren't normally of relevance to optimization). The value of decreasing a
single performance of the task by delta_t is, to a good approximation,
-dV(t)/dt * delta_t. The value of decreasing the time taken on a million
performances of the task is then -1000000 * dV(t)/dt * delta t. If you
want a little more realism, there's a different V_i for each task, so
the more realistic formula is

- Sum over i of (dV_i(t)/dt * delta_t)

However, that can simply be re-written as

- 1000000 * Average over i of (dV_i(t)/dt) * delta_t

or
- Average over i of (dV_i(t)/dt) * 1000000 * delta_t

The first factor in that product as the value multiplier.

In order for this to be a non-linear function of delta_t for small
values of delta_t, then dV(t)/dt * delta_t would have to be a VERY bad
approximation to V(t+delta_t) - V(t). There are functions for which that
is true, but only near singularities in the function. Such functions do
not seem plausible to me as descriptions of the value of completing a
task in the amount of time t.

--
James Kuyper

"Bartc" <> writes:

> "Ben Bacarisse" <> wrote in message
> news:0.2c31fa0ec98afd51ac22.20110126171740GMT.8739 ...
>
>> If you define "valid" I might be able to comment. I am not saying that
>> 1,000 times 1ms != 1s. I am saying that 1,000 separate milliseconds are
>> not always as useful as the single second (even when scaled by some
>> value multiplier as you suggest).
>
> What you're saying is that it's OK to waste an entire lifetime, provided
> it's shared out as tiny units of time between large numbers of
> people..

That's an emotive way to put it! No, it is never OK to waste anything
and certainly not an entire lifetime. I said that some small
improvements make no appreciable difference to anyone and it's OK to
concentrate on more important things. The same point of view can be
expressed in lots of different ways.

> Actually, 1 or 2 msecs really wouldn't make much difference.
>
> But hundreds of milliseconds certainly do,

Absolutely. This sub-thread was sparked by my remark about "a few ms"
which, to my mind, lies somewhere between "1 or 2" and "hundreds" of
milliseconds. It sounds like we agree.

> especially with the response
> times of electronic equipment, some of which can be rendered unusable (you
> press a button; nothing happens. You press it again after one second, then
> again. Suddenly all presses are actioned at once, and you've probably
> deleted something you shouldn't. Or at best have to start again (meanwhile
> you've got kids screaming because their show hasn't come on instantly..)
>
> On my car, there is a lever that you pull towards you to turn on full beam
> headlights. To flash a courtesy signal, you pull it part-way, but this point
> is difficult to judge. The point is, there is a 200-250ms delay between
> actuating the switch, and the blue indicator lighting on the dashboard. You
> move the lever, the light hasn't come on, you move it some more, but now it
> latches, and the lights are blinding the other driver! So now I usually
> don't bother.
>
> A lot of this will be just bad programming, but I'm sure some of it is just
> sluggish performance due, not to hardware limitations, but to programmers
> with the wrong attitudes.

Absolutely. With anything real-time there is often an extreme
non-linearity in the timing required. In these cases the argument may
stop being about adding up "wasted time" to become one about getting the
thing to work at all.

--
Ben.

James Kuyper <> writes:

> On 01/26/2011 12:17 PM, Ben Bacarisse wrote:
>> James Kuyper<> writes:
>>
>>> On 01/26/2011 09:23 AM, Ben Bacarisse wrote:
>>> ...
>>>> No, and I don't see how you suspect me of such an attitude. My argument
>>>> is solely with the oft-quoted (and to my mind naive) arithmetic that I
>>>> originally commented on. That arithmetic could be used to argue *against*
>>>> writing efficient software (just as it can also be used to argue in it's
>>>> favour). It is sometimes worth taking care of efficiency even when then
>>>> sum of time saved by others won't add up to the time spent optimising it
>>>> (and, equally, it sometimes is worth it).
>>>
>>> The point I was trying to make is that the math being used is
>>> perfectly valid.
>>
>> Ah. You asked me if I though developers would be right to take the
>> attitude that "no one cares about saving 2.5 milliseconds". I think
>> it's understandable that I did not get that you were just talking about
>> the validity of the arithmetic.
>>
>> If you define "valid" I might be able to comment. ...
>
> In this context, validity might not be precisely the right term, but
> what I mean is that it is fact reasonable and appropriate to perform
> that multiplication as part of the process of deciding whether it's
> appropriate to bother performing an optimization.

I could not agree more. In fact, if this had been the way it was
expressed initially I doubt I would have posted at all.

> At least,
> conceptually - hard numbers to put into the calculation are often
> difficult or impossible to obtain, but the basic concept that saving a
> an infinitesimal amount of time on sufficiently many different
> occasions can be worth doing, even though each of the individual time
> savings are too small to even be perceived, is something that it is
> important to be aware of.
>
>> ... I am not saying that
>> 1,000 times 1ms != 1s. I am saying that 1,000 separate milliseconds are
>> not always as useful as the single second (even when scaled by some
>> value multiplier as you suggest). I believe that in some situations
>> there is a non-liner scale that devalues small savings.
>
> I disagree. To me, the typical situation is that the value of taking a
> certain amount of time to perform a task can, at least conceptually,
> be described as a function of that amount of time, V(t). V(t) is
> usually a decreasing function (the parts of the curve where it isn't
> (if any) aren't normally of relevance to optimization). The value of
> decreasing a single performance of the task by delta_t is, to a good
> approximation, -dV(t)/dt * delta_t. The value of decreasing the time
> taken on a million performances of the task is then -1000000 *
> dV(t)/dt * delta t. If you want a little more realism, there's a
> different V_i for each task, so the more realistic formula is
>
> - Sum over i of (dV_i(t)/dt * delta_t)
>
> However, that can simply be re-written as
>
> - 1000000 * Average over i of (dV_i(t)/dt) * delta_t
>
> or
> - Average over i of (dV_i(t)/dt) * 1000000 * delta_t
>
> The first factor in that product as the value multiplier.
>
> In order for this to be a non-linear function of delta_t for small
> values of delta_t, then dV(t)/dt * delta_t would have to be a VERY bad
> approximation to V(t+delta_t) - V(t). There are functions for which
> that is true, but only near singularities in the function. Such
> functions do not seem plausible to me as descriptions of the value of
> completing a task in the amount of time t.

This is formalising the simple multiply and add argument but it does not
make it any more credible to me. I don't believe people think or work
like this. It is certainly true, for example, that I value faster
builds but I am almost never staring blankly at the screen, my mind in
idle, waiting for the result so I can continue to work the instance it
finishes. Sometimes I don't even notice it's finished for several
hundreds of milliseconds. Sometimes that time is wasted because I'm
staring out of the window -- sometimes it is not because I'm thinking
about the problem at hand. If the build took 10ms longer every time, I
don't think I'd be less productive which, ultimately, must be the
measure of "lost time" that gets balanced again the time to shave those
milliseconds off.

--
Ben.

On 1/26/2011 10:18 AM, Bartc wrote:
>
> What you're saying is that it's OK to waste an entire lifetime, provided
> it's shared out as tiny units of time between large numbers of people..

Isn't that the *definition* of Usenet?

--
Eric Sosman
lid

On 01/26/2011 08:08 PM, Ben Bacarisse wrote:
....
> This is formalising the simple multiply and add argument but it does not
> make it any more credible to me. I don't believe people think or work
> like this. ...

You're confusing the formalism with the thing being modeled. It's like
saying that baseballs can't trace out parabolas when hit by a bat, just
because baseballs don't know how to calculate the square of a number.

People don't have to think this way in order for thinking this way to be
appropriate; what matters is whether saving time has a value that is a
sufficiently smooth function of the amount of time saved; it doesn't
matter whether people actually think about such a function, it just
matters whether their time has value to them.

> ... It is certainly true, for example, that I value faster
> builds but I am almost never staring blankly at the screen, my mind in
> idle, waiting for the result so I can continue to work the instance it
> finishes. Sometimes I don't even notice it's finished for several
> hundreds of milliseconds. Sometimes that time is wasted because I'm
> staring out of the window -- sometimes it is not because I'm thinking
> about the problem at hand. If the build took 10ms longer every time, I
> don't think I'd be less productive which, ultimately, must be the

I can't imagine why that would be; those hundreds of milliseconds that
might pass before you notice it's finished will occur an average of 10ms
earlier, if it finishes 10ms earlier, because your opportunities to
notice that it has finished will start 10ms earlier. You're confusing
"too small to notice" with "zero", and those quantities have very
different properties when multiplied by sufficiently large numbers.

--
James Kuyper