Re:DEC64: Decimal Floating Point
by microcolonel on Sunday March 04, 2018 @02:38PM
(#16516190)
> So the only valid criticism I saw in that whole thread is #4, and even that is only a tenth as valid as its author thought it was.
Not really here to defend these criticisms, but if #4 is only a tenth as valid as the author thought it was, then does that mean that you know the worst case instruction count to compare two DEC64 numbers is five? Also, we're talking x86 here, how many μops and static instruction bytes are we talking on either side of this? Are all of the branches usually predictable? Can we ever afford to inline something as critical as the comparison operation?
As for the validity of #5, I think this might make more sense in the context of hardware implementations, where a low-order exponent position could increase complexity (requiring adjustments to reuse any of the FPU datapath) AFAIK.
Re:DEC64: Decimal Floating Point
by Veedrac on Sunday March 04, 2018 @02:46PM
(#16516251)
All I meant is that the author of the comment said it would apply in most cases, where even pessimistically it seems it should apply one time in ten. I don't have detailed performance information.
Not really here to defend these criticisms, but if #4 is only a tenth as valid as the author thought it was, then does that mean that you know the worst case instruction count to compare two DEC64 numbers is five? Also, we're talking x86 here, how many μops and static instruction bytes are we talking on either side of this? Are all of the branches usually predictable? Can we ever afford to inline something as critical as the comparison operation?
As for the validity of #5, I think this might make more sense in the context of hardware implementations, where a low-order exponent position could increase complexity (requiring adjustments to reuse any of the FPU datapath) AFAIK.