Entrar    Registrar

LIW

Software e Hardware para linha x86

Moderadores: andre_teprom, 51

  • Autor
    Mensagem

LIW

Mensagempor mastk » 01 Jan 2011 14:02

Sabe esses dias estava estudado pesadamento sobre os processadores atuais.

Particulamente, fiquei admirado com a ideia de simplificar o processador para possibilitar operacoes superescalares. Passando a CPU de CISC para RISC. Mas a partir do momento onde vc tem 8 ALUs uma dedicada a cada tipo de operacao, a maior parte do projeto com circuitos de prognostica de ramos e predicao de desvios, acho que algo esta errado.

Ate hoje me lembro do lancamento do Pentium 4, com seu pipeline de 20 estagios, que intel falou que quase nunca falhava, mas na pratica era pior que cego em tiroteio.

E ai, me vem esse trabolho, que pensei que tinha ido pro lixo:

Imagem

Com um conceito novo, LIW (Large instruction word), que ao meu ver nao faz muito sentido. Mas uma coisa devo dizer, eh bonito rs.

Execulcao especulativa, tb, que abominacao, fico pensado na area de silicio usado para prever o que pode ser execultador fora de ordem, marcar como execultado e depois reordenar os caches.

E o pior de tudo, que me assusta o quanto deve deixar o projeto complexo, esses trens nao rodam seu codigo nativo, eles rodam codigo legado sendo convertido em tempo real.

Ja pensaram o quanto mais rapidos seriam os computadores hoje, se por exemplo em vez de emulacao em silicio, fossem usado emuladores por software e assim eliminado com o tempo o codigo legado? Creio que niguem mais usa tango para DOS ou Lotus123 e mesmo que use, se a CPU conseguir usar plenamentes seus recursos, creio, que compensaria a emulacao tendo pouco penalidade em desempenho.

Enfim, olho para o Ipad e fico com cada vez menos vontade de ligar meu PC...
Sim, mesmo se alguém conquistar apenas uma alma, uma única alma em todo o mundo. Mas aquele que não foi capaz disso, que fique chorando sozinho!

http://mastk.wordpress.com/

http://www.youtube.com/user/Mastk2008
Avatar do usuário
mastk
Dword
 
Mensagens: 4336
Registrado em: 14 Out 2006 20:43

Mensagempor msamsoniuk » 01 Jan 2011 18:14

a grande vantagem do software eh a flexibilidade, mas eu cheguei a conclusao de que essa flexibilidade apenas atrasa a vida, pois desperdica um grande potencial computacional presente nos processadores.

no exemplo abaixo vc pode ver como flexibilidade e performance sao coisa bem opostas! voce pode comecar pensando em uma unidade computacional bem eficiente:

Código: Selecionar todos
module mac(CLK,WEX,WEY,WEZ,VEC,DI,DO);

    input           CLK;
    input           WEX;
    input           WEY;
    input           WEZ;
    input           VEC;
    input   [15:0]  DI;
    output  [15:0]  DO;

    reg     [15:0]  DX;
    reg     [15:0]  DY;
    reg     [15:0]  DZ;

    assign DO = DZ;

    always@(posedge CLK)
    begin
        if(VEC)
        begin
            if(WEX)
                DX <= DI;
            if(WEY)
                DY <= DI;
            if(WEZ)
                DZ <= DZ+DX*DY;
        end
    end

endmodule


em essencia, cada unidade computacional destas eh capaz de fazer 125 MMAC/s em uma spartan XC3S250E. a ideia eh carregar previamente em DY um coeficiente constante e entao continuamente carregar em DX um valor, multiplicar e acumular em DZ.

como uma XC3S250E possui 12 multiplicadores deste, eh possivel facilmente projetar uma unidade vetorial:

Código: Selecionar todos

module vec(CLK,WEX,WEY,WEZ,VEC,ADDR,DI,DO);

    input           CLK;
    input           WEX;
    input           WEY;
    input           WEZ;
    input   [0:11]   VEC;
    input   [3:0]   ADDR;
    input   [15:0]  DI;
    output  [15:0]  DO;

    wire    [15:0]  DZ [0:11];

    assign DO = DZ[ADDR];
   
    mac mac00(CLK,WEX,WEY,WEZ,VEC[00],DI,DZ[00]);
    mac mac01(CLK,WEX,WEY,WEZ,VEC[01],DI,DZ[01]);
    mac mac02(CLK,WEX,WEY,WEZ,VEC[02],DI,DZ[02]);
    mac mac03(CLK,WEX,WEY,WEZ,VEC[03],DI,DZ[03]);
    mac mac04(CLK,WEX,WEY,WEZ,VEC[04],DI,DZ[04]);
    mac mac05(CLK,WEX,WEY,WEZ,VEC[05],DI,DZ[05]);
    mac mac06(CLK,WEX,WEY,WEZ,VEC[06],DI,DZ[06]);
    mac mac07(CLK,WEX,WEY,WEZ,VEC[07],DI,DZ[07]);
    mac mac08(CLK,WEX,WEY,WEZ,VEC[08],DI,DZ[08]);
    mac mac09(CLK,WEX,WEY,WEZ,VEC[09],DI,DZ[09]);
    mac mac10(CLK,WEX,WEY,WEZ,VEC[10],DI,DZ[10]);
    mac mac11(CLK,WEX,WEY,WEZ,VEC[11],DI,DZ[11]);
   
endmodule


neste caso a performance de pico seria de 1500 MMAC/s. mas como estamos falando em software, a coisa nao eh tao eficiente. se for pensar em memoria externa, tem o compromisso de largura de bus vs bandwidth. e com apenas um barramento de 16 bits, o bandwidth efetivo eh de apenas 250MB/s.

eh possivel carregar multiplos registros na mesma instrucao e fazer os MAC ao mesmo tempo em paralelo, porem se os coeficientes ou dados forem todos diferentes, seria necessario uma instrucao por registro. daih na pratica seria necessario primeiro fazer 12 instrucoes load, uma instrucao de mac vetorial e entao 12 instrucoes store.

o resultado eh que seriam necessarios 25 clocks para fazer 12 operacoes MAC, o que resultaria em meros 60MMAC/s. o gargalo estaria concentrado justamente nos load/store.

mas claro, isso depende do tipo de filtro. uma outra possibilidade seria, ao inves de pensar em 12 filtros separados, pensar em um filtro de 12 termos. neste caso seria necessario apenas uma instrucao load e uma store em meio a uma mac vetorial, o que totalizaria 3 clocks para 12 operacoes e resultaria em 500MMAC/s.

a diferenca eh que cada resultado DZ seria o proximo DX, evitando mover dados pelo barramento externo. ainda assim, teria apenas 1/3 da maxima performance possivel, sem falar que seria uma solucao bem dedicada, ou seja, estaria perdendo muito a flexibilidade de software.

a melhor performance mesmo seria fazer tudo fixo: um DMA puxando valores de DX, com os DZ entrando no proximo DX e o resultado final no ultimo DZ sendo gravado em outra memoria. a flexibilidade seria zero, mas atingiria entao os 1500MMAC/s.

a conclusao eh simples: quando mais flexivel em software, pior a performance! :)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Mensagempor mastk » 01 Jan 2011 18:50

Tal como se faz hoje. Vc poderia sintetizar caches de entrada e saida, aumentando o bandwitch, pode chegar a uma situacao ideal.

Sim, quanto mais fixo melhor, e dessa rigidez torna-se possivel velocidades mais altas, operar de forma superescalar, deve ser impossivel ter uma maquina plenamente CISC rodando mais de um instrucao por clock.

Imagine um PIC de 400Ghz com 25 instrucoes simples, com paralelismo, ele pode emular sem problemas um nucleo mais decente, com velocidade satisfatorias, tendo software nativo para ele, pronto, plena performace.

Isso todo me faz pensar em picoblazer com mais carinho rs.
Sim, mesmo se alguém conquistar apenas uma alma, uma única alma em todo o mundo. Mas aquele que não foi capaz disso, que fique chorando sozinho!

http://mastk.wordpress.com/

http://www.youtube.com/user/Mastk2008
Avatar do usuário
mastk
Dword
 
Mensagens: 4336
Registrado em: 14 Out 2006 20:43

Mensagempor msamsoniuk » 01 Jan 2011 19:47

o picoblaze eh bem compacto e simples, mas eu acho que aproveita mal o hardware da FPGA, pq a simplificacao nao impacta em melhorar o clock. o melhor entao eh tentar justamente extrair o maximo possivel de paralelismo a cada clock que vc tem direito.

e eu acho que um ponto de partida melhor eh esse aqui:

http://excamera.com/sphinx/fpga-j1.html

alem de ser um processador com mais recursos, o J1 tem um nivel de evolucao extra: eh programado em forth e nao possui asm! um terror para os amantes do asm, mas o fato de ter o verilog disponivel permite fazer modificacoes e otimizacoes conforme o caso! hehehe :)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Mensagempor vtrx » 02 Jan 2011 11:42

eh programado em forth e nao possui asm!

Se voce não usar ASM,não poderá usar as instruções "PICK"e "ROLL" que não são acessiveis na memória normal,isto é,não poderá programar por completo...
Poderá tambem juntar em uma única instrução,diferentes funções da ALU usando ASM.
Tem um PDF interessante enfatizando estas otimizações;
http://www.excamera.com/files/j1.pdf
vtrx
Dword
 
Mensagens: 1768
Registrado em: 20 Abr 2008 21:01

Voltar para Intel x86

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron