Re: programmer optimizations?

jbuck@Synopsys.COM (Joe Buck)
Mon, 2 Jan 1995 17:48:28 GMT

          From comp.compilers

Related articles
programmer optimizations? (Afsal C. Majeed) (1994-12-28)
Re: programmer optimizations? davidm@Rational.COM (1994-12-31)
Re: programmer optimizations? (1995-01-01)
Re: programmer optimizations? (1995-01-02)
Re: programmer optimizations? jbuck@Synopsys.COM (1995-01-02)
Re: programmer optimizations? (Erkki Ruohtula) (1995-01-11)
Re: programmer optimizations? (1995-01-05)
Re: programmer optimizations? (1995-01-05)
Re: programmer optimizations? (1995-01-12)
Re: programmer optimizations? (Stefan Monnier) (1995-01-21)
Re: programmer optimizations? synaptx!carambole! (Dave Gillespie) (1995-01-11)
[9 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: jbuck@Synopsys.COM (Joe Buck)
Keywords: optimize, architecture
Organization: Synopsys Inc., Mountain View, CA 94043-4033
References: 94-12-145
Date: Mon, 2 Jan 1995 17:48:28 GMT

"Afsal C. Majeed" <> writes:
>We are having small debate here as to the use of some of the
>code optimizations by the programmer himself.
> replacing (n / 4)
> by (n >> 2)

The moderator writes:
>[One reason that such optimizations are discouraged is that they're often
>wrong. Turning n/4 into n>>2 is only correct if n is unsigned.]

This is only true because almost everyone has broken integer division.

Turning n/4 into n>>2 for signed numbers implements a truncating towards
minus infinity. For many applications this truncating is *preferable* to
the truncating towards zero performed by the integer division instruction
in most CPUs, since truncating towards zero introduces a bias in the data.
Example: if you start with uniformly distributed integers, then divide
them by four, if you do so with "n >> 2" they are still uniformly
distributed (if their original range was a multiple of four). If you do
so with "n/4" and division truncates towards zero, you wind up with a
bigger-than average clump at 0, everything that was in [-3,3]. This kind
of bias is a major problem in digital signal processing: it means you have
to do many operations differently on positive and negative numbers because
you can't use the native instruction set, which wants to move everything
towards zero rather than in a consistent direction (actually, floating to
integer type conversion is even a bigger problem here).
-- Joe Buck <> Phone: +1 415 694 1729

Post a followup to this message

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