Implementações alternativas de funções/abordagens padrão - página 11
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Você pode, por favor, me enviar o link?
Não o guardou. Mencionado no fórum aqui. Eu mesmo procurei nos motores de busca.
Não o guardou. Mencionado no fórum aqui. Eu mesmo pesquisei através dos motores de busca.
Obviamente, todas estas bicicletas foram reconstruídas muitas vezes. Até mesmo os livros foram publicados, até mesmo as implementações asm.
Hoje em dia, o básico é difícil de encontrar, pois quase todos usam APIs relevantes para todas as ocasiões.
Portanto, você só tem que se registrar nos fóruns e perguntar por aí.
Obviamente, todas estas bicicletas foram reconstruídas muitas vezes. Até mesmo livros foram publicados, até e incluindo implementações de asm.
Agora o básico é difícil de encontrar, já que quase todos usam APIs relevantes para todas as ocasiões.
Portanto, você só tem que se registrar nos fóruns e perguntar.
Por que você não usa LONG_MAX/MIN? De alguma forma, ficaria mais bonito. Acho que fica bonito. Joguei seus testes com o gcc (com modificações min, é claro, o compilador é muito antigo 5.4.0, o que eu tinha em mãos):
Bem, sim, não é agradável. MasLONG_MAX= 9223372036854775807 é mais de 9007199254740992. E a forma hexadecimal deste número - 0x20000000000000 é repreendida porque deve ser apenas para o tipo ulong. Eu nem sei como torná-lo mais claro. Eu não posso escrever (ulong)(1<<53) porque é uma operação demorada.
O tipo duplo começa a conter inteiros sem partes fracionadas não a partir do valorLONG_MAX, mas a partir do máximo possível de mantissa. Mas 53 bits são permitidos para a mantissa, ou seja, 2^53=9007199254740992.
Seu código de tempo falha - a saída é em milissegundos (não nano), e eu ainda não entendo porque precisamos de menos t0.
t0 é o tempo de ciclo completo de 1000000 passes de soma do duplo principal
enquanto t é o tempo do mesmo ciclo de soma dos mesmos valores duplos, mas passou por funções ceil, ceil, round etc.
Parti da lógica de que a diferença (t-t0) é o tempo líquido gasto com estas funções.
Naturalmente, uma maior objetividade só pode ser alcançada através de várias medidas.
- Em nano, eu calculo com base no tempo necessário para realizar uma função em 1.000.000. Exatamente em nano está correto.
pavlick_:
Eu fiz seus testes no gcc (com modificações mínimas, é claro, o compilador é muito antigo 5.4.0, o que estava à mão):
1. Compilação com -O3.
2. Compilação com -Ofast
Não escreva (ulong)(1<<53), porque essa já é uma operação demorada.
Esta operação não consome muito tempo, como todas as operações com constantes, incluindo as cordas.
Esta operação é intemporal como todas as constantes, incluindo as cordas.
Uau - legal! Obrigado. E eu achava que isso contava sempre. Sim, bem, é lógico, você já pode calculá-lo em tempo de compilação.
Bem, então é isso:
Entretanto, seria mais correto escreverDBL_MANT_DIG ao invés de 53
Caso de ganho mínimo se todos os valores de duplo forem fracionários.
Assim acontece. Que o código MQL5 compilado funciona mais rápido que até mesmo Ofast? Acho difícil de acreditar que você deve ter tido um compilador de 32 bits.
Eu tirei o menos t0 de tudo (pensei que fosse algum tipo de erro) e minha saída tem todo o laço medido, não um único passe. Se convertermos para sua forma de produção em nanossegundos por iteração (na primeira linha "Tempo de ciclo sem arredondamento" - temos a mesma forma de contagem), obtemos:
Não há muita aceleração no gcc (e ainda mais lenta no -Ofast). Na mcc há uma velocidade significativa, a julgar pelo seu teste, mas:
você tem 985'651 de 1'000'000, ou seja, quase todas as iterações satisfazem a condição x < MIN || x > MAX.
-Ofast desabilita todas as verificações inf/nan, errno setting, ou seja, o arredondamento nu no fpu é deixado. E este arredondamento nu não pode ser derrotado por uma simples comparação de x < MIN || x > MAX.
Não há muita aceleração no gcc (e ainda mais lenta no -Ofast). Em µl é significativo.
No entanto, é difícil dizer. Jogamos fora t0 por bons números e conseguimos 20 vezes a diferença. Mesmo o código adicional mínimo em forma de laço (+t0) torna o resultado bonito em várias dezenas de vezes a menos atraente em cerca de duas vezes. E o que você pode dizer se não for apenas um loop, mas um algoritmo real fazendo algo útil? A diferença não será visível de forma alguma, ela irá vaguear em algum lugar muito depois do ponto decimal e dificilmente se tornará um gargalo de estrangulamento. Em uma aplicação real a captação mutex, barreiras cpu, alocação de memória são muito mais caras do que o arredondamento. Em suma, não vale a pena apostar, imho.
Sim, a diferença não será visível de forma alguma, ficará em algum lugar muito depois do ponto decimal e é improvável que seja um gargalo de estrangulamento. Em uma aplicação real, que toma barreiras mutex, cpu, a alocação de memória é muito mais cara do que o arredondamento. Em suma, não vale a pena apostar, imho.
Isto é verdade em 99% das vezes, sim.
Antes de otimizar, você deve certificar-se de ter algo a ser otimizado.
Em minha prática eu me lembro apenas de um caso quando minha própria implementação do atof realmente ajudou. Embora me parecesse que sim.
E você deve ter em mente que qualquer otimização (exceto ***) não é livre.