By: Foo_ (foo.delete@this.nomail.com), June 30, 2013 5:15 am
Room: Moderated Discussions
x (x.delete@this.example.com) on June 30, 2013 3:54 am wrote:
>
> And then, once we establish that the FPU is present, making it good is natural.
>
> In servers, I guess the reason here is that microservers don't have economies of scale yet, while big servers
> are not price sensitive and in some cases also need to "run any workload" (think of servers being rented out
> for unknown use), and they need a lot of OoO and cache anyway, so the cost of an FPU is a small part.
>
> If massively multicore microservers become popular and start being
> used by Google & co., then THESE might not have an FPU.
I'm not sure what the point of not having a FPU would be. They could have a pretty basic FPU, e.g. with microcoded SIMD and no superscalar execution, but having a FP addition complete in a couple of cycles, rather than trap to an emulation routine, is probably good for performance robustness.
(I suppose a basic FPU takes up little space nowadays)
>
> And then, once we establish that the FPU is present, making it good is natural.
>
> In servers, I guess the reason here is that microservers don't have economies of scale yet, while big servers
> are not price sensitive and in some cases also need to "run any workload" (think of servers being rented out
> for unknown use), and they need a lot of OoO and cache anyway, so the cost of an FPU is a small part.
>
> If massively multicore microservers become popular and start being
> used by Google & co., then THESE might not have an FPU.
I'm not sure what the point of not having a FPU would be. They could have a pretty basic FPU, e.g. with microcoded SIMD and no superscalar execution, but having a FP addition complete in a couple of cycles, rather than trap to an emulation routine, is probably good for performance robustness.
(I suppose a basic FPU takes up little space nowadays)