Ajuda com o OOP - página 7
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
Comparação incorreta, pois não leva em conta o tempo para remoção automática de objetos.
Modificado.
De onde vêm 123 megabytes depois da V3, não sei.
Não, está correto. E este é um ponto de princípio. A eliminação automática não acontece no fio principal, onde o custo do tempo é extremamente caro. Você pode iniciar uma nova corrida sem esperar que o fio paralelo retorne a memória usada. Sim, ela também será chamada e consumirá recursos da CPU também, mas será uma operação paralela executada em segundo plano. Com qualquer otimização, mesmo a mais agressiva, uma parte dos recursos da CPU estará disponível para outras roscas porque esta é a forma como todos os sistemas operacionais modernos funcionam hoje em dia. Colocar uma carga de 100% na CPU em processadores modernos é quase impossível.
--
Deixe-me colocar isto de outra forma. Suponha que haja uma tarefa a ser executada em 5 unidades de tempo. Você pode executá-lo com uma linha em 5 unidades, ou com duas linhas em 3 e 2 unidades respectivamente. Obviamente, o tempo total de execução seria o mesmo: 5 unidades, mas o tempo físico necessário no segundo caso seria de 2 unidades a menos, já que a tarefa é concorrente no segundo caso e não no primeiro. Há um contra-argumento de que a otimização ocupa todos os núcleos físicos disponíveis da CPU. Mas isto não é verdade. Qualquer otimização alocará, na melhor das hipóteses, um número de fios igual ao número de núcleos no sistema operacional. Entretanto, além dessas tarefas, centenas de outras tarefas serão executadas em OS, e todos os 8 núcleos de processador (se houver oito deles) serão divididos entre centenas de fios do sistema, ao invés de 8 fios alocados por otimizador. Assim, alocar mais um thread no modo 8+1 ou 8+8, é sempre mais sensato do que pensar ingenuamente que uma vez que uma aplicação tenha alocado 8 threads, ela usará todos os recursos da CPU com 100%.
--
Em geral, é divertido ouvir argumentos como"não contamos este tempo, porque o tempo total de todo o sistema o inclui". "Ou o argumento de que"os métodos de objetos criados através de novos são chamados mais lentos" - Se assim for, provavelmente devemos descontar a referência até este momento, porque é injusto quando os métodos são chamados mais lentos de uma forma e mais rápidos de outra)))))) Bem, nesse caso, por que fingir que estamos nos afogando em desempenho? Sejamos francos, somos da década de 90 e não admitimos nada além dos falsos slogans "assembler é mais rápido mesmo!" ou "quando trabalho com ponteiros, eu controlo tudo".
--
Segundo ponto. Preste atenção à V2. Não há eliminação de objetos e há um vazamento deliberado de memória direto. Mesmo assim, a alocação de objetos leva 1,4 segundos versus 1,2 segundos em V1, embora não se gaste tempo algum com a eliminação.
Não sei de onde vêm 123 Mbytes depois da V3.
É difícil dizer. Você precisa conhecer a especificação da máquina virtual mql. Mas ninguém sabe disso, exceto os desenvolvedores. A julgar pela análise no ProcessHacker, parece que os objetos selecionados através de * novos são alocados individualmente em um lugar de alguma forma complicada e depois movidos para outra área de memória como grandes matrizes. Isto é, poderia ser alguns objetos temporários ou algo mais.
Não, correto. E este é um ponto de princípio. A eliminação automática não acontece no fio principal, onde o custo do tempo é extremamente caro. Você pode iniciar uma nova corrida sem esperar que o fio paralelo retorne a memória usada. Sim, ela também será chamada e consumirá recursos da CPU também, mas será uma operação paralela executada em segundo plano. Com qualquer otimização, mesmo a mais agressiva, uma parte dos recursos da CPU estará disponível para outras roscas porque esta é a forma como todos os sistemas operacionais modernos funcionam hoje em dia. Colocar uma carga de 100% na CPU em processadores modernos é quase impossível.
--
Deixe-me colocar isto de outra forma. Suponha que haja uma tarefa a ser executada em 5 unidades de tempo. Você pode executá-lo com uma linha em 5 unidades, ou com duas linhas em 3 e 2 unidades respectivamente. Obviamente, o tempo total de execução seria o mesmo: 5 unidades, mas o tempo físico necessário no segundo caso seria de 2 unidades a menos, já que a tarefa é concorrente no segundo caso e não no primeiro. Há um contra-argumento de que a otimização ocupa todos os núcleos físicos disponíveis da CPU. Mas isto não é verdade. Qualquer otimização alocará, na melhor das hipóteses, um número de fios igual ao número de núcleos no sistema operacional. Entretanto, além dessas tarefas, centenas de outras tarefas serão executadas em OS, e todos os 8 núcleos de processador (se houver oito deles) serão divididos entre centenas de fios do sistema, ao invés de 8 fios alocados por otimizador. Assim, alocar mais um thread no modo 8+1 ou 8+8, é sempre mais sensato do que pensar ingenuamente que uma vez que uma aplicação tenha alocado 8 threads, ela usará todos os recursos da CPU com 100%.
--
Em geral, é divertido ouvir argumentos como: "Bem, nós não contamos este tempo porque o tempo total de todo o sistema o inclui. "Ou o argumento de que"os métodos de objetos criados através de novos são chamados mais lentos" - Se assim for, provavelmente devemos descontar a referência até este momento, porque é injusto quando os métodos são chamados mais lentos de uma forma e mais rápidos de outra)))))) Bem, nesse caso, por que fingir que estamos nos afogando em desempenho? Sejamos francos, somos da década de 90 e não admitimos nada além dos falsos slogans "assembler é mais rápido mesmo!" ou "quando trabalho com ponteiros, eu controlo tudo".
--
Segundo ponto. Preste atenção à V2. Não há eliminação de objetos e há um vazamento deliberado de memória direto. Mesmo assim, a alocação de objetos leva 1,4 segundos versus 1,2 segundos em V1, embora não se gaste tempo algum com a eliminação.
É difícil dizer. Você precisa conhecer a especificação da máquina virtual mql. E ninguém sabe disso, exceto os desenvolvedores. A julgar pela análise no ProcessHacker, parece que os objetos selecionados através de * novos são alocados individualmente em um lugar de alguma forma complicada e depois movidos para outra área de memória como grandes matrizes. Isto é, poderia ser alguns objetos temporários ou algo mais.
Então, se a eliminação não estiver na linha principal, que diferença faz se ela está incluída na medição ou não? Não é como se isso afetasse a)))) Então por que não incluí-la para ver a verdade?
E a propósito, Vasily, há uma pergunta esperando por você lá (última fila).
... Ou o argumento de que"os métodos de objetos criados com novos são chamados de mais lentos".
Você não tem a coragem de medi-lo? Você é uma casca vazia, Vasya, sua cascavel.
Você não tem coragem de medir?
Você vai dormir descansado!
Dorme!
Sonho... e pisar os pés...
Então, se a eliminação não estiver na linha principal, que diferença faz se ela está ou não incluída na medição? Não é como se isso afetasse a)))) Então por que não incluí-la para ver a verdade?
Bem, então inclua no benchmark o tempo total gasto pelo Explorer, telegrama, cromo rodando durante a otimização. Mesmo se você matar tudo isso, e deixar apenas MT, haverá uma centena de outros fios do sistema que perderão tempo da CPU, incluindo-os.
Bem, então inclua no benchmark o tempo total gasto pelo Explorer, telegrama, cromo rodando durante a otimização. Mesmo se você matar tudo isso, e deixar apenas MT, haverá uma centena de outros fios do sistema que perderão tempo da CPU, incluindo-os.
Está em fios paralelos)))) (© Vasya)
Vasya, você é realmente estúpido!
Mas continue, continue persistindo.
E, a propósito, Vasily, há uma pergunta esperando por você lá (última fila).
Você pode provar que você é um idiota e um codificador zero em pouco tempo. Mas quem e por que precisaria disso quando você está provando ano após ano, sujando literalmente todos os tópicos deste fórum. Passei dois anos sem postar nada aqui, só ocasionalmente olhava - e cada vez, em cada fio era você, com sua "opinião autorizada" no estilo de "vocês são todos idiotas, não entendem nada, e como fazer - não vou dizer. Você é um homem podre, Dima.
Você pode provar que você é um idiota e um codificador zero em pouco tempo. Mas quem precisa disso quando você o prova ano após ano, cagando literalmente em cada tópico deste fórum. Passei dois anos sem postar nada aqui, só ocasionalmente olhava - e cada vez, em cada fio era você, com sua "opinião autorizada" no estilo de "vocês são todos idiotas, não entendem nada, e como fazer - não vou dizer. Você é um homem podre, Dima.
O problema é que eu não lhe digo como fazê-lo corretamente?
Sim, e você já provou algo muito bem aqui))
E eu é que sou o podre? Você é o único com diarréia e escrófula quando eu escrevo código.