Os algoritmos (e a eficiência em geral) estão ficando menos importantes?


29

Como comprar poder de computação é muito acessível do que no passado, o conhecimento de algoritmos e a eficiência são cada vez menos importantes? É claro que você deseja evitar um loop infinito, portanto, nem tudo acontece. Mas se você tiver um hardware melhor, poderia ter um software pior?


2
"sim e não"!
vzn

4
Agora que existem aviões, e o frete transatlântico não precisa mais embarcar nos navios, a velocidade do transporte é menos importante? Os clientes da FedEx e da DHL não pensam assim.
Peter Shor

2
Se o tamanho da entrada for grande o suficiente, uma diferença de ordem de grandeza entre os algoritmos é importante, independentemente da velocidade da máquina. Mas, ocasionalmente, sou enganado em fazer alterações para "otimizar" uma diferença constante de fator, apenas para perceber que o uso de expressões incorporadas ao açúcar sintático da linguagem de programação <cough> Python </cough> é significativamente mais rápido que a minha "otimização".
kojiro

veja também moores law
vzn 13/10/2013

um estudo de caso interessante aqui é, por exemplo, o Windows, que de alguma maneira é executado de maneira menos eficiente, mesmo em hardware altamente otimizado do que costumava ... assim como a lei de Moore está melhorando o hardware, parece haver uma lei inflacionária correspondente no software em que o software moderno está cada vez mais ativo, com novas camadas adicionadas e multiplicadas ... um pouco análogas à maneira como um gás preenche todo o volume disponível ... ou no qual um orçamento, não importa o tamanho ou o aumento, sempre é usado ou um pouco excedente ... veja também corrida evolutiva
vzn

Respostas:


31

Eu realmente gosto do exemplo do livro Introdução aos algoritmos , que ilustra o significado da eficiência do algoritmo:

Vamos comparar dois algoritmos de classificação: classificação por inserção e classificação por mesclagem . Sua complexidade é e respectivamente. Normalmente, a classificação de mesclagem tem um fator constante maior, então vamos supor . O ( n log n ) = c 2 n lg n c 1 < c 2O(n2)=c1n2O(nlogn)=c2nlgnc1<c2

Para responder sua pergunta, avaliamos o tempo de execução de um computador mais rápido (A) executando o algoritmo de classificação por inserção contra o computador mais lento (B) executando o algoritmo de classificação por mesclagem.

Nós presumimos:

  • o tamanho do problema de entrada é de 10 milhões de números: ;n=107
  • o computador A executa instruções por segundo (~ 10GHz);1010
  • o computador B executa apenas instruções por segundo (~ 10MHz);107
  • os fatores constantes são (o que é ligeiramente superestimado) (na realidade, é menor).c 2 = 50c1=2c2=50

Então, com essas suposições, é preciso

2(107)2 instructions1010 instructions/second=2104 seconds
por o computador A para classificar números e107

50107lg107 instructions107 instructions/second1163 seconds

para o computador B.

Assim, o computador, que é 1000 vezes mais lento, pode resolver o problema 17 vezes mais rápido. Na realidade, a vantagem da classificação por mesclagem será ainda mais significativa e aumentará com o tamanho do problema. Espero que este exemplo ajude a responder sua pergunta.

No entanto, isso não é tudo sobre complexidade do algoritmo. Hoje, é quase impossível obter uma aceleração significativa apenas com o uso da máquina com maior frequência de CPU. As pessoas precisam projetar algoritmos para sistemas com vários núcleos que escalam bem. Essa também é uma tarefa complicada, porque, com o aumento de núcleos, uma sobrecarga (para gerenciar acessos à memória, por exemplo) também aumenta. Portanto, é quase impossível obter uma aceleração linear.

Então, para resumir, o design de algoritmos eficientes hoje em dia é igualmente importante como antes, porque nem o aumento da frequência nem os núcleos extras fornecerão a aceleração em comparação com a trazida pelo algoritmo eficiente.


4
Vale ressaltar que a impossibilidade de aceleração linear deriva da lei de Amdhal .
Bartosz Przybylski

A lei de Amdhal nem sempre é aplicável. Existem muitos problemas na ciência computacional em que a fração do trabalho não-paralelizável cai para zero à medida que o tamanho do problema aumenta. Digamos que computar requer trabalho e você precisa calcular para diferentes . Em série, o custo do tempo é , enquanto que paralelamente a processadores, o trabalho é . f(x)n2i=1nf(xi)nxisO(nn2+n)=O(n3)nO(n2+n)=O(n2)
Nick Alger

“Portanto, o computador, que é 1000 vezes mais lento, pode resolver o problema 17 vezes mais rapidamente.” Essa é uma afirmação falsa, pois você combina a velocidade do hardware e algoritmos diferentes ao mesmo tempo. Em vez disso, compare o computador A com o computador B para cada tipo de classificação separadamente. (Por que não posso usar merge sort no computador A, ou inserções tipo no computador B?)
AquaAlex

3
@AquaAlex, o objetivo do exemplo é mostrar que o computador lento pode superar o rápido apenas por meio do algoritmo selecionado. Poderíamos comparar o tempo de execução de cada tipo de classificação separadamente ou executar a classificação de mesclagem em A e a inserção de classificações em B. Mas mostrar que um computador mais rápido normalmente tem um desempenho melhor do que um lento simplesmente não faz sentido.
Pavel Zaichenkov

OK, então a ideia era mostrar que um algoritmo mais eficiente ainda carrega peso, mesmo durante o dia, em CPUs mais rápidas e em memória maior.
AquaAlex

36

Pelo contrário. Ao mesmo tempo em que o hardware está ficando mais barato, vários outros desenvolvimentos ocorrem.

Primeiro, a quantidade de dados a serem processados ​​está crescendo exponencialmente. Isso levou ao estudo de algoritmos de tempo quaseilineares e à área de big data . Pense, por exemplo, nos mecanismos de pesquisa - eles precisam lidar com grandes volumes de consultas, processar grandes quantidades de dados e fazê-lo rapidamente. Os algoritmos são mais importantes do que nunca.

Segundo, a área de aprendizado de máquina está crescendo forte e cheia de algoritmos (embora de um tipo diferente do que você aprende em seu BA). A área está prosperando e, de tempos em tempos, um algoritmo verdadeiramente novo é inventado e melhora significativamente o desempenho.

Terceiro, algoritmos distribuídos tornaram-se mais importantes, pois estamos atingindo um obstáculo no aumento da velocidade de processamento da CPU . Atualmente, o poder da computação está sendo aumentado pela paralelização , e isso envolve algoritmos dedicados.

Quarto, para contrabalançar o poder crescente das CPUs, os paradigmas de programação modernos empregam métodos de máquina virtual para combater brechas na segurança. Isso atrasa esses programas por um fator apreciável. Além do enigma, seu sistema operacional está investindo mais tempo de CPU em sinos e assobios, deixando menos tempo de CPU para seus programas reais, o que pode incluir algoritmos intensivos em CPU, como compactação e descompressão de vídeo. Portanto, embora o hardware seja mais rápido, ele não é usado com a mesma eficiência.

Resumindo, algoritmos eficientes são necessários para lidar com grandes quantidades de dados; novos tipos de algoritmos estão surgindo na área de inteligência artificial ; algoritmos distribuídos estão entrando em foco; e a energia da CPU é aproveitada com menos eficiência por vários motivos (mas principalmente porque os computadores estão ficando mais poderosos). Algoritmos ainda não estão mortos.


"algoritmos ainda não estão mortos" ... muito pelo contrário, estamos propensos a viver através de uma "idade de ouro de algoritmos" ....
vzn

12

O conhecimento de algoritmos é muito mais do que como escrever algoritmos rápidos.

Também fornece métodos de solução de problemas (por exemplo, dividir e conquistar, programação dinâmica, ganancioso, redução, programação linear etc.) que você pode aplicar ao abordar um problema novo e desafiador. Ter uma abordagem adequada geralmente leva a códigos mais simples e muito mais rápidos de escrever. Portanto, tenho que discordar da resposta de Kevin, pois os códigos que não são cuidadosamente reunidos geralmente são não apenas lentos, mas também complicados. Eu gosto desta citação de David Parnas:

Costumo ouvir desenvolvedores descritos como "alguém que sabe como construir um sistema grande rapidamente". Não há truque na construção de grandes sistemas rapidamente; quanto mais rápido você as constrói, maiores elas ficam!

(Obviamente, também precisamos combinar algoritmos com métodos de design de software para escrever bons códigos.)

O conhecimento de algoritmos também nos diz como organizar seus dados para que você possa processá-los com mais facilidade e eficiência através do uso de estruturas de dados.

Além disso, fornece uma maneira de estimar a eficiência de sua abordagem e entender as vantagens e desvantagens entre várias abordagens diferentes em termos de complexidade de tempo, complexidade de espaço e complexidade dos códigos. Conhecer essas compensações é a chave para tomar a decisão certa dentro de suas restrições de recursos.

Sobre a importância da eficiência do software, cito a Lei de Wirth:

O software está ficando mais lento mais rapidamente do que o hardware se torna mais rápido.

Larry Page recentemente reafirmou que o software fica duas vezes mais lento a cada 18 meses e, portanto, ultrapassa a lei de Moore.


7

Sim , eles são 'relativamente' menos importantes em uma ampla indústria. O editor de texto pode ser 'rápido o suficiente' e pode não precisar de muitas melhorias. Grande parte do esforço de TI é garantir que o componente A escrito em Java funcione com o componente B escrito com C se comunique corretamente por meio da fila de mensagens gravadas em Cobol (ou algo assim), ou para colocar o produto no mercado etc.

Além disso, a arquitetura ficou complicada. Quando você tinha processadores simples e antigos, onde tinha 1 instrução por ciclo e escreveu na montagem, as otimizações foram 'fáceis' (você só precisava contar o número de instruções). Atualmente, você não possui um processador simples, mas um processador totalmente pipeline, superescalar e fora de ordem, com renomeação de registro e cache de vários níveis. E você não escreve em assembly, mas em C / Java / etc. onde o código é compilado / JIT (normalmente, para melhor codificar, você ou eu escreveríamos em assembly) ou em Python / Ruby / ... onde o código é interpretado e você é separado por vários níveis de abstração da máquina. As microoptimalizações são difíceis e a maioria dos programadores obteria efeito oposto.

Não , eles são sempre tão importantes em pesquisa e em termos "absolutos" . Há áreas em que a velocidade é importante, pois elas operam com grande quantidade de dados. Nesta escala, as complexidades são importantes, como mostra o exemplo de Pavel.

No entanto, existem outros casos - descer dos algoritmos ainda é uma opção escolhida quando a velocidade é importante (HPC, dispositivos incorporados etc.). Você encontrará em muitas universidades grupos especializados em compiladores e / ou otimização de software. Por exemplo, uma troca simples de pedidos de loop pode obter uma aceleração de mil vezes apenas porque utiliza cache de maneira eficiente - embora possa ser um exemplo limítrofe, a diferença de CPU e memória cresce 1000 vezes nos últimos 30 anos. A arquitetura de computadores também faz parte do CS. Portanto, muitas das melhorias na velocidade da computação são de fato parte do campo geral do CS.

No lado industrial - quando você tem um cluster de HPC, a velocidade é importante porque um único programa pode ser executado por dias, meses ou anos. Não apenas você precisa pagar a conta de luz, mas também a espera pode custar dinheiro. Você pode jogar o dobro do hardware, mas US $ 700 milhões dificilmente pode ser considerado uma mudança de bolso para todas as empresas, exceto as maiores - nesses casos, os programadores são a opção mais barata e, se reescrever o programa em um novo idioma significar apenas uma aceleração 'pequena' - eles podem considere isso.

Velocidade também pode significar melhor UX. Muitas revisões de sistemas operacionais de telefones celulares afirmam qual é 'mais rápido' e, embora possa ser feito por 'truques', é certamente uma área de estudo. Além disso, você deseja acessar seus dados mais rapidamente e rapidamente fazer o que precisa. Às vezes, significa que você pode fazer mais - em jogos você tem 0,017s para fazer tudo e quanto mais rápido você é, mais doces você pode colocar.


2

É uma discussão interessante. E temos algumas coisas para analisar aqui.

  1. A ciência da computação teórica - Esta é uma ciência em evolução, que significa que, com o passar do tempo, encontraremos novas e melhores maneiras de resolver problemas, o que significa algoritmos aprimorados para pesquisa e classificação, por exemplo.

  2. Comunidades maiores / bibliotecas maiores - Como muito trabalho foi realizado por outras pessoas, podemos apenas desenvolver seu trabalho e usar os algoritmos que eles já criaram e até mesmo codificaram. E essas bibliotecas serão atualizadas com o tempo, permitindo o acesso automático a programas / algoritmos mais eficientes.

  3. Desenvolvimento - Agora, aqui temos um problema, eu acho. Muitos programadores não são cientistas da computação, então escrevem código para resolver problemas de negócios, não problemas técnicos / teóricos e ficariam tão felizes usando um tipo de bolha quanto um tipo rápido, por exemplo. E aqui a velocidade do hardware está permitindo que maus programadores se safem do uso de algoritmos e práticas de codificação ruins. Memória, velocidade da CPU, espaço de armazenamento, essas coisas não são mais grandes preocupações e, a cada poucos meses, as coisas estão ficando maiores, mais rápidas e mais baratas. Quero dizer, olhe para os novos celulares. Eles agora são mais avançados que os computadores / servidores de mainframe dos anos 70/80. Mais armazenamento, mais poder de processamento, memória mais rápida.

  4. Interface do usuário e dados - Interface do usuário / experiência do usuário e dados agora são considerados mais importantes do que códigos super eficientes na maioria das áreas de desenvolvimento. Portanto, a velocidade só se torna problemática quando um usuário precisa esperar muito. Se dermos ao usuário uma boa aparência e ele receber uma boa resposta do aplicativo, ele ficará feliz. E se as empresas souberem que todos os dados estão armazenados de maneira segura e puderem recuperá-los e manipulá-los a qualquer momento, não se importam com a quantidade de espaço necessária.

Então, eu diria que não é que programadores eficientes não sejam mais importantes ou necessários, apenas poucas empresas / usuários recompensam as pessoas por serem programadores super eficientes e, por causa do hardware ser melhor, estamos nos saindo menos eficiente. Mas pelo menos ainda existem pessoas por aí focando na eficiência e, devido ao espírito da comunidade, todos ganham tempo com isso.


1

Alguns outros ângulos dessa questão interessante e profunda que enfatiza os aspectos interdisciplinares e transversais do fenômeno. Dai cita a lei de Wirth em sua resposta:

O software está ficando mais lento mais rapidamente do que o hardware se torna mais rápido.

Existem paralelos interessantes dessa idéia com os fenômenos observados na economia. Observe que a economia tem muitas conexões profundas com a ciência da computação, por exemplo, por exemplo, agendamento onde recursos escassos (como threads etc.) são alocados a pedido, por algoritmos de "balanceamento de carga". Outro exemplo é o que é chamado de fila produtor-consumidor. Além disso, leilões.

Também por exemplo, Lista de leis de mesmo nome, Wikipedia :

Lei de Parkinson - "O trabalho se expande para preencher o tempo disponível para sua conclusão". Cunhado por C. Northcote Parkinson (1909-1993), que também cunhou seu corolário, "As despesas aumentam para atender à renda". Nos computadores: os programas se expandem para preencher toda a memória disponível.

Também existe uma forte semelhança com o paradoxo de Jevon, que foi observado no aumento do uso de energia depois que os motores a vapor Watt mais eficientes começaram a substituir o design Newcomen, mas o uso ou proliferação dos motores aumentou:

Em economia, o paradoxo de Jevons (/ ˈdʒɛvənz /; às vezes efeito de Jevons) é a proposição de que o progresso tecnológico que aumenta a eficiência com a qual um recurso é usado tende a aumentar (em vez de diminuir) a taxa de consumo desse recurso.

A analogia é que o hardware é o recurso e o software é como o consumo do recurso (também conhecido como oferta versus demanda). Portanto, software e hardware (e os avanços em cada um) existem de certa forma em um ciclo de feedback simbiótico fortemente acoplado entre si, em certo sentido, co-evoluindo . Existem muitos fatores complexos e inter-relacionados que influenciam essa interação, por exemplo:


Por que o voto negativo? Acho a menção à lei de Parkinson e ao paradoxo de Jevons muito reveladora.
Yuval Filmus

@YuvalFilmus Meu palpite: problemas com a gramática. Não achei incomodando minha capacidade de ler muito a resposta dessa vez, mas tentei melhorá-la.
Juho

1
Não é "problemas com a gramática", é um estilo diferente. É como dizer que um falante nativo comete "erros" ao falar em seu próprio idioma, enquanto na verdade o idioma está mudando ou há uma variação regional. Nesse caso, é o estilo idiomático do vzn.
Yuval Filmus

-3

Não, principalmente considerando a complexidade do espaço! A capacidade de armazenamento de um computador normal está crescendo exponencialmente.


O inverso não seria verdadeiro - se você tiver armazenamento "infinito", não precisará se preocupar com a complexidade do espaço. O 'problema' não é que o armazenamento cresça, mas que os dados para operar cresçam em sincronia, preenchendo as acelerações oferecidas pelo aumento da potência e da memória computacional - o que é bom, queremos modelar o cosmos de maneira mais realista, dobrar mais proteínas etc. (PS. Eu não votei no ar) #
Maciej Piechotka

4
É verdade que muitos desenvolvedores de aplicativos móveis parecem assumir recursos infinitos, mas infelizmente meu dispositivo é muito finito.
Raphael
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.