Rui Carlos Posted September 24, 2018 at 06:19 PM Report #611927 Posted September 24, 2018 at 06:19 PM Citação [...] Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”: Citação @tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days 🙂 You’ve probably heard this mantra: “programmer time is more expensive than computer time”. What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time. [...] Artigo longo e interessante sobre o estado do desenvolvimento de software hoje em dia. Versão completa disponível aqui: http://tonsky.me/blog/disenchantment/ 1 Report Rui Carlos Gonçalves
nunopicado Posted September 25, 2018 at 08:49 AM Report #611929 Posted September 25, 2018 at 08:49 AM Há muitos anos que eu digo que o PC de teste de um programador deveria ser um chaço arcaico. Só assim para alguns programadores perceberem que, independentemente de tudo o resto, o programa deveria ser o mais eficiente possível, e dever-se-ia apostar em fazer o melhor possível logo à primeira, para evitar depois a 'perca de tempo' a refactorar. 2 Report "A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!" > Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.
M6 Posted September 25, 2018 at 11:09 AM Report #611931 Posted September 25, 2018 at 11:09 AM 2 hours ago, nunopicado said: Há muitos anos que eu digo que o PC de teste de um programador deveria ser um chaço arcaico. Só assim para alguns programadores perceberem que, independentemente de tudo o resto, o programa deveria ser o mais eficiente possível, e dever-se-ia apostar em fazer o melhor possível logo à primeira, para evitar depois a 'perca de tempo' a refactorar. Não concordo totalmente com essa visão. EU só otimizo quando tenho de otimizar. Não vale a pena estar a otimizar uma aplicação para correr em Windows XP com 1GB de RAM se a realidade é correr em Windows 7 com 4GB de RAM. Isso é tentar resolver um problema que não existe. A última vez que tive de me "empenhar a sério" nesse tipo de guerra foi quando fiz uma app para Android há alguns anos atrás e como se pretendia que abrangesse o maior número de dispositivos Android possíveis tive de otimizar bastante a aplicação para correr em Android com pouquíssimos recursos. Já na altura achei que se calhar não fazia grande sentido porque a velocidade com que esses dispositivos são descartados é muito rápida, e na verdade uns 6 meses depois, todo o trabalho adicional foi quase inglório. Atenção que isto não quer dizer que não se tenha atenção a fazer as coisas como deve ser logo de inicio, apenas estou a dizer que só me preocupo com problemas de performance se, em ambiente de qualificação e/ou produção, tiver problemas de performance. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
nunopicado Posted September 25, 2018 at 11:16 AM Report #611932 Posted September 25, 2018 at 11:16 AM Acho que é de dividir o que é software que se sabe à partida onde vai correr e o que não se sabe, e em que condições ele vai correr. Se faço um software para correr uma vez, admito que também não me preocupo em demasia. Mas se faço um software que vai correr não sei em que PCs durante não sei quantas vezes e em quanto tempo... Convém ter cuidado com o que se faz. Lógico que não estou a dizer que temos de entrar em paranóia com isso. Mas uma gestão de memória consciente, com noção mínima do que uma acção implica a nível de performance não é de descartar. Se o fiz sempre? Não, infelizmente. Hoje olho para os programas em que não o fiz e, mesmo que os PCs sejam agora mais rápidos e portanto ainda se note menos o problema, gostaria de os ter feito correctamente de início, porque sei que cedo ou tarde, havendo tempo, vai-me dar comichão olhar para lá e vou refazer esses programas, mesmo que sem benefício para o utilizador, simplesmente por ficar melhor comigo próprio ao olhar para o código. 😁 1 Report "A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!" > Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.
Rui Carlos Posted September 26, 2018 at 07:31 PM Author Report #611936 Posted September 26, 2018 at 07:31 PM Acho que o @nunopicado toca em dois pontos fundamentais: É habitual não controlarmos devidamente o ambiente de execução (quer as características do sistema, quer os restantes processos a correr no sistema); Se por acaso existir alguma modificação das circunstâncias que torne a performance um problema, pode ser complicado optimizar a aplicação nesse ponto. Depois uma coisa é não nos preocuparmos com a performance mas sabermos escrever código minimamente eficiente de raiz. Outra coisa é literalmente não querer saber da performance e vir com a história de comprar hardware novo. E esta parece ser a norma hoje em dia. Já passamos a fase do "optimizar prematuramente é mau", para o "performance não interessa". Diria também que não estamos a falar de um potencial futuro problema, mas de um problema que efectivamente já é bem visível no software. 2 Report Rui Carlos Gonçalves
pwseo Posted September 26, 2018 at 07:58 PM Report #611937 Posted September 26, 2018 at 07:58 PM @Rui Carlos, não queres adicionar o link para que possamos ler na íntegra? (encontrar no Google é fácil, mas assim fica no post de abertura).
Rui Carlos Posted September 26, 2018 at 08:02 PM Author Report #611938 Posted September 26, 2018 at 08:02 PM 3 minutos atrás, pwseo disse: @Rui Carlos, não queres adicionar o link para que possamos ler na íntegra? (encontrar no Google é fácil, mas assim fica no post de abertura). Não sei como escapou-me essa parte 😄 Já adicionei o link no artigo original (fica também aqui: http://tonsky.me/blog/disenchantment/). 1 Report Rui Carlos Gonçalves
bsccara Posted September 30, 2018 at 08:42 AM Report #611954 Posted September 30, 2018 at 08:42 AM Acho que esta questão tem duas vertentes: - Comercial - Quem tem um projecto de desenvolvimento para executar num dado orçamento irá procurar tudo para reduzir custos directos. Como já foi escrito, o gestor paga o tempo de programação mas não o tempo de execução. Logo a eficiência do código, a menos que seja um critério definido, será sempre uma preocupação secundária. - Profissional - A larga maioria dos jovens programadores nunca teve de se preocupar com performance na execução do código, apenas com performance na criação do mesmo. De maneira geral, apenas programadores que começaram a desenvolver em máquinas limitadas tiveram de se preocupar com isso. Ferramentas como 'profilers' basicamente caíram em desuso e nem sei se serão referidas em cursos superiores da área. O enfoque que se dá hoje em dia a linguagens como Java e Python como formação primária não ajuda a criar uma mentalidade de eficiência na execução, quando são linguagens que usam 'garbage collection', tirando assim do controlo do programador a maior fonte de ineficiências de código minimamente bem criado, que é a gestão de memória. Quando ambos se combinam temos todo o tipo de 'bloatware' existente actualmente. Um 'Office Word' actual precisa de mais memória e capacidade de processamento para correr do que a disponível num super-computador Cray X-MP de 1982, ano em que surgiu o IBM PC. Apenas num mundo em que questões como a eficiência energética (sistemas que têm de funcionar à velocidade máxima, com consumo máximo, devido à carga exercida pela execução de código ineficiente) e o tratamento do lixo electrónico (sistemas deitados fora porque já não conseguem executar adequadamente as novas versões do velho 'software' usado) se tornem importantes levará a uma mudança de prioridades. Mas temo que a 'IA' (aspas usadas depreciativamente) apareça primeiro e tire completamente de mãos humanas a criação da maioria do código. 1 Report
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now