Article: AMD's Jaguar Microarchitecture
By: Michael S (already5chosen.delete@this.yahoo.com), April 7, 2014 1:20 am
Room: Moderated Discussions
Maynard Handley (name99.delete@this.name99.org) on April 6, 2014 3:52 pm wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on April 6, 2014 1:50 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on April 5, 2014 6:01 pm wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on April 5, 2014 10:59 am wrote:
> > > >
> > > > I don't follow.
> > > > Why should one save/restore the whole FPU state, why not only FP control register? Saving/restoring
> > > > only FPU control register is not slow relatively to the rest of library call overhead
> > > > and it *should* be done by any library that wants to use non-default control bits. Anything
> > > > less is bug and should not be tolerated bu library users.
> > > >
> > >
> > > By FPU state I mean the stuff that would be in an FP control register. I don't
> > > mean the state of standard FP registers. Sorry, I guess that was not clear.
> > >
> > > The point is
> > > (a) put it ALL CONTROL state in ONE register. And don't make the problem artificially
> > > more complicated by mixing up CONTROL bits with STATUS bits.
> > > (b) allow rapid reading and writing of that control state register with a single user level
> > > read/write operation, instead of a twiddle one bit at a time with high latency model.
> >
> > Intel/AMD MXCSR, indeed combines control and status in the
> > same registers. Same for Power FPSCR. And, indeed,
> > I don't like it from pure theoretical point of view. But in practice it is not a significant problem.
>
> Reading and writing control both make sense, writing status does not make sense.
Writing status does not make sense, but it does not hurt. At least I don't see why it could possibly hurt.
>
> Reading control can be as fast as reading any other register, reading status
> means you have to delay the read until the status is available.
>
In theory that makes sense.
Trying to compare the theory with practice:
x87 has separate control and status words (=good), while SSE has them intermixed (=bad).
I tried to compare the speed of FNSTCW instruction (x87 Control Word read=good) vs STMCSR (SSE Control/Status Word read=bad) in Agner's tables. Unfortunately, he provides very little information about the latency of these instructions and even available information is unlikely to be reliable. Which (lack of reliable information) sort of makes sense since the latency in this case is not only hard to measure, it's even hard to define what exactly would be considered latency.
Agner has throughput number, so and for majority of cores the throughput of FNSTCW is, indeed, significantly higher than STMCSR, but, first, in this case throughput is not very interested and second, on Nehalem and SB/EB the thoughput is the same for both - 1 per clock.
> Writing control (in a model where control is separate from status) is also easy and fast because now "all"
> you do is attach the control bits (as they are defined at the point of instruction execution) to each instruction,
> and they then flow along with instruction execution. At the point where you're making each decision (rounding,
> deform, etc), you consult the attached bit, not the global register. The main additional feature you need
> to add is that FP instructions later than a change of FP control don't move past an FP control write. (Or
> you can speculate on this, but an explicit test is probably easier and more performant.)
It's not clear to me where exactly you can do this "easy" attachment on OoO machine.
>
> PPC allows for 4-bit at a time twiddling of the FPSCR. This has the potential to be faster than reading
> and writing the whole thing because now you aren't necessarily delayed by the status bits; but it does
> mean that pulling out/shoving in the data you want is now two instructions (I think there are 8 control
> bits of interest on PPC, but it's been a while) each time, instead of one, and two registers that have
> to just sit around storing that info otherwise unusable, or which have to be pushed then popped.
Also sound like, depending on implementation, it would be the source of either partial-register interlock hazard or the source of more-true-than-false dependency on the previous state of control/status word. I'm not sure what's worse, in typical usage scenario probably the later.
> Michael S (already5chosen.delete@this.yahoo.com) on April 6, 2014 1:50 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on April 5, 2014 6:01 pm wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on April 5, 2014 10:59 am wrote:
> > > >
> > > > I don't follow.
> > > > Why should one save/restore the whole FPU state, why not only FP control register? Saving/restoring
> > > > only FPU control register is not slow relatively to the rest of library call overhead
> > > > and it *should* be done by any library that wants to use non-default control bits. Anything
> > > > less is bug and should not be tolerated bu library users.
> > > >
> > >
> > > By FPU state I mean the stuff that would be in an FP control register. I don't
> > > mean the state of standard FP registers. Sorry, I guess that was not clear.
> > >
> > > The point is
> > > (a) put it ALL CONTROL state in ONE register. And don't make the problem artificially
> > > more complicated by mixing up CONTROL bits with STATUS bits.
> > > (b) allow rapid reading and writing of that control state register with a single user level
> > > read/write operation, instead of a twiddle one bit at a time with high latency model.
> >
> > Intel/AMD MXCSR, indeed combines control and status in the
> > same registers. Same for Power FPSCR. And, indeed,
> > I don't like it from pure theoretical point of view. But in practice it is not a significant problem.
>
> Reading and writing control both make sense, writing status does not make sense.
Writing status does not make sense, but it does not hurt. At least I don't see why it could possibly hurt.
>
> Reading control can be as fast as reading any other register, reading status
> means you have to delay the read until the status is available.
>
In theory that makes sense.
Trying to compare the theory with practice:
x87 has separate control and status words (=good), while SSE has them intermixed (=bad).
I tried to compare the speed of FNSTCW instruction (x87 Control Word read=good) vs STMCSR (SSE Control/Status Word read=bad) in Agner's tables. Unfortunately, he provides very little information about the latency of these instructions and even available information is unlikely to be reliable. Which (lack of reliable information) sort of makes sense since the latency in this case is not only hard to measure, it's even hard to define what exactly would be considered latency.
Agner has throughput number, so and for majority of cores the throughput of FNSTCW is, indeed, significantly higher than STMCSR, but, first, in this case throughput is not very interested and second, on Nehalem and SB/EB the thoughput is the same for both - 1 per clock.
> Writing control (in a model where control is separate from status) is also easy and fast because now "all"
> you do is attach the control bits (as they are defined at the point of instruction execution) to each instruction,
> and they then flow along with instruction execution. At the point where you're making each decision (rounding,
> deform, etc), you consult the attached bit, not the global register. The main additional feature you need
> to add is that FP instructions later than a change of FP control don't move past an FP control write. (Or
> you can speculate on this, but an explicit test is probably easier and more performant.)
It's not clear to me where exactly you can do this "easy" attachment on OoO machine.
>
> PPC allows for 4-bit at a time twiddling of the FPSCR. This has the potential to be faster than reading
> and writing the whole thing because now you aren't necessarily delayed by the status bits; but it does
> mean that pulling out/shoving in the data you want is now two instructions (I think there are 8 control
> bits of interest on PPC, but it's been a while) each time, instead of one, and two registers that have
> to just sit around storing that info otherwise unusable, or which have to be pushed then popped.
Also sound like, depending on implementation, it would be the source of either partial-register interlock hazard or the source of more-true-than-false dependency on the previous state of control/status word. I'm not sure what's worse, in typical usage scenario probably the later.