Clique abaixo para nos ajudar
Login

Esqueci minha senha

Estamos no Facebook
Buscar
 
 

Resultados por:
 


Rechercher Busca avançada

Quem está conectado
13 usuários online :: Nenhum usuário registrado, Nenhum Invisível e 13 Visitantes :: 1 Motor de busca

Nenhum

[ Ver toda a lista ]


O recorde de usuários online foi de 468 em 1/3/2012, 10:43
Últimos assuntos
» Ajuda a direcionar
Hoje à(s) 01:17 por miiiih

» Alterar uma palavra num arquivo de texto
5/12/2016, 12:02 por Teseu

» Buscar endereço por CEP
3/12/2016, 19:59 por pedrossian

» USAR WEBSERVICE NO VFP9
2/12/2016, 09:50 por AJC

» BANIMENTO DE USUARIO
17/11/2016, 08:31 por FAF

» Impressora Ticket
15/11/2016, 09:20 por clima238

» Gráfico
9/11/2016, 10:43 por hidroluz

» TRANSPOR TABELA
9/11/2016, 10:34 por hidroluz

» MUDANÇA DO .DBF PARA POTSGREE
9/11/2016, 09:12 por AJC

» Website com videoaulas sobre linguagens de programação
8/11/2016, 09:56 por JLDR

» Parceria para desenvolvimento de template em Wordpress
7/11/2016, 19:15 por mindix

» Data fica invertida na planilha que é gerada via programa.
27/10/2016, 11:00 por Linghston

» Maximizar report direto do menu
21/10/2016, 20:48 por Rosangela Pires

» Fechar form com tempo
21/10/2016, 10:15 por Rosangela Pires

» URGENTE: Ajuda com impressora ELGIN-L42
14/10/2016, 09:53 por megasoft

» Opções para gerar NF-e
10/10/2016, 09:07 por mavsinfo

» Google Maps
8/10/2016, 15:08 por Rosangela Pires

» Mysql
5/10/2016, 11:22 por Marcos Guedes

» Acessando Banco em MYSQL de um projeto WORDPRESS
3/10/2016, 10:58 por Marcos Guedes

» OPTION SELECT MOSTRAR CAMPOS QUASE PRONTO
26/9/2016, 21:09 por BobKuspe

Alterar uma palavra num arquivo de texto

5/12/2016, 12:02 por Teseu

Olá prezados colegas de programação!

Este é eu primeiro post no fórum e gostaria de poder …

Comentários: 0

Buscar endereço por CEP

3/12/2016, 19:59 por pedrossian

Caros amigos, meu código para buscar endereço pelo CEP não funciona mais.
Alguém pode me …

Comentários: 0

USAR WEBSERVICE NO VFP9

2/12/2016, 09:50 por AJC

Pessoal, preciso de um material ou livro que me traga instruções como
usar a consumação de …

Comentários: 0

BANIMENTO DE USUARIO

13/11/2016, 16:21 por FAF

A usuária ROSANGELA PIRES ao tentar acessar o Forum obtem sempre a mensagem de BANIMENTO.
A mesma …

Comentários: 3

Impressora Ticket

15/11/2016, 09:20 por clima238

Bom dia,
Por favor alguém me explique porque o código abaixo imprime no ecrã em vez do printer: …

Comentários: 0

Estatísticas
Temos 6963 usuários registrados
O último usuário registrado atende pelo nome de miiiih

Os nossos membros postaram um total de 17119 mensagens em 2577 assuntos

O gap entre a evolução do hardware e as linguagens de programação

Ver o tópico anterior Ver o tópico seguinte Ir em baixo

Informativo O gap entre a evolução do hardware e as linguagens de programação

Mensagem por alessandrohmachado em 28/12/2011, 10:32

Recentemente li 3 artigos fantásticos sobre o funcionamento do cache L1 e L2 (http://igoro.com/archive/gallery-of-processor-cache-effects/), sobre o impacto

que o paradigma de orientação a objeto tem sobre os tempos de acesso á memória, a perda do cache e os impacto disso no programa como um todo

(http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf) e sobre Programação Orientada a Dados

(http://gamesfromwithin.com/data-oriented-design). E isso me fez refletir se estamos realmente usando as melhores práticas de programação ou se muito disso

não passa de ilusão ou abstração da realidade.

Se você é um programador em linguagem de alto nível, que esta mais no ramo de aplicações comerciais ou utiliza algum tipo de ferramenta case, pra você,

talvez isso não importe muito, afinal se a tela demorar 0.2s ou 1.2s, pro usuário não faz diferença, ele não vai notar, mesmo que demorasse 2s, ou até 3s, já

que ele esta acostumado a esperar o Windows carregar, esperar a pagina carregar, esperar o programa iniciar, pra ele é normal esperar um pouquinho. E pra

você que diferença faz, se pra abrir uma tela do seu programa, que emite a nota fiscal, o PC tiver que executar 1 milhão de instruções que não estão

diretamente relacionadas ao que seu programa tem que fazer, por exemplo, coletor de lixo, checagem de pilha/heap e tantas outras coisas, afinal 1 milhão de

instruções não significa nada em termos de tempo, já que as cpus modernas rodam a 3GHz ou mais, executar 1 milhão de linhas a mais, cada vez que abre a tela

de notas fiscais não é nada, e tambem se cada registro da nota fiscal no banco de dados pudesse ocupar 10K no disco, na melhor das hipoteses, mas esta

ocupando 20K, e dai, hoje temos discos da ordem de Terabytes, isso tudo que estou falando não tem muito sentido pra você. Já se você é daquele tipo de

programador que já teve curiosidade de desassemblar uma função ou trecho de código que você fez pra ver no que se transformou o seu código e aquele if que

você colocou na sua lógica, como é que fica em linguagem de máquina, e notou que quando se coloca inline na frente da função o compilador não gera as

instruções necessárias para empilhar os parametros e nem a chamada da função, e que isso faz uma boa diferença, se a função for chamada inúmeras vezes,

dentro de um loop por exemplo, então, você é do tipo que entende do que eu to falando.

Me sinto como um mestre de obras (programador), em um canteiro de obras Chines, tendo a planta do prédio (problema a ser resolvido) só na minha mente, tendo

que passar as instruções aos operários (core´s da cpu), sobre o que construir e o que cada um deve fazer (cada core da cpu), tendo que escrever em forma de

verso e prosa (linguagem de programação), e traduzir isso pro mandarim usando google translator (compilador)(tradução ao pé da letra). Neste cenário, a única

forma de saber se os operários entenderam o que deve ser feito é ver o resultado (testar/depurar o executavel), e claro, nada vai ser exatamente como o

esperado a princípio, após sucessivas interações de comunicação com os operários, reescrevendo as instruções e revendo os resultados obtidos

(testes/depuração/correções), é que vão surgindo o resultado desejado, mas quase sempre a um custo e prazo além do rasoável.

Penso se há meios de melhorar essa comunicação, gostaria de sussurar ao invés de ter que gritar do outro lado do quarteirão o que o computador tem que fazer.

É como se eu estivesse em um prédio de 50 andares (software em camadas) tentando falar com um cara na calçada lá em baixo (cpu) !!!!

Recentemente li em um livro (Como quebrar códigos. Greg Hoglund/Gary McGraw) que a estimativa de bugs em um software fica entre 5 a 50 por 1000 linhas de

código e que o Windows XP tem aprox. 40 milhões de linhas de código, logo, no melhor caso, estamos falando em estimados 200 mil bugs. Não tenho bases para

comparar, mas se na construção de um software como o Windows XP, foi necessário, em termos de número de programadores, horas/homem e investimento, algo

similiar aos necessário para executar projetos de engenharia, como por exemplo, a construção das torres Petronas, na Malásia, ou a maior torre de TV do

mundo, em Guanzhou, na China, seria como se logo após concluída, a estrutura apresentasse infiltração de agua em dias de chuva, rachaduras em algumas

paredes, a falta de algumas janelas e a presença de algumas portas onde não deveria existir, pra ser bem otimista. Isso me leva a questionar se as

ferramentas e as metodologias que temos a disposição hoje, realmente ajudam a fazer software mais rapidamente e com poucos defeitos numa escala tão grande

quando a demanda atual por software no mundo, e infelismente, a resposta me parece ser NÃO.

Isso me leva a crer que a disciplina de desenvolvimento de software não evoluiu na mesma proporção que outras engenharias. Muitos classificam a atividade de

programação como arte, algo abstrato e imprevisível. À mim, me parece mais estar ligada a área de exatas, em especial á area de engenharia, como a mecânica,

a civil, a naval e a aerospacial. Nestas temos softwares CAD (Desenho "Assistido por Computador") que permitem a visualização em 3D do produto/estrutura e

nos permite simular e prever o seu comportamento antes mesmo da construção. Na programação não temos nada parecido com uma visualização 3D do programa que

estamos construindo, muito menos um desenho assistido (CAD) que nos permita simular seu comportamento diante das forças a que será submetido (usuários,

hackers, so, etc), na fase de projeto, antes de ser construído. Seguindo esta analogia o desenho de projeto de engenharia evoluiu da prancheta para o sofware

CAD e as ferramentas e linguagens de programação, evoluiram em que direção ?

É obvio que as ferramentas e linguagens de programação evoluiram, desde os primordio do Assembler, mas me parece que não na mesma direção das engenharias e

nem do hardware onde são executadas, me parece que evoluiram em direção ao ser humano, ao tentar humanizar a relação entre o programador e a máquina, ao

criar linguagens cada vez mais próximas a linguagem natural do ser humano, cada vez mais abstratas. Isso a meu ver criou um abismo entre a forma como o

programador vê o mundo e a solução do problema que deseja resolver (pensando em objetos, por exemplo) e as instruções computacionais necessária a solução

desde problema da forma que a maquina entende. Para fazer a ponte existe os compiladores, que cada vez mais avançam para realizar a visão abstraida que o

programador tem do mundo a sua volta e transformar essa visão em instruções de máquina realizaveis. Mas, perai, estamos escrevendo código para ser executado

por outras pessoas ou executádos por máquinas ?

Não quero dizer com isso que deveriamos voltar a quebrar pedra (programar em assembler), não seria produtivo, mas sim, que as ferramentas e as linguagens não

evoluiram no mesmo sentido da evolução do hardware. Já se perguntou, por que o hardware é cada vez mais rápido e o Windows é cada vez mais lento !?!? será

que é culpa exclusivamente dos programadores da Microsoft, ou o problema tem raizes mais profundas ? Será que parte do problema pode estar na qualidade do

assembler que é gerado pelos compiladores, em seu esforço em vão de otimizar e tentar transformar em linguagem de máquina um código fonte cada vez mais

abstrato ? Será que o problema pode esta na incompatibilidade dos paradigmas de programação que promovem a abstração da solução do problema, a agrupar a

informação em objetos, sem levar em conta o ambiente real e físico (tempo de acesso á memória, cache multinível, multicore, tempos de acesso a disco) onde

isso vai realmente ser executado ?

Tenho a impressão que apesar da evolução das ferramentas e linguagens de alto nível ainda estamos numa era pré revolução industrial. Vejo que o sofware ainda

é feito de maneira artesanal, em grande parte, por indivíduos (programadores), ou pequenos grupos de artesãos (equipes de desenvolvimento), agrupados em

aldeias (empresas). Quando vejo alguma empresa entituladas "fábrica de software" não consigo visualizar um linha de produção como a que Henri Ford idealizou

para a produção do Ford T, com analistas, arquitetos, designers, programadores, testados, enfileirados em uma linha de produção continua, parece mais uma

grande aldeia, ou até uma cidade, de artesãos.

Como a "lei de Moore" de dobrar a capacidade a cada 18 meses, esta cada vez mais difícil de ser seguida pelos fabricantes de processadores, penso que em

algum momento no futuro ira ficar cada vez mais evidente a necessidade de se repensar a forma como é feita o software, as metodologias e as ferramentas, pois

atualmente, a direção atual da evolução das ferramentas e linguagens de programação nos leva cada vez mais a demandar por mais velocidade de processamento,

para realizar as mesmas coisas.

Penso se não seria hora de voltar atras, aos primórdios da computação e seguir uma linha evolutiva diferente da atual, na área de linguagens de programação e

metodologias, que levaria mais em conta os avanços em hardware neste período e a interação humana da máquina com o programador num nível mais natural,

baseado em tecnologias atuais, chega de escrever textos/cartas (codigo fonte) para o computador, para explicar o que queremos que ele faça, melhor seria

mandar um desenho técnico, não acha. Penso em uma interação mais visual (gráfico), tátil (multitouch) ou quem sabe até vocal (comando de voz) do que textual,

como por exemplo, ferramentas que nos forneçam um ambiente gráfico dos componentes computacionais (memoria, cache, cpu, armazenamento, interface do usuário)

e nos permita interagir (programar) entre eles sem dispor de uma linguagem textual, mas mantendo a característica de baixo nível com alto nivel de

produtividade e voltada para modelar a interação deste componentes físicos, orientado aos dados, ou seja, programar num nível mais realistico e físico em

detrimentos de abstrações e outras distrações. Tecnologia pra isso já existe, temos exemplos de multitouch e comando de voz no iPad/iPhone respectivamente,

não se trata de utopia.

Alem disso penso nos benefícios que uma abordagem mais realista da programação de computadores, pode trazer no campo dos testes automatizados, da otimização

do código, da melhoria da qualidade se associada a um programa menor, por conter somente as instruções necessárias à solução do problema. Qual seria o

impacto no número de defeitos por 1000 linhas de código, díficil dizer, mas divagando um pouco, se 1000 linhas de código em linguagem de alto nível,

representam talvez 4000 instruções de máquina, com uma abordagem mais objetiva, consiga-se reduzir o número de instruções pela metade, estamos falando em uma

redução de 50% nas expectativas de falhas e bugs, essa mesma linha de raciocinio aplicada em larga escala (40 milhões de linhas de código) a redução é

significativa, sem falar em redução de tempo de processamento quando o programa estiver executando entre outras coisas.

Qual a sua opinião ?


alessandrohmachado
Participa Pouco
Participa Pouco


Voltar ao Topo Ir em baixo

Ver o tópico anterior Ver o tópico seguinte Voltar ao Topo


 
Permissão deste fórum:
Você não pode responder aos tópicos neste fórum