On Tue, 11 Jan 2011, nathan binkert wrote:
I don't know the range of numbers that we deal with, but floating numbers
may not exactly represent integers. It is possible to construct integers >
2^53 which are not exactly representable, I think (2^53)+1 cannot be
represented exactly. In fact, in such a case, 'a++' might end up equal to
'a' itself.
I'm pretty sure that we won't run into this. There are 31.5 Million
seconds/year. Or 31.5e15 nanoseconds per year. 2^53 is 9.0e15. That
means that you'd have to increment that counter every nanosecond to
hit the problem in four months. Now in theory, if you were to
increment by 1000 once per nanosecond for 3 hours and then you tried
to increment by one, the 1 would be lost. The question then becomes,
would that just be noise? (I'd think so).
Now such huge numbers can be reached if the simulation were to run for
months (assuming only increments by one are made). Therefore it might not
be a problem. But floating point addition is costly compared to integer
addition, then why go for floating point?
Is it really true that floating point adds are much more expensive
than integer ones these days?
On Core i7, it is single cycle for integer add and three cycles for
floating point.
Anyway, I'm quite happy for you to try changing it to an int64_t and
thoroughly test the results. I think that Counter was once indeed
int64_t.
Nate
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
