kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (10/03/90)
In article <34469@cup.portal.com> Don_A_Corbitt@cup.portal.com writes: >roy@phri.nyu.edu writes: [equality comparison faster than greater] >I haven't seen this in print, but I assume it is because there is extra >delay waiting for carry propagation to set the condition code. XOR can >test all the bits in parallel. I think there is still O(log n) delays for all the bit XOR's to get together into a final result. However, AND-ing together 32 XOR's is a much easier proposition than handling carry lookahead for the same number of bits (assuming greater/less is done using effectively an ALU subtract). The more efficient means of generating less/greater, comparable to the the speed of XOR's for equality, are typically uneconomic to implement in dedicated h/w. -Kym Horsell
marcb@hp-ptp.HP.COM (Marc Brandis) (10/05/90)
>In article <41898@mips.mips.COM> mash@mips.COM (John Mashey) writes: >:At the code level, this is probably true, although it certainly is the >:case that there are fundamental computer system design reasons why >:== might be faster than <. Whether these reasons show up in any ...... >:It probably doesn't matter most places, except in some technical code >:with short loops with many iterations. > >My point was only that I felt that any performance advantage (one or >two clocks was bandied about) is grossly outweighed by the rest of the >loop, and given that, I tend to prefer the < syntax (since it is pretty >much required for floating-point variables.) Probably you should not care too much about it. A smart optimizer may be able detect most of these cases, where < may be replaced by ==, and do the replacement. This is certainly true for loops like for (i = 0; i < n; i++) stat; where stat is known not to change i. (* I speak only for myself. Marc-Michael Brandis Institut fuer Computersysteme ETH Zentrum CH-8092 Zuerich, Switzerland e-mail: brandis@inf.ethz.ch brandis@iis.ethz.ch Temporarily at HP, marcb@hp-ptp.ptp.hp.com *)