Idéias ambiciosas!!! - página 5
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ê está enganado porque não sabe as coisas mais simples.
Os dados de qualquer matriz são armazenados na memória em uma seqüência linear. Do primeiro ao último, e para endereçar um elemento x[15], o compilador calculará o endereço do início da matriz mais o turno 15 para calcular o endereço desta variável. Com uma matriz bidimensional, por exemplo, x[2][5], primeiro calcule o offset para a segunda linha e depois acrescente o offset para o 5º elemento, ou seja, o dobro das operações.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
tudo isso é a nível de compilador, mas o ArrayRange(x[0]) para um array estático é SEMPRE constante, não precisa ser computado o tempo todo, apenas uma vez e salvo em tempo de compilação
Você está praticando assembler? por que esses problemas? se você está fazendo assembler, infelizmente - eu não vi nenhuma documentação russa para o carregamento DIREITO do pipeline de instruções em processadores mais antigos que o Pentium-I, e o carregamento DIREITO do processador não é feito nem mesmo por desenvolvedores de compiladores, mas pelos desenvolvedores do sistema operacional e da arquitetura do processador
Se você está preocupado que uma operação de adição leve mais tempo para ser executada em ciclos de relógio de processador do que uma operação de adição, infelizmente, aquele navio navegou com o processador 486, o carregamento de caches e dutos de instrução leva mais tempo do que operações aritméticas e lógicas.
SZZY: Apelo mais uma vez - comece a ler as fontes primárias, aqui https://www.mql5.com/ru/docs/basis/types/classes desenvolvedores mql5 descrevem como organizar o alinhamento dos dados, a mesma informação é para todos os compiladores, há informações sobre como usar corretamente as funções do sistema de chamadas do Windows, etc. - Estou escrevendo isto para dizer que há pouca documentação russa que corresponda às capacidades modernas do sistema operacional e dos processadores, e o material antigo - o material que ensinam nas faculdades e universidades - não corresponde à realidade neste estágio de desenvolvimento do sistema operacional e do hardware.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
tudo isso é a nível de compilador, mas o ArrayRange(x[0]) para array estático é SEMPRE constante, não precisa ser calculado constantemente, é suficiente para calcular e economizar uma vez no tempo de compilação
Apenas o endereço do primeiro elemento é calculado na fase de compilação. Todos os outros elementos serão contados em modo de contagem através do offset, que é diferente a cada vez.
Para uma matriz bidimensional, você precisa contar dois offsets por colunas e por linhas multiplicadas pelo número da linha, e, claro, também no processo de contagem. Asembler e compilador não têm absolutamente nada a ver com isso, é apenas um endereçamento básico de memória para o uso correto dos recursos computacionais na prática.
A partir disto você pode facilmente ver que mesmo que haja uma perda de desempenho tão grande entre arrays unidimensionais e bidimensionais, os tempos de endereçamento são ainda mais significativamente mais lentos em casos mais complexos, por exemplo, com objetos.
Apenas o endereço do primeiro elemento é calculado no momento da compilação. Todos os outros elementos serão contados no modo de contagem através de um offset, que é diferente a cada vez.
Para uma matriz bidimensional você precisa calcular dois offsets por colunas e linhas multiplicados pelo número da linha e no processo de contagem também, é claro. Asembler e compilador não têm absolutamente nada a ver com isso, é apenas um endereçamento básico de memória para o uso correto dos recursos computacionais na prática.
A partir disto você pode facilmente ver que mesmo que haja uma perda de desempenho tão grande entre arrays unidimensionais e bidimensionais, os tempos de endereçamento são ainda mais significativamente mais lentos em casos mais complexos, por exemplo, com objetos.
êxitos na compreensão do que está acontecendo e a perda de produtividade
Não tenho problemas em otimizar compiladores e escrever meus próprios projetos de acesso aos dados
SZY: os objetos não são casos complexos - todas as manipulações para criar links - tudo no nível do compilador, infelizmente, o processador não se importa ou não com o objeto, não tem problema com as mudanças de computação relativas aos dados alinhados, mesmo que o "programador milagroso" salve a memória - escreve os dados em arrays como byte, mas não olha a documentação para o compilador, a eficácia deste código será visível apenas no reflexo de uma fisionomia presunçosa do programador no espelho, mas na realidade é uma falsificação
tudo está no nível do compilador, infelizmente o processador não se importa se é um objeto ou não, ele não tem problemas para calcular compensações relativas aos dados alinhados
Parece ter sido explicado a você em um simples exemplo o quanto a matriz bidimensional em relação à unidimensional irá desacelerar durante a execução do programa, não durante a compilação. Não vejo sentido em me repetir. Assim, você vê que não se encarrega de escrever códigos de cálculo mais ou menos otimizados em excesso do seu tempo e talvez não precise deles. Neste caso, o OOP é criado para você. :)
Você está pensando em categorias amoeba :) .
" Devemos esquecer as pequenas eficiências, digamos cerca de 97% do tempo: a otimização prematura é a raiz de todo o mal. No entanto, não devemos desperdiçar nossas oportunidades com esses 3% críticos".
Esta é a quarta vez que sou citado neste fórum.
Parece ter sido explicado a você em um exemplo simples o quanto mais lento um array bidimensional em relação a um unidimensional estará no processo de execução do programa, não de compilação. Não vejo sentido em me repetir. Assim você vê que não se preocupa em escrever um código computacional mais ou menos otimizado, e talvez não precise dele. Neste caso, o OOP é criado para você. :)
De que tipo de código ideal estamos falando? Você não tem absolutamente nenhuma idéia de como funcionam os compiladores e as máquinas virtuais
O programador não precisa descobrir como é feito o acesso e endereçamento aos elementos da memória física em cada compilador em particular (mesmo que na diagonal, não na coluna - nada pode ser feito aqui) - é a tarefa dos desenvolvedores, se o programador não estiver satisfeito com o código - ele irá otimizar seu código:
- aumentando o tamanho do código e diminuindo o tamanho dos dados e perdendo a velocidade de cálculo
- aumentando o tamanho dos dados no código e obtendo maior velocidade
- alternativamente, ele/ela usa um compilador diferente
TODAS AS OPÇÕES desapareceram!
OOP é outro ramo para escrever código EFICIENTE, a eficácia do OOP é que o programador pode criar um modelo matemático na forma de algum tipo de arquitetura - assim, conseguir grande versatilidade de seu código, se você acha que as classes têm outro tipo de endereçamento para acesso físico aos dados - você está enganado, essa quantidade extra microscópica de dados - uma tabela de objetos ligados não aumentará de forma alguma o tempo de acesso aos dados físicos na memória e os dados extras serão mais do que compensados por multi
Estou chocado - você começou a cagar no OOP, e depois passou para discussões sobre como lidar com arrays multidimensionais e unidimensionais - você estudou isso em algum lugar, ou apenas - todas as especulações e fantasias?
O trabalho com matrizes multidimensionais tem sido implementado há muito tempo no nível do ferro - o mesmo Z-buffer quando se trabalha com placas de vídeo, ah, sim, "ovelhas, os desenvolvedores de ferro" - não o consultaram e não aprenderam o quão eficaz é o endereçamento de matrizes multidimensionais, e não o consultaram - todos os programadores usam matrizes multidimensionais sem pensar, e não procuram a felicidade em aumentar o código em prol da eficiência imaginária quando se trabalha com matrizes unidimensionais
A confiabilidade das informações depende de quem as está apresentando? Qualquer pessoa sensata deve entender que a informação é objetiva, não subjetiva. :)
se o programador não estiver satisfeito com o código, ele otimiza seu código:
- aumentando o tamanho do código e diminuindo o tamanho dos dados e perdendo a velocidade computacional
- aumentando o tamanho dos dados no código e ganhando mais velocidade
- alternativamente, utiliza um compilador diferente
TODAS AS OPÇÕES desapareceram!
A otimização de código requer que o programador tenha um entendimento mínimo de como um fragmento de código será de uso intensivo de recursos em termos de operações elementares realizadas (adição, multiplicação, acessos à memória, cálculos de endereço, etc.). Sem isto, nenhuma otimização é possível em princípio, e mesmo o melhor compilador ficará impotente contra este pobre programador. Parece uma coisa óbvia, mas vejo que isto também pode ser uma grande notícia para muitos programadores. :)
E qualquer um que se proponha a entender a questão compreenderá que a informação, como a quantidade, é uma coisa subjetiva, não objetiva:))
Bem, você tem que confundir e misturar em uma cascavel, misturar coisas diferentes. :)
Uma é uma fonte de informação, que é objetiva, e a outra é um receptor, que é subjetivo porque nem sempre é capaz de perceber todas as informações, mas apenas parte delas.