[Tutor] back on bytes

[shawn bright]

Well, I contacted the programmer of these controls and the reason they
mask the MSB on these reports is to designate what type of sensor it
is. If the MSB is set, the sensor is one type, if not, another. So,
knowing that i could put these together ok. To me, the speed is of no
consequence like it would be if i were processing files, these sensors
report anywhere from 6 to 12 bytes total, and we get them at the rate
of about 20 / minute.

Having said all that, I want to express thanks to this list,
especially you guys, Kent and Alan, not just for the help here the
past week, but also what i have been able to dig out of my gmail
archives from help you gave me on similar issues months ago. I
appreciate it a lot.

shawn

On 7/7/07, Kent Johnson <kent37 at tds.net> wrote:
> Alan Gauld wrote:
> > Surely it is easier and more obvious
> > to simply shift the bits right or left using >> and << and use
> > bitwise and/or operations than do all this multiplication and
> > addition malarky. (Its also a lot faster!)
>
> Are you sure about that? With Python  2.5 on a MacBook Pro it seems to
> be *slightly* faster:
>
> src $ python -m timeit "5 << 21; 10 << 21; 50 << 21; 247 << 21"
> 10000000 loops, best of 3: 0.0917 usec per loop
>
> src $ python -m timeit "5 * 0x200000; 10 * 0x200000; 50 * 0x200000; 247
> * 0x200000"
> 10000000 loops, best of 3: 0.0924 usec per loop
>
> .0917/.0924 = 0.99242424242424254
>
> src $ python -m timeit -s "nums=range(256); mults=range(1, 22)" "for i
> in nums:" "  for m in mults:" "    i<<m"
> 1000 loops, best of 3: 564 usec per loop
>
> src $ python -m timeit -s "nums=range(256); mults=[1<<m for m in
> range(1, 22)]" "for i in nums:" "  for m in mults:" "    i*m"
> 1000 loops, best of 3: 579 usec per loop
>
> src $ python -m timeit -s "nums=range(256); mults=[1<<m for m in
> range(1, 22)]" "for i in nums:" "  for m in mults:" "    pass"
> 10000 loops, best of 3: 195 usec per loop
>
> If the last timing is a reasonable estimate of the loop overhead in the
> previous two, then roughly the speed difference is 579-195=384 vs
> 564-195=369 and shifting is 369/384.=0.9609375 the speed of multiplication.
>
> My guess is the integer multiply in my computer recognizes this simple
> case and optimizes it to a shift.
>
> Kent
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>