Execução da aplicação em máquinas com dual core [RESPONDIDO]

Ele está certo em parte. Por default, uma aplicação Java já usa cerca de 5 ou 6 threads para diversas coisas (interface com usuário, garbage collection, finalizers, New IO etc.). Entretanto, se sua aplicação não está preparada para usar vários processadores, ela não usará todo o potencial dos processadores.

Note que não estou falando explicitamente em “threads”. Não é preciso criar threads explicitamente no seu programa para usar vários processadores; entretanto, há várias APIs no Java 5 e 6 que criam essas threads, como as APIs de java.util.concurrent.

Uma forma muito usada de aproveitar todos os processadores de uma máquina é rodar várias aplicações em paralelo, tal como um web ou application server. Eles criam as “threads” para você; você não precisa se preocupar com a criação de threads.

Mas quando essa thread são criadas… a aplicação sabe quantos processadores ela possui a seu dispor para executá-las ?? Ou não preciso me preocupar em avisar isso (programar) ??

A divisão de serviço das threads pelos processadores é feita pelo sistema operacional. Entretanto, se seu programa processar tudo em uma única thread (por exemplo, um longo processamento de cálculo), então ele gastará em média o equivalente a um único processador - já que o serviço não pode ser dividido entre os processadores.

Hmm… saquei…

A execução de uma thread não pode ser dividida… apenas um dos processadores pode consumi-la…

Se eu tiver umas 10 thread, então, se o SO assim desejar, posso ter 5 thread’s sendo executadas por cada processador…

Agora se eu tiver apenas 1, então apenas um deles irá executa-la… já que um processo não pode ser dividido ao meio…

E tudo isso já é assim… não preciso alterar nenhum parâmetro no código fonte para que isso ocorra!

Vlw thiagol !!!

A arquitetura utilizado nos multcore da vida são SIMD (Instruções Simples e Múltiplos Dados). Isso significa que as instruções passadas para os processadores são sempre as mesmas, mas vários dados são acessados e tratados com essa mesmas instrução. Até onde vi de arquiteturas para alto desempenho, definir essa instrução depende do SO. Então ele vai sim utilizar todos os processadores.
Tb vi que o que o computador faz é verificar, a nivel de codigo assembler, quais partes do seu código podem ser paralelizadas, otimizando assim o processamento de forma transparente ao programador. Mas esses algoritmos nao sao perfeitos, no sentido de otimização, entao por isso as linguagems criam maneiras de o programador poder indicar quais partes do código sao totalmente paralelizáveis, que no caso de Java se faz basicamente criando Threads, direta ou indiretamente.
Baseado no exposto acima, uma aplicação JAVA, faria sim uso dos múltiplos processadores, ainda mais se houver Threads na mesma.
Agora o quanto essa utilização seria feita, dependeria tb da interação JVM->SO e SO->hardware.
Bom, acho que divaguei muito sobre o assunto , mas espero te ajudado.

Opa…

Ajudou sim…

Ficou bem claro o funcionamento… esse tópico me deu mais argumentos de dicutir com o técnico na próxima reunião… hehe

Vlw !

Seu colega está parcialmente certo.

Qualquer aplicação Java só vai se aproveitar de multiplos processadores se ela for escrita com concorrência em mente. (Threads).

PORÉM, dado que a aplicação se utiliza de threads, a JVM – ou melhor, o SO - será capaz de distribuir esta aplicação por múltiplos processadores automaticamente se o computador tiver múltiplos processadores.

Por fim, o amigo aí em cima se enganou: os processadores multicore que tem por aí tipo Core2 e Athlon X2 Dual Core não são SIMD.

domingos.neto:

Seu colega está parcialmente certo.

Qualquer aplicação Java só vai se aproveitar de multiplos processadores se ela for escrita com concorrência em mente. (Threads).

PORÉM, dado que a aplicação se utiliza de threads, a JVM – ou melhor, o SO - será capaz de distribuir esta aplicação por múltiplos processadores automaticamente se o computador tiver múltiplos processadores.

Por fim, o amigo aí em cima se enganou: os processadores multicore que tem por aí tipo Core2 e Athlon X2 Dual Core não são SIMD.

Bom, nesse site (http://www.intel.com/portugues/technology/magazine/computing/new-instructions-1006.htm)
diz que são SIMD sim. Apesar de ter dormido muito nas aulas, lembro bem que fazer um controlador pra SIMD já era uma coisa complicada (tivemos que fazer um simplificado que já foi difícil), quanto mais para um MIMD (Multiplas Instruções Multiplos Dados).
Devido a essa complexidade, a nível comercial, nao sei de nenhum computador construido com essa arquitetura. Dei uma pesquisada na internet e realmente nao encontrei um computador MIMD, no máximo encontrei o vetorial.
Mas se tiver algum, seria legal se passasse o link pra eu levar para o professor e para o pessoal da minha sala.

O que este artigo se refere como SIMD são apenas extensões específicas dos processadores x86 voltadas a processamento aritmético e multimídia. Estes instructions sets não são relacionados ao fato de o processador ter ou não múltiplos núcleos.

thingol:

Um dos técnicos presentes na reunião foi tão convicto na afirmação (“Se a aplicação não estiver preparada para usar os dois processadores, ela não usará!”) que nem me atrevi em dicutir no momento, mas fiquei com a pulga na orelha.

Ele está certo em parte. Por default, uma aplicação Java já usa cerca de 5 ou 6 threads para diversas coisas (interface com usuário, garbage collection, finalizers, New IO etc.). Entretanto, se sua aplicação não está preparada para usar vários processadores, ela não usará todo o potencial dos processadores.

Note que não estou falando explicitamente em “threads”. Não é preciso criar threads explicitamente no seu programa para usar vários processadores; entretanto, há várias APIs no Java 5 e 6 que criam essas threads, como as APIs de java.util.concurrent.

E se eu quisesse explicitamente criar threads para obter vantagem dos múltiplos processadores? Como ficaria? Não seria meio POG? Primeiro que eu teria que descobrir quantos processadores eu tenho – e não sei se a API do Java tem algo assim, e depois, teria que em todos os pontos sensíveis dividir o processamento entre threads, e me pergunto se isso vai ser sempre possível.

Por exemplo, imagina que o meu programa vai calcular o hash de um arquivo muito grande num Core2 Duo. Teria como criar 2 FileInputStream para ler o arquivo, um em cada thread, com o outro stream começando do meio do arquivo? Mesmo que desse, isso não é POG?

Realmente estava enganado, achei um paper falando o contrário: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04428984
Vlw pelo toque domingos.neto

Agora que uma thread seja responsabilidade de apenas um processador, isso já não sei realmente. Em geral o pessoal que projeta essas coisas não gosta de confiar no programador, já que se ele nao utilizasse Threads não haveria ganho nenhum.

Quanto a parte que as vezes tb dizem de colocar Threads não ser vantajoso para um sistema com único processador, isso não é verdade, já que pelo menos a indicação da thread tornaria o uso do pipeline mais eficiente, já que isso ajuda o sistema preditor, entre outras coisas, melhorando assim a performance.

Nesse link ele fala sobre a diferença entre concorrência e paralelismo no final, achei interessante http://64.233.169.104/search?q=cache:buyCypFHrTsJ:www.cs.mu.oz.au/678/Threads.ppt+pipeline+thread+java&hl=pt-BR&ct=clnk&cd=1&gl=br

Encontrei outro link bacana que fala de threads no contexto do usuário e no contexto do SO: http://www.heise.de/ct/english/98/13/140/
Realmente a Thread do usuário roda em apenas um processador, já o outro tipo de Thread, do SO, pode executar em vários.
Eu tava confundindo as duas, foi mal aí galera.
Enfim, não devia ter dormido tanto nas aulas de arquitetura.

Ixi…

faz tempo que assisti as aulas de arquitetura… e realmente enferrujei no core desse assunto.

Mas se bem me lembro a fila dos processos (pipeline) é executada de forma a alterna-los dentro do processador… dessa forma todos os processos tem uma chance (acho que isso todos sabem, neh)

Pelo que li nos artigos dos links acima… nenhum deles sita a possibilidade de quebrar uma thread ao meio para ser executada por multiplas thread’s… e acho que isso realmente não tem como acontecer… afinal, um processo eh um processo e deve ser executado “uniformemente”!

Mas achei interessante o “Supplemental SSE3” da intel… pelo que entendi, os caras acharam uma forma de otimizar a leitura da thread… fazendo com que ele seja consumido pelo processador mais rápido e com isso ocupa menos tempo de processamento… muito bom…

Me parece que qse tudo que eh tecnologia melhora, não só no hardware, mas principalmente nos algoritmos que ficam cada vez menores e mais eficientes… algo que parece não ter mais como melhorar, tem nego que acha um jeito e cria um algoritmo revolucionário… muito bacana !!!

=]