Posso obter granularidade de microssegundos quando calculo o número de nanossegundos do Windows Epoch até hoje?

Question

Usando o Ubuntu Linux 16.04 e g ++, eu queria saber se poderia obter granularidade em microssegundos ou milissegundos quando eu calcular o número de nanossegundos entre o Unix Epoch ou o Windows Epoch e um datetime arbitrário. Estou ciente de que o resultado time_t do tempo (NULL) tem granularidade em segundos e o resultado temporal da estrutura de gettimeofday tem granularidade em milissegundos.

Que outras abordagens existem para resolver este problema? Esta não é uma questão de programação. Eu escrevi um programa para testar isso que eu posso compartilhar, se solicitado.

Qualquer ajuda é muito apreciada.

    

Answer 1

Você pode fazer isso com gettimeofday() . Isso foi respondido no StackOverflow , que citarei aqui:

You have two choices for getting a microsecond timestamp. The first (and best) choice, is to use the timeval type directly:

struct timeval GetTimeStamp() {
    struct timeval tv;
    gettimeofday(&tv,NULL);
    return tv;
}

The second, and for me less desirable, choice is to build a uint64_t out of a timeval:

uint64_t GetTimeStamp() {
    struct timeval tv;
    gettimeofday(&tv,NULL);
    return tv.tv_sec*(uint64_t)1000000+tv.tv_usec;
}

    

Answer 2

Minha resposta é usar o formato decimal64.

Citações de link :

In computing, decimal64 is a decimal floating-point computer numbering format that occupies 8 bytes (64 bits) in computer memory. It is intended for applications where it is necessary to emulate decimal rounding exactly, such as financial and tax computations.

Decimal64 supports 16 decimal digits of significand and an exponent range of −383 to +384, i.e. ±0.000000000000000×10−383 to ±9.999999999999999×10384. (Equivalently, ±0000000000000000×10−398 to ±9999999999999999×10369.) In contrast, the corresponding binary format, which is the most commonly used type, has an approximate range of ±0.000000000000001×10−308 to ±1.797693134862315×10308. Because the significand is not normalized, most values with less than 16 significant digits have multiple possible representations; 1×102=0.1×103=0.01×104, etc. Zero has 768 possible representations (1536 if you include both signed zeros).

Decimal64 floating point is a relatively new decimal floating-point format, formally introduced in the 2008 version[1] of IEEE 754 as well as with ISO/IEC/IEEE 60559:2011.

Aqui está um link descrevendo como usar decimal64.

link

    

Answer 3

A solução flutuante Decimal64 é a melhor, mas requer alguma mágica de programação com uniões anônimas. Para converter decimal64 para std :: string, você tem que usar uma união (suponha que ele tenha o nome S) com 2 membros, uma entrada decimal :: decimal64 e uma saída uint64_t (do c ++ 99's cstdint.h). Como essa união tem um membro decimal :: decimal64 que é uma classe C ++ e requer um construtor e um destruidor definidos pelo usuário, é necessário usar o novo operador de posicionamento para definir o valor do membro de entrada e causar uma alteração no valor do membro de saída.

Além disso, o programador deve inicializar o objeto S, por exemplo, dados nomeados, como este: S data = {12345678987654321ULL} para que o compilador não exclua o objeto union nos bastidores. Para complicar mais as coisas, decimal / decimal.h, não define o construtor embutido, decimal64 :: decimal64 em linha (decimal64 __r). Finalmente, o usuário precisa escrever um operador global de ostream < < para decimal64.

Para simplificar a vida para mim, hoje usei uint64_t para representar o número de nanossegundos do Windows Epoch hoje. Essa opção corrigiu meus erros de estouro numérico int64_t.

A desvantagem entre o uint64_t e o decimal64 é que o decimal64 tem um intervalo dinâmico muito maior que o uint64_t. Além disso, printf de uint64_t requer um especificador de formato especial:

   #include <inttypes.h>
    uint64_t t;
    printf("%" PRIu64 "\n", t);

Por favor, deixe-me saber se você tiver dúvidas ou precisar de um exemplo de código.