Migrate timestamps to int64_t about drampower HOT 9 CLOSED

Was this issue not finished by your commit on August 1?

from drampower.

Mainly because there are still some residual casts to double, and because the MemCommand class still uses doubles internally to store time (https://github.com/ravenrd/DRAMPower/blob/master/src/MemCommand.cc#L55).

from drampower.

We don't rely on double's anymore to represent time. I propose to remove the getTime() function from MemCommand in favor of the int64_t getTimeInt64() const; function we now use.

https://github.com/ravenrd/DRAMPower/blob/master/src/MemCommand.h#L117

Any objections? If not, then I'll make this change and close the issue in 2 days.

from drampower.

I think that is totally valid. @efzulian, what do you think?

from drampower.

Hi guys, just wondering why not to use unsigned timestamps (uint64_t instead of int64_t). :)

from drampower.

Using unsigned numbers creates a few interesting opportunities for failure:

// If all of these variables are unsigned, then we might end up with
// an unexpectedly large value for 'a'
uint64_t a = max(zero, c-d);

The google style guide also agrees to some extent:
https://google.github.io/styleguide/cppguide.html#Integer_Types

from drampower.

Since we had this afternoon some discussions about using double or int for representing time in SystemC for DRAMSys, I'm curious to know: @Sv3n what is your motivation to represent time in int instead of double?

from drampower.

The input to DRAMPower is commands, which happen at integer multiples of the clock period. Expressing time as an integer number of clock cycles allows us to write down exactly when a command happens. Arithmetic on these clock cycles is guaranteed to produce an output that is another integer multiple of the clock period. With doubles you cannot guarantee that:

// Assuming the clock period is '1'
double now  = current_time_cycles_to_double(0);
double eight_cycles_ago = now - 8;
double four_cycles_ago =  now - 4;

// Now any of these expressions might be true, depending
// on the particular value of 'now':
eight_cycles_ago + 4 == four_cycles_ago;
eight_cycles_ago + 4 > four_cycles_ago;
eight_cycles_ago + 4 < four_cycles_ago;

At extremely large values, certain integer values can no longer be expressed in a double, and they will alias to other integers. For a demonstration of the effect (with less waiting time), you can use the smaller 'float' type:

for (float i = 0; i < 0xFFFFFFFF; i++) {
   // This will never finish. It halts at the first point where
   // the closest number expressible as a float for i + 1 == i
}

from drampower.

Thank you for that nice explanation. I had similar concerns, especially the rounding in the high dynamic ranges.

from drampower.