linux DDR16bit/32bit

[tcpipchip]

Muito complexo para um fim de ano
Mas leia isto
https://community.freescale.com/mobile/ ... s%2F329671

[tcpipchip]

No caso 3) apesar das arquiteturas Harvards poderem endereçar RAM e FLASHes no mesmo range de endereços, ainda...

Harvards ? Ou Von ?

[fabim]

A beaglebone Black REV C, é uma CPU-A7@1GHZ com DDR3-16bit@606mhz.

http://www.adafruit.com/product/1876


Baseando-se nas informações que me prestaram, se eu tivesse DDR3-32bit@700mhz, a performance iria melhorar um pouco mais do que já esta, e não gritante, é isso ?

[pbernardi]

No caso 3) apesar das arquiteturas Harvards poderem endereçar RAM e FLASHes no mesmo range de endereços, ainda...

Harvards ? Ou Von ?

Oops. Von Neumann...

[pbernardi]

A beaglebone Black REV C, é uma CPU-A7@1GHZ com DDR3-16bit@606mhz.

http://www.adafruit.com/product/1876


Baseando-se nas informações que me prestaram, se eu tivesse DDR3-32bit@700mhz, a performance iria melhorar um pouco mais do que já esta, e não gritante, é isso ?

Sim, acho que o qumento de performance não seria muito grande não. Acho que não haveria muita diferença entre rodar uma DDR3-32 bits@500 MHz e rodar uma DDR3-32 Bits@700 MHz.

[fabim]

No caso 3) apesar das arquiteturas Harvards poderem endereçar RAM e FLASHes no mesmo range de endereços, ainda...

Harvards ? Ou Von ?

von neumann !! errei, pensei na rolinha atirei na pomba ! rsrs

[fabim]

A beaglebone Black REV C, é uma CPU-A7@1GHZ com DDR3-16bit@606mhz.

http://www.adafruit.com/product/1876


Baseando-se nas informações que me prestaram, se eu tivesse DDR3-32bit@700mhz, a performance iria melhorar um pouco mais do que já esta, e não gritante, é isso ?

Sim, acho que o qumento de performance não seria muito grande não. Acho que não haveria muita diferença entre rodar uma DDR3-32 bits@500 MHz e rodar uma DDR3-32 Bits@700 MHz.

NOPS: Digo DDR3-16bit@700mhz, ou DDR3-32bit@700mhz.
A performance teoricamente não é o dobro ! Correto ?:

[pbernardi]

Não deve ser o dobro, pois uma DDR3/16 bits@700 MHz = 700 MWords/s

Uma DDR3/32 bits@1400 MHz = 1400 MWords/s

Mas o core de 1 GHz deve ter uma capacidade aproximada de processar apenas 1000 MWords/s, logo no segundo esses 400 Mwords/s a mais devem ser disperdiçados. (a grosso modo, tem relação MIPS/MHz do core, cache, escritas e leituras de dados e não só de instrução e outras variáveis envolvidas).

[fabim]

HUM, uma luz foi setada pela passagem de zero da minha rede de vida !!
A grosso modo, eu sempre tenho que olhar logicamente e não levado em consideração o Clock do processador.

Barramento 16 bits 700mhz, = satisfatório
Barramento 32 bits 700mhz, = mais que satisfatório mais não necessariamente duas vezes mais satisfatório.
Barramento 32 bits 1000mhz, = ideal, pois a ram roda no mesmo Clock que o processados com palavras de 32 bits, o que logicamente tem uma performance muito melhor que as duas anteriores, haja visto que caso o ARM não fosse de 2.0 mips@mhz, poderia dizer com certeza que o programa rodando na ram, ou rodando no cache teria a mesma velocidade/rendimento.

Isso mesmo ?

Mas, como o A8 possui um rendimento de 2.0mips@mhz, logicamente o que for pego no ram que roda a 1ghz, e puxado para o cache, vai ser mais rápido, pois antes o gargalo era puxar dois Words por vez, agora puxa uma int por vez, e em uma velocidade 46% maior.
Desta forma poderia dizer que a sintonia esta perfeita.
uP_clock = 1GHZ-32bit
Mem = 1GHZ-32bit

Se comparar performance da BBB REV C, conforme link, com a BBB REV D com características que eu coloquei acima, logicamente a REV D teria uma performance muito melhor, correto ?


Como exemplo.
http://www.element14.com/community/comm ... riotboard/
1GHZ CPU - 800MHZ DDRx 32 BIT.

A DDR roda quase que nos 1GHZ da CPU, ou seja, quase que na sintonia ideal para poder retirar a melhor performance do sistema, CERTO ?

[pbernardi]

Bem por ai, fabim.

Só precisa considerar que, na prática, a cache da uma acelerada no acesso a memória.

Por exemplo, se você estiver um loop curto, contando de um até 1000 em uma função, as instruções vão ser copiadas da RAM para a cache em um primeiro momento, e depois disso, as outras 999 vezes as instruções vão ser rodadas diretamente da cache. Então, nesse momento, o barramento da RAM vai ficar parado, do ponto de vista das instruções.

Se você pegar isso num código completo, dá uma boa diferença. Então, com uma cache habilitada, talvez vc não precise de uma DDR3@1GHz, provavelmente uma com um clock um pouco mais baixo já dê uma performance bem parecida. Como os 800 MHz da placa que vc citou, por exemplo, parece estar bem próximo do ideal, levando em conta a cache.

[pbernardi]

Muito complexo para um fim de ano
Mas leia isto
https://community.freescale.com/mobile/ ... s%2F329671

Não consigo abrir esse link não, tcp.

[fabim]

HUMMMMMMMMMMMMMMMMMMMMMMMMMMMM !!
Viu, Viu, Viu estou entendendo.
Agora, o que ainda ninguém tem certeza é sobre o core rodar com 16 bits, e saber se o kernel deve ser gerado em 32 ou suporte a thumb.

Veja este link http://www.embarcados.com.br/beaglebone ... buildroot/
Quando ele manda acertar o kernel.

Observações do escritor:

Veja que foi selecionada a arquiteura ARM Cortex-A8 Little Endian e o set de instruções ARM. Vamos alterar este último para Thumb2.

ARM instruction set (Thumb2) --->

Bem, isto me da dor no stromo, pois, se discutimos até agora que o kernel se vira pra ajeitar as words de 16 bits, no cache ou no barramento de execução, modique, tenho que botar pra gerar o kernel em thumb ?

[pbernardi]

Pelo que eu lembro, o modo thumb foi criado originalmente para ocupar menos memória de armazenamento (FLASH). Parece que o pessoal no começo chorava que o código gerado pelo ARM ocupava muito "espaço em disco", requerendo componentes maiores. Coisas de programadores de PIC, hahaha .

Claro que reduzir o código de 32 para 16 bits tem seu preço, ou seja, aperformance do ARM caia e ficava uma m****! Então eles criaram o thumb2, colocaram umas intruções de 32 bits lá e parece que a performance ficou bem parecida como se o set inteiro de instruções fossem em 32 bits. Mas como boa parte das sintruções ainda são de 16 bits, o código acaba dando uma compactada.

[msamsoniuk]

No caso 3) apesar das arquiteturas Harvards poderem endereçar RAM e FLASHes no mesmo range de endereços, ainda...

Harvards ? Ou Von ?

na realidade a maioria dos processadores usa arquitetura de harvard com barramentos e caches separadas para instrucoes e dados. porem nada impede que os controladores de barramento trabalhem em um espaco de enderecamento unificado apos as caches. isso inclusive pode ser facilmente explorado para pendurar multiplos cores em um espaco unificado de memoria e permitir multiprocessamento simetrico. se ambas as caches estiverem com um cache hit, o core vai puxar uma instrucao e em paralelo ler/escrever um dado pelo outro barramento. se um deles tiver um cache miss, o core vai inserir wait-states naquele estado em especial. no pior caso, do core ter um cache miss em ambas as caches, ele vai enfileiras ambas, inserindo wait-states no primeiro cache miss e no segundo tambem. isso parece meio estranho, mas normalmente as buscas de instrucao e dados estao em pipelines diferentes. e claro, com a cache rola uma serie de maracutaias, tanto reduzindo a largura do bus para economia quanto aumentando. no caso da reducao, eh obvio, um core de 32 bits com caches de 32 bits pode operar a maior parte do tempo com um clock por acesso e zero wait-states, ao mesmo tempo que mantem uma memoria externa barata com largura de 8 ou 16 bits e varios wait-states. no caso do incremento, um ou varios cores de 32-bits vao operar da mesma forma, porem a alimentacao da cache pode ser feita com maior bandwidth se a largura do bus for de 64 ou 128-bits. eventualmente, pode rolar wait-states durante o acesso a memoria, mas transferencias sub-sequentes para a cache podem ser feitas com zero wait-states atraves de acessos em burst.

em resumo, o core e a arquitetura de memoria podem ser completamente diferentes!

[fabim]

então, pois é !!
A historia ta ficando muito legal, vamos continuar até matar a pau.