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
Se estamos falando especificamente de SSDs (não apenas Unidades Flash USB ou vários SD/MMC/CF etc.), os controladores modernos programam as operações de escrita de forma a distribuir uniformemente a carga em todas as células. Isto é, mesmo que o mesmo arquivo seja substituído o tempo todo, as células são quase sempre diferentes. Portanto, mesmo ~10 000 ciclos (para MLC) durarão muito tempo.
Particularmente a Intel para seus SSDs série M garante que a unidade será capaz de escrever até 100GB por dia por 5 anos. É verdade, eles são "apenas" garantidos por 3 anos, mas é improvável que tenhamos 100GB por dia em testes a qualquer momento em breve.
Quanto à velocidade de acesso a QUALQUER arquivo (grande/pequeno), as SSDs modernas podem ser inferiores a QUALQUER HDD moderna apenas em operações lineares (seqüenciais). Mas em tais operações, sua velocidade é boa o suficiente. Ao mesmo tempo, durante o acesso casual (freio principal), mesmo os discos rígidos "15 milésimos" do servidor não são capazes de se aproximar deles, pelo menos de alguma forma, em velocidade. Bem, o tempo de acesso difere por ordens de magnitude! O mesmo se aplica ao número de operações de entrada-saída por segundo.
Portanto, o único fator limitante é o preço.
Uau, quão detalhado... obrigado pela lambida sem - não sabia) Li sobre isso do canto do olho, mas não tenho um conhecimento tão profundo... Obrigado, talvez agora eu economize para um SSD sem medo =)
a propósito, de acordo com as revisões, o primeiro eee pc tinha um SSD de lixo. portanto, em termos de velocidade e qualidade, acho que não foram tão bons quanto....
Testado o laptop. Intel Mobile Core 2 Duo P8600 @ 2.4 GHz, cache 3072 KB L2, DDR2 4GB PC-6400
Teste de roteiro 44,99s, otimização 201s, em carrapatos 29:46
Terminal em RAM mostrará 45,14, otimização 185s e 29:38 em carrapatos.
para Olga_trader. Para teste use o SuperSpeed RamDisk 9.0.1.0, primeiro disponível. Em ambos os casos criei um disco de 800 Mb, porque o testador cria o histórico com antecedência. 1 ano é cerca de 524 Mb. Durante 5 anos são 2,5 gb mais a pasta do histórico, que já inchei até 1,85 gb, e ainda preciso deixar 3-4 gb de RAM para o terminal e o disco rígido. Total 8 gb. Um aumento na produtividade graças a estas ações é questionável, mas não consigo me sentir confortável trabalhando com estas coisas de qualquer forma.
Se eu executar 2 terminais em meu atlonchik, o teste por minuto será de 188s e 166s - escolha o resultado mais alto. Eu tenho 1:23:24 e 1:18:23 ticks (era 1:09:06 em um só núcleo) - minha RAM estava baixa e o computador estava usando ativamente o disco rígido.
Na otimização de laptops por minutos 113s e 96s, por carrapatos 20:26 e 16:48.
Sim, Imp120, coloque o teste do laptop na mesa.
Если на моем атлончике запустить сразу 2 терминала, то тест по минутам будет 188с и 166с - выбираем больший результат. По тикам 1:23:24 и 1:18:23 (было 1:09:06 на одном ядре) - не хватило RAM и комп стал активно пользоваться хардом.
O laptop é otimizado pelos minutos 113s e 96s, pelos carrapatos 20:26 e 16:48.
É aqui que eu não entendo. Que resultados devo deixar na tabela? E como é que o funcionamento de dois terminais melhora os resultados?
Imp120, a propósito, notei que seu laptop e meu desktop são muito próximos em termos de desempenho tabular. E os resultados são semelhantes (o seu é mais rápido, mas não por muito).
Mathemat, извините я не точно выразился. Я разделил оптимизацию на два терминала. 102 цикла в одном и столько же в другом. Значения второй переменной в первом были 1 и 4, а во втором 7 и 10. Думал будет в 2 раза быстрее, а получилось в 1.5 ) Просто наводит на размышления, что при равной цене оптимизация быстрее будет на двух компах, чем на одном, но мощном.
Seria mais rápido, bip-beep, se os desenvolvedores parassem de bipar e fizessem um testador multi-tarefa normal. Caso contrário, bip-beep, temos que multiplicar os terminais como bip-beep a fim de acoplar os núcleos.
E o que é característico, o principal problema do envolvimento de vários núcleos é a má paralelização do algoritmo. Um testador é perfeitamente paralelizável, o que idiotas vezes fazemos executando cópias do mesmo. Mas todos o têm, não nossos queridos desenvolvedores! Eles têm outro problema - a julgar pela reação - pessoal qualificado. O OOP, claramente o pioneiro, é mais importante! (A propósito, nem um único código publicado no 5 usando o OOP - todos os procedimentos!)
Perdoe-me - já se passaram 20 horas de otimização, é isso que me deixa nervoso.
Tenho esta hipótese estúpida e ingênua de que é isto que os desenvolvedores estão tentando fazer com o testador. O botão de teste de estratégia ainda está desativado, e há uma razão para isso, não é mesmo?
Tenho esta hipótese estúpida e ingênua de que é isso que os desenvolvedores estão tentando fazer com o testador. O botão de teste de estratégia ainda está desativado, e há uma razão para isso...
O otimismo é a essência de uma perspectiva alegre e de afirmação da vida.
>> Tem sido dito repetida e inequivocamente que não o fará.
No início, os desenvolvedores também disseram que não haveria herança.
E que não haveria objetos em perus.
Mas não funciona assim...
P.S. Bem, é verdade o que você diz: o testador (ou melhor, o otimizador) é o mais fácil de fazer paralelismo. Será que é possível controlar este processo, ou seja, definir diretamente como distribuir os conjuntos de parâmetros entre os núcleos?
Se Deus quiser...
Com os objetos, ou melhor, sua ausência nos indicadores, é claro - a idiotice da situação era óbvia.
A propósito, a nova construção já permitida?