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
Alguma vez analisaram os códigos de hrenfx(getch in former life)? Recomendo vivamente que analisem todos os seus trabalhos no 4º fórum kodobase e analisem cuidadosamente um casal ou três deles para compreenderem completamente os algoritmos. E toda a vossa brigada de alto contraste de "pessoas do mais alto nível de profissionalismo" sugiro vivamente que façam o mesmo. Talvez devessem estar menos delirantes sobre as capacidades intelectuais de Ivan e começar a melhorar as vossas próprias capacidades.
Não mostrou merda em números, tem três carrapatos em barras, enquanto ele tem um carrapato em cada - apenas LoAsk e HiBid - que propagou aqui durante muito tempo. Assim, se retirar duas comparações desnecessárias do loop e desligar as verificações de alcance no compilador (RangeCheck), então a figura declarada parece bastante realista, mesmo com cálculos úteis (mínimos) dentro do loop.Alguns dos códigos hrenfx com que me deparei - o código é de muito alta qualidade, não posso dizer nada. Ainda utilizo alguns deles. Mas não misturar moscas com costeletas. Você, como a gerica, está a escrever sem sequer compreender o teste que estou a oferecer. Ou por falta de conhecimentos profundos em C, ou por alguma outra razão está a enfatizar que uma barra para hrenfx é apenas dois inteiros. Na realidade, passamos um ponteiro para a estrutura que descreve a barra; a estrutura em si não é passada por valor, o que significa que ligar e desligar o número de itens na barra não afectará de forma alguma o desempenho. Nota, estou a falar do tempo de desempenho do próprio estrato, estou a ignorar o tempo de enchimento da matriz.
Aqui está o resultado do desempenho se deixar apenas um valor na própria estrutura:
Ou seja, o tempo para implantar uma estrutura leve, consistindo num único valor longo diminuiu muitas vezes, de 9 segundos para 2,35, mas o tempo de execução em si permaneceu quase o mesmo (mesmo ligeiramente aumentado, porque comecei a chamar rand() no if check). Se o motor delegar a execução ao estratega, o que na realidade está a acontecer, o tempo de execução torna-se ainda mais longo e o tamanho da estrutura que descreve a barra não tem absolutamente nada a ver com isso.
Portanto, se vai dizer algo novamente, estude C primeiro - então teremos algo de que falar.
Ou seja, é verdade que o tempo de implantação de uma estrutura leve, constituída por um único valor longo, diminuiu de 9 segundos para 2,35, mas o tempo da execução em si permanece quase o mesmo
E se se dividir por 8 (núcleos)?
E se o dividirmos por 8 (núcleos)?
Alguns dos códigos hrenfx com que me deparei - o código é de muito alta qualidade, não posso dizer nada. Ainda utilizo alguns deles. Mas não misturar moscas com costeletas. Você, como a gerica, está a escrever sem sequer compreender o teste que estou a oferecer. Ou por falta de conhecimentos profundos em C, ou por alguma outra razão está a enfatizar que uma barra para hrenfx é apenas dois inteiros. Na realidade, passamos um ponteiro para a estrutura que descreve a barra; a estrutura em si não é passada por valor, o que significa que ligar e desligar o número de itens na barra não afectará de forma alguma o desempenho. Nota, estou a falar do tempo de desempenho do próprio estrato, estou a ignorar o tempo de enchimento da matriz.
Aqui está o resultado do desempenho se deixar apenas um valor na própria estrutura:
Ou seja, o tempo para implantar uma estrutura leve, consistindo num único valor longo diminuiu muitas vezes, de 9 segundos para 2,35, mas o tempo de execução em si permaneceu quase o mesmo (mesmo ligeiramente aumentado, porque comecei a chamar rand() no if check). Se o motor delegar a execução ao estratega, o que realmente acontece, o tempo de execução torna-se ainda mais longo e o tamanho da estrutura que descreve a barra não tem absolutamente nada a ver com isso.
Portanto, se vai dizer algo novamente, estude C para começar e depois teremos algo para falar.
Não quero discutir a discrepância encontrada menos de duas vezes, // que pode ser eliminada, por exemplo, para diferenças em compiladores e processadores.
O desempenho de Ivan é próximo do real, para estratégias leves, e é bastante motivador para escrever "calculadoras" simples para cada uma das suas estratégias.
Pois essa produtividade é enorme em comparação com um mashup universal de testador regular. Era exactamente isso que Ivan queria dizer, e não a Renat, mas a si, a mim e a outros "utilizadores" que estão à espera "sob o mar do tempo".
e não um programador, em apenas cinco horas.
Não, hrenfix tem um testador de rosca única, está escrito no seu posto.
Não me lembro de ter dito que não era um programador, mas há muito que é conhecido aqui como programador, entre outros.
1) ...... Mas foi também declarado que foi alcançado, por assim dizer, com meio estrondo, por um não-programador, em apenas 5 horas.
2) E não saberemos durante muito tempo se hrenfx significava desempenho em modo multi-rosca ou mono-rosca.
1) O resultado foi alcançado em cinco horas por um homem que escreve o provador não pela primeira vez, ou seja, um "não-programador" muito experiente. Por exemplo,um dos seus feitos, já com três anos de idade.
2) Leia o post original com mais atenção e saberá logo de seguida. "a manivela não é um leitor..." ? ;)
Ele não é um profissional, e ao contrário de alguns que afirmam ser profissionais, ele diz isso, apesar de provavelmente estar acima da maioria dos cargos de topo em termos de nível.