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

Quem tem que se preocupar com isso em primeira instância é o compilador e depois o SO.

Se você precisar “controlar” o processamento paralelo, ai sim, vc tem que colocar a mão na massa, mas como falei, quem tem que se preocupar em usar todo o poder do processador é o SO e o compilador.

Posso estar muito enganado, mas ficar se preocupando com esse tipo de coisa, pelo menos para mim, é perdade tempo caso você não precise lidar com processamento paralelo diretamente. É a mesma coisa você ter que ficar se preocupando se o motor do seu carro tem x ou y cilindros.

[]'s

eduacsp:

Pessoal,

Vcs acham que essa onde de core2duo, i3,i5,i7 etc…vai deixar a programação Java ainda mais complicada? Pq pelo que sei, a divisão do processamento entre núcleos não ocorre assim de forma tão natural. Por exemplo, para preencher ou ler um simples Map<String,String>, temos que dividir o preenchimento entre os núcleos de forma programatica usando Threads, já que o processador não faz isso. Sei que 99,9% dos desenvolvedores não fazem isso, mas algum dia terão de fazer quiserem softwares performaticos.

Programação OO vai ficar mais complicada, nao só em Java.

Ainda bem que temos Scala, e pricipalmente Clojure, pra nos salvar quando essa hora chegar.

davidbuzatto:

Quem tem que se preocupar com isso em primeira instância é o compilador e depois o SO.

Se você precisar “controlar” o processamento paralelo, ai sim, vc tem que colocar a mão na massa, mas como falei, quem tem que se preocupar em usar todo o poder do processador é o SO e o compilador.

Posso estar muito enganado, mas ficar se preocupando com esse tipo de coisa, pelo menos para mim, é perdade tempo caso você não precise lidar com processamento paralelo diretamente. É a mesma coisa você ter que ficar se preocupando se o motor do seu carro tem x ou y cilindros.

[]'s

Acho que vai demorar um bocado para ser algo transparente assim para o usuário.

Existem cada vez mais linguagens que trabalham com scabilidade.
É o caso do scala.
Muitas outras linguagens e frameworks devem chegar para isso, já que se tem notícias dos multi-processadores chegando nos celulares também.

davidbuzatto:

Quem tem que se preocupar com isso em primeira instância é o compilador e depois o SO.

Se você precisar “controlar” o processamento paralelo, ai sim, vc tem que colocar a mão na massa, mas como falei, quem tem que se preocupar em usar todo o poder do processador é o SO e o compilador.

Posso estar muito enganado, mas ficar se preocupando com esse tipo de coisa, pelo menos para mim, é perdade tempo caso você não precise lidar com processamento paralelo diretamente. É a mesma coisa você ter que ficar se preocupando se o motor do seu carro tem x ou y cilindros.

[]'s

Concordo, mas algum dia todos nós vamos ser requisitados para deixar o software o mais rápido possível, e se vc fez todas as refatorações possíveis, a única coisa que vai restar é refatorar para deixar compatível com o número de núcleos do processador.

Oi mochuara, não é bem isso que falei.

Por exemplo, estou falando que não é pq seu código não é multithread que ele vai rodar em apenas um núcleo. Quem vai cuidar disso é o SO, não você. Se você quer “garantir” a execução em paralelo, então você programa dessa forma, mas como falei, o SO vai fazer o que ele achar melhor, além do compilador otimizar o código. É claro, se você programar de forma a usar os recursos do processador, realmente o desempenho vai ser maior, mas mesmo assim, duvido que o SO não tente usar o poder do processador. Acredito até que o próprio processador possa tomar algumas deciões. Acredito que o pessoal que trabalha mais perto do hardware, ou mesmo que conheça mais esses tipos de detalhes, possa nos dar algumas respostas mais perto da realidade.

[]'s

Sim, não estou dizendo o contrário. Concordo que hajam softwares que precisam utilizar o máximo do poder do processador, mas não concordo com você no ponto que cada programa vai precisar saber quantos núcleos tem o processador. Como falei, acho que os processadores atuais devem ser espertos o bastante para direcionar as instruções que passam pelo processo de adminissão para o núcleo apropriado. Já pensou se a gente tivesse que compilar um código para um processador de 2 núcleos, para um de 4, 8, etc?

[]'s

Sim, não estou dizendo o contrário. Concordo que hajam softwares que precisam utilizar o máximo do poder do processador, mas não concordo com você no ponto que cada programa vai precisar saber quantos núcleos tem o processador. Como falei, acho que os processadores atuais devem ser espertos o bastante para direcionar as instruções que passam pelo processo de adminissão para o núcleo apropriado. Já pensou se a gente tivesse que compilar um código para um processador de 2 núcleos, para um de 4, 8, etc?

[]'s

Mas e em alguns casos onde nem o processador, nem o compilador pode dividir o processamento? como o preenchimento de alguma Collection? Nesses casos não tem como, tem que dividir pelo código.

Sim, não estou dizendo o contrário. Concordo que hajam softwares que precisam utilizar o máximo do poder do processador, mas não concordo com você no ponto que cada programa vai precisar saber quantos núcleos tem o processador. Como falei, acho que os processadores atuais devem ser espertos o bastante para direcionar as instruções que passam pelo processo de adminissão para o núcleo apropriado. Já pensou se a gente tivesse que compilar um código para um processador de 2 núcleos, para um de 4, 8, etc?

[]'s
Realmente, isso perderia uma das características do Java (portabilidade) e dificultaria também o desenvolvimento em outras linguagens…

Uai, então não divide. Sei que você deu só um exemplo, mas este não foi um dos melhores. Pq eu dividiria o preenchimento de uma coleção?

Motivo do ponto de vista do desenvolvedor: Para manter a segurança dos dados.

Motivo do ponto de vista do usuário: Se a Collection for mt grande, pode impactar na performance]

Motivo do ponto de vista do processador: Eu não vou dividir, pq senão posso fazer besteira e duplicar dados na Collection

O que dividir ou não um determinado processo impacta na “segurança” de algum dado? Não entendi o que você quis dizer.

Hummmm mas a coleção fica em memória, não no processador.

O processador não sabe o que é uma coleção. Uma coleção é uma abstração, feita em uma determinda linguagem (Java por exemplo), talvez gerenciada por uma determinada máquina virtual (JVM por exemplo, que por sua vez não sabe o que é uma coleção tbm). O que a JVM conhece são classes, tipos primitivos, etc. Uma coleção não é um tipo primitivo, mas sim um tipo criado não é mesmo? Se a gente for pensar dessa forma, o processador ou a máquina virtual teriam que conhecer todas as classes do JDK, além de conhecer as classes que criamos.

davidbuzatto:

Oi mochuara, não é bem isso que falei.

Por exemplo, estou falando que não é pq seu código não é multithread que ele vai rodar em apenas um núcleo. Quem vai cuidar disso é o SO, não você. Se você quer “garantir” a execução em paralelo, então você programa dessa forma, mas como falei, o SO vai fazer o que ele achar melhor, além do compilador otimizar o código. É claro, se você programar de forma a usar os recursos do processador, realmente o desempenho vai ser maior, mas mesmo assim, duvido que o SO não tente usar o poder do processador. Acredito até que o próprio processador possa tomar algumas deciões. Acredito que o pessoal que trabalha mais perto do hardware, ou mesmo que conheça mais esses tipos de detalhes, possa nos dar algumas respostas mais perto da realidade.

[]'s

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

Uai, então não divide. Sei que você deu só um exemplo, mas este não foi um dos melhores. Pq eu dividiria o preenchimento de uma coleção?

Porque vc pode.

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).

davidbuzatto:

Mas não é isso que estou falando?

ah ta, foi mal!

ViniGodoy:

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.

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/

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!

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

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

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

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:

def setMaxThreads = {
  val maxThreads = (Runtime.getRuntime.availableProcessors * 2)
  System.setProperty("actors.maxPoolSize", maxThreads.toString)
}

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

Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors() *2);

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

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.

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.

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 :oops:
Deve ser a contagem regressiva pro ano-novo :XD: