«

James Kuyper <> writes:

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

No, that's not what I am doing. I am saying that the model does not
apply (though, as I have admitted this is an unsupported belief). The
phrase "people don't think or work like this" means that I don't believe
that people behave in a way the produces a "value function" that can be
determined with any useful precision.

I suspect you will say that that is just measurement and there must be
such a function even if it is hard to determine, but that is just
insisting that the model applies despite being unable to determine
whether it does or not.

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

Not if my habit is to read a Usenet post after starting a compile (or,
if that seems to wasteful, to read one work-related email) and the
minimum time that takes is always a little more than the compile.

> You're
> confusing "too small to notice" with "zero", and those quantities have
> very different properties when multiplied by sufficiently large
> numbers.

I am tempted to counter that you are confusing "small by noticeable" with
"too small to notice" since my argument centres around what is
"noticeable" (not consciously noticeable, but noticeable in the sense of
producing a detectable effect on a person's behaviour) but we've been
here before. I suspect we both think what we are saying is obviously
true and don't think either of has any evidence to offer.

--
Ben.

I'm back again
Sorry for the delay, but I was involved in another project and I
haven't found time to make the measurements you asked for.


On 25 Gen, 03:52, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > You are saying that code A could be faster than code B on a platform
> > (CPU+compiler), but could be slower on another platform.
>
> * * *Yes. *If you believe A is always faster/slower and B is always
> slower/faster, regardless of platform, compiler version, compiler
> options, program context, and phase of the Moon, you are too young
> and inexperienced for the work you're engaged in.

Ok, ok...


> * * *It is surpassingly unlikely that a straight-line source-code
> sequence A will be faster than B in all circumstances. *Compilers
> are startlingly subtle, but are not magical. *So, what's a poor
> programmer to do? *There are several approaches, among them:
> [...]
> * * *... and that is the LAST you will hear from me on this thread
> until and unless you offer some actual MEASUREMENTS! *If you say
> "I think" or "It stands to reason" or "Everyone knows," I will
> personally come after you with a big book of six-place logarithms
> and bludgeon you so hard your mantissa will fall off.

I made some measurements with an oscilloscope. The function is:
---
unsigned char data[] = {0x11, 0x22, 0x33, 0x44};
unsigned int x;
void foo(void) {
PIN_SET(34);
x = *(unsigned int *)&data[0];
PIN_RESET(34);
NOP();

PIN_SET(34);
x = *(unsigned int *)&data[1];
PIN_RESET(34);
NOP();

PIN_SET(34);
x = (data[0] << + data[1];
PIN_RESET(34);
NOP();

PIN_SET(34);
x = (data[1] << + data[2];
PIN_RESET(34);
NOP();
}
---
The first pulse on pin 34 is for an aligned access. The second pulse
is for misaligned access. The third/forth pulse is for a portable
access (aligned and misaligned).

I found the following (clock cycle is 62.5ns):
1st pulse: 1.13us (18 cycles)
2nd pulse: 1.25us (20 cycles)
3rd pulse: 1.63us (26 cycles)
4th pulse: 1.63us (26 cycles)

As imagined before, portable access (3rd and 4th pulses) is slower
than simple cast (but not portable) instructions. Of course, the
difference is only 6 cycles (375ns).

Anyway I think you are write: the gain with the cast/faster approach
is limited, compared with the advantages of a portable (byte
composition) approach.

"pozz" <> wrote in message
news:943754ae-ec14-4cb0-a8f8-...

> On 25 Gen, 03:52, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:

>> ... and that is the LAST you will hear from me on this thread
>> until and unless you offer some actual MEASUREMENTS! If you say
>> "I think" or "It stands to reason" or "Everyone knows," I will
>> personally come after you with a big book of six-place logarithms
>> and bludgeon you so hard your mantissa will fall off.
>
> I made some measurements with an oscilloscope.

Well, that's different...

The function is:
> ---
> unsigned char data[] = {0x11, 0x22, 0x33, 0x44};
> unsigned int x;
> void foo(void) {
> PIN_SET(34);
> x = *(unsigned int *)&data[0];
> PIN_RESET(34);
> NOP();
>
> PIN_SET(34);
> x = *(unsigned int *)&data[1];
> PIN_RESET(34);
> NOP();
>
> PIN_SET(34);
> x = (data[0] << + data[1];
> PIN_RESET(34);
> NOP();
>
> PIN_SET(34);
> x = (data[1] << + data[2];
> PIN_RESET(34);
> NOP();
> }
> ---
> The first pulse on pin 34 is for an aligned access. The second pulse
> is for misaligned access. The third/forth pulse is for a portable
> access (aligned and misaligned).
>
> I found the following (clock cycle is 62.5ns):
> 1st pulse: 1.13us (18 cycles)
> 2nd pulse: 1.25us (20 cycles)
> 3rd pulse: 1.63us (26 cycles)
> 4th pulse: 1.63us (26 cycles)

You should also have tested just:

PIN_SET(34);
PIN_RESET(34);

(or repeated the code between these calls several times), just to test what
these overheads are. The more microseconds in overheads, the more
significance those 6 cycles will have (so instead of 26/20, it might be
22/16 for example; 37% slower instead of 30%).

> As imagined before, portable access (3rd and 4th pulses) is slower
> than simple cast (but not portable) instructions. Of course, the
> difference is only 6 cycles (375ns).
>
> Anyway I think you are write: the gain with the cast/faster approach
> is limited, compared with the advantages of a portable (byte
> composition) approach.

I think Eric meant measurements of an actual program, where that 30% slower
portable code (or 23% faster non-portable) may or may not have any
significance.

But if your program really will be portable, then you will have opportunity
to do tests on other processors (where perhaps the portable code might be
half the speed, in which case they might deserve a dedicated, non-portable
version).

--
bartc