A onda dos proc. de multiplos núclelos vai deixar a programação ainda mais complicada?

mochuara wrote:Claro que SO/JVM vai cuidar, mas o programador vai ter que especificar o processamento a ser feito em paralelo, por meio da API.

Mas não é isso que estou falando?

Na verdade, os principais gargalos de processamento, há muito tempo, já estão fora da CPU. Então, quando se fala em otimização, a menos que você tenha um programa estritamente matemático, é difícil que um único core chegue a ter 100% de ocupação. Basta dar um CTRL+ALT+DEL e olhar seu gerenciador de desempenho. Você vai ver que a maior parte do tempo, a ocupação do seu core dificilmente ultrapassa 20%.

Para otimizar isso, não só o software, mas o hardware teria que dar mais suporte. Em especial, eliminando gargalos fora do core. Tem que ser possível, por exemplo, ter acesso de dois cores simultâneos ao disco, coisa que até então, não é possível (ele é time-shared, não simultâneo).

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

davidbuzatto wrote:
Mas não é isso que estou falando?

ah ta, foi mal!

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

ViniGodoy wrote:Na verdade, os principais gargalos de processamento, há muito tempo, já estão fora da CPU. Então, quando se fala em otimização, a menos que você tenha um programa estritamente matemático, é difícil que um único core chegue a ter 100% de ocupação. Basta dar um CTRL+ALT+DEL e olhar seu gerenciador de desempenho. Você vai ver que a maior parte do tempo, a ocupação do seu core dificilmente ultrapassa 20%.

Para otimizar isso, não só o software, mas o hardware teria que dar mais suporte. Em especial, eliminando gargalos fora do core. Tem que ser possível, por exemplo, ter acesso de dois cores simultâneos ao disco, coisa que até então, não é possível (ele é time-shared, não simultâneo).

Tem razão, só será util para computações realmente intensivas.

mochuara wrote:Tem razão, só será util para computações realmente intensivas.

Intensivas e pouco interdependentes. Não é à toa que placas de vídeo já se benefíciam de mais de 100 cores há bastante tempo. Como o cálculo de cada matriz é relativamente independente, é fácil paralelizar coisas por lá. Esse seria o ponto onde precisaríamos melhorar a aplicação.

Especialiastas andam dizendo que estamos chegando ao limite de processamento por nucleo, e realmente vai ser necessario uma ajuda dos desenvolvedores para aproveitar as tecnologias multi-cores.

http://www.gizmodo.com.br/conteudo/pesquisadores-criam-processador-de-mil-nucleos/
http://idgnow.uol.com.br/mercado/2010/12/29/acha-seu-pc-lento-vem-ai-o-processador-de-1-000-nucleos/

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

ViniGodoy wrote:

mochuara wrote:Tem razão, só será util para computações realmente intensivas.

Intensivas e pouco interdependentes. Não é à toa que placas de vídeo já se benefíciam de mais de 100 cores há bastante tempo. Como o cálculo de cada matriz é relativamente independente, é fácil paralelizar coisas por lá. Esse seria o ponto onde precisaríamos melhorar a aplicação.

Isto é mesmo um problema para sistemas OO. Bem lembrado!

GUJ Ranger Membro desde: 29/03/2006 21:29:35 Mensagens: 897 Offline

Marky.Vasconcelos wrote:Especialiastas andam dizendo que estamos chegando ao limite de processamento por nucleo, e realmente vai ser necessario uma ajuda dos desenvolvedores para aproveitar as tecnologias multi-cores.

Finalmente alguém entendeu o q quis dizer!. Vlw Marky!

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Chip designers are under so much pressure to deliver ever-faster CPUs that they?ll risk changing the meaning of your program, and possibly break it, in order to make it run faster

http://gotw.ca/publications/concurrency-ddj.htm

Apesar do autor parecer confundir concorrencia com paralelismo, mesmo assim uma boa leitura.

se não estou enganado, tem um artigo recente, ou na mundoj ou na java magazine falando desse assunto (como dividir o processamento entre os núcleos).

PS: Quando li pela primeira vez no título "multi-cores" não entendi como "muitos nucleos" mas como "um monte de cores" (vermelho, azul, etc) hehehe

Deve ser a contagem regressiva pro ano-novo

Concordo com o davidbuzatto, nós não vamos escolher quais cores esta o que, mas podemos sim definir a quantidade de Thread's baseado na quantidade de cores, quanto mais cores, mais threads são interessantes criar.

Por exemplo num exemplo de Scala que estou vendo ele acha que o legal seria 2*quantidadeCores, e tem até este exemplo de código:

O mesmo poderiamos fazer com os Executors do java ou manualmente.

Claro que o SO/JVM tem que ser inteligente o bastante para dividir nossas thread nos varios nucleos, ai sim acho que teriamos performance.

Virtual Machine Man Membro desde: 15/08/2006 16:15:11 Mensagens: 598 Offline

ola!

Tambem acho que muitas coisas tem que ser controladas via codigo. O c# 4 por exemplo, para as Collections, tem metodos que abstraem a utilizacao de mais de um processador.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

fredferrao wrote:
Claro que o SO/JVM tem que ser inteligente o bastante para dividir nossas thread nos varios nucleos, ai sim acho que teriamos performance.

Ele deve ser capaz de inferir a melhor configuração a partir do tipo do seu sistema, por exemplo, se computacionalmente intensivo como disse o Vini, ou I/O intensivo.

Acho que esta descrevendo um futuro mais complicado do que deveria.

Notícias, artigos e o maior fórum brasileiro sobre Java