Discordo completamente, o for de 1 bilhão de interações é muito útil, principalmente para fazer jogos, todo jogo é basicamente um for loop infinito. Pode não ser útil para a sua área, mas está bem longe de ser inútil.
Dai eh foda, c tá abstraindo demais paizão. Gargalo em nenhum jogo tá na velocidade de execução de looping (a menos que tenha algo codado dentro do looping causando a lentidao, e isso q eh o que deve ser analisado)
Você não itera bilhões de vezes em x tempo, você limita as iterações de acordo com a taxa de frames que seu game suporta. Então com 60 fps, advinha qual média de iterações por segundo vc vai ter no seu Game Loop dependendo do seu algoritmo? DIca: Perto de 60, não de 1 bi. Portanto, escrevestes merda.
@@rodrigoresbi o jogo inteiro roda dentro de um loop infinito amigo, tenho jogos lançados na Steam e vivo disso. Faz sentido sim medir velocidade do loop, mesmo que não vá executar milhões de vezes.
Um bilhão de iterações é bem factível na verdade. Mas o teste é ruim porque só testa a habilidade do compilador em transformar dois FOR em linguagem de máquina.
Cara, no mundo das WEB API's, você só deve começar a se preocupar com qual linguagem usar caso sua API for lidar com no mínimo 2k de requisições simultâneas. Tem um canal Anton Putra, que esse cara faz uns benchmarks um pouco mais realistas. Para linguagens, na maioria, ele testa mais webserver's e serialização/desserialização, com massivos workloads. Tem comparações entre banco de dados tbm, load balancers, entre outros. Gosto dele porque ele traz muito próximo ao mundo real os testes.
Uma coisa que me incomoda nesses testes é que eles nem parecem saber o que estão medindo. Eu já acho toda essa questão de dizer que linguagem x é mais rápida que linguagem y balela. O vídeo "Porque que não existe LINGUAGEM lenta" do Augusto Galego sintetiza bem meu pensamento. Linguagens de programação são linguagens formais usadas para descrever a solução de problemas computáveis para pessoas ou máquinas. Uma linguagem de programação não é uma computação, ela expressa uma computação. E essa diferença nem tão sútil leva a certas conclusões equivocadas, tipo "linguagem x é compilada e linguagem y é interpretada". Uma linguagem de programação, assim como qualquer outra linguagem, é um meio de comunicação, e essa é a chave, comunicação. Elas possuem regras sintáticas e semânticas que compõe um meio para descrever um algoritmo. Compiladores e interpretadores são apenas ferramentas que analisam o algoritmo expresso através daquela linguagem e produz um código em outra linguagem (geralmente a de máquina), as vezes até produzindo um outro programa, mas sendo consistente com o programa original no quesito entrada e saída. Não existe linguagem compilada ou interpretada, uma linguagem pode ser interpretada, compilada ou nenhuma das duas, ela pode até mesmo ser projetada para ser um meio de comunicação entre pessoas. A gente faz isso o tempo inteiro, quando estudamos algoritmos, vemos trechos de código em linguagens de programação, mas esses programas não necessariamente foram compilados ou interpretados, pois o ponto não é se comunicar com a máquina, mas com pessoas, a comunicação de uma computação de uma pessoa para outra. "C é compilado", existem interpretadores para C. "Python é interpretado", existem compiladores para Python. "Java é compilado e interpretado, pq você primeiro compila para bytecodes e usa um intepretador", existem compiladores que compilam bytecode para a arquitetura nativa, como GraalVM, nesse caso Java seria compilado e compilado??? Obviamente, certas decisões de design tornam mais fácil uma implementação eficiente do que outras. Por exemplo, tipagem estática geralmente é mais eficiente do que a dinâmica porquê o compilador/interpretador não precisa ficar fazendo verificações em tempo de execução. Mas no fim do dia, isso ainda é detalhe de implementação. Eu fiz toda essa argumentação para chegar a esse ponto: esses benchmarks não estão medindo desempenho de linguagens, isso sequer faz sentido, mas sim de compiladores e interpretadores. Um bom benchmarks obviamente vai dizer qual compilador/interpretador foi usado para fazer o teste, mas a questão é que isso geralmente é posto como um detalhe secundário, quando na verdade é o ponto central. E esse equívoco de achar que se está medindo linguagens ao invés dessas ferramentas, faz com que as pessoas não façam as perguntas certas. Como no caso de C, qual compilador foi usado? GCC, Clang ou outro? Flags de otimização foram usadas? Se foram, qual o nível da otimização usado? O código de saída foi analisado para ver se é coerente com o que o benchmark quer medir? Porquê se eu escrevo uma função, que apenas itera 1 milhão de vezes em C, com uma flag de otimização mais agressiva o compilador produz um código que apenas retorna da função assim que ela chamada, afinal, ela não está fazendo nenhuma computação útil de qualquer maneira. Se eu usar um compilador da linguagem C de 20 anos atrás e compilar para o padrão C99 ele certamente será menos eficiente do que o MESMO código compilado por um compilador moderno. E qual foi a mudança da linguagem? Nenhuma, o código é o mesmo, o que mudou foi o compilador, porquê é isso que importa. Desculpe o textão, mas quis dar a minha opinião aqui que nem sei se está certa kkkkk. Mas toda vez que vejo esses testes de linguagens me parecem que eles tentam responder uma pergunta quando na verdade estão respondendo outra.
Eu cai nessa semana passada, eu até escrevi meu próprio teste em python vs C comparando a velocidade para descobrir se 10000 é um número primo kkkk. Obrigado pelo conhecimento waine
Não sei se você conhece Waine, mas eu acompanho um canal de um cara chamado Anton Putra que ele faz benchmarks de webframeworks de várias linguagens. Me parece que a abordagem dele é mais honesta, visto que ele explica o problema (geralmente um cenário de aplicação mais simples) demonstra a solução em cada linguagem e depois demonstra os resultados do teste em tempo real explicando o que cada gráfico aponta. Ainda por cima ele sempre pega o feedback dos comentários e incentiva o público a fazer pull request para outras possíveis soluções mais performáticas. Ali dá pra ter uma noção um pouco mais real dos limites que alguns frameworks e linguagens tem devido a forma como são executados.
Já vi alguns vídeos do canal dele! Os que já vi me pareciam benchmarks bons, que consideravam essas questões que comentei no vídeo. Benchmark é muito importante saber contexto e fazer uma boa interpretação dos resultados. Uma das melhores referências pra mim é o Chips N Cheese, blog sobre microarquitetura de CPUs e GPUs, que sempre fazem benchmarks e testes pra comparar desempenho, e são sempre posts gigantes com as mais diversas análises, tomando um cuidado muito grande pra tirar qualquer conclusão.
As pessoas nem tem noção de como é muito mais fácil compilar Python (jit) do que C... e que num código real, Python está rodando C a maior parte do tempo... Python compilado é muito rápido, tão rápido qto C compilado sem otimização. O ponto é que é muito mais que rápido o suficiente para 99% dos casos. E cada nova versão de Python é muito mais rápida... e o hw fica cada vez mais rápido tbm.
esse tipo de benchmark realmente é inútil, mas as lições que conseguimos tirar disso, como vemos no vídeo do Pedro Pessoa, é a graça do negócio na minha opinião, linguagens provavelmente usando a mesma logica e algoritmo comparados, e daí vemos como as otimizações que o compilador fazem é um puta diferencial, apesar de ser um problema para os 0,2% dos casos
Uso python e isso ai é bem irrelevante, não faço nada que exija tanta performance, a não ser que você trabalhe no Facebook ou alguma empresa que cada segundo reduzido economize uma boa grana, tirando esses casos isso ai não importa
Ruby e Python puros são carroças mesmo, se não usar os JIT que foram adicionadks recentemente. (Mesmo esses não ajudam tanto) Mas a maioria do código dessas linguagem só chama funções escritas em C, então meio que não importa.
"é pra ficar mais performático", microsserviço é muito mais pra resolver problema organizacional do que técnico. Aí surgem as pérolas do app com mais microsserviços que usuários kkkkkkk
@waine_jr na verdade não, já na década de 90, Java era focada em grandes times (programming in the large), a ideia era usar OOP em peso para criar módulo independentes, de forma que um software poderia ser desenvolvido por vários times em paralelo, com menos comunicação. A única vantagem que micro serviços tem é que você pode fazer cada serviço em uma linguagem diferente, porque os dados são armazenados em JSON ao invés de objetos da linguagem.
Sr. Waine. Eu vi o video do cidadão. Sou dev a mais de 25 anos e com todo respeito a comunidade... muito inútil esse benchmark. Concordo com você. Cada linguagem possui suas características próprias e suas otimizações. Benchmarks por benchmark (de Fibonacci por exemplo) não pode ser aplicado em tudo, pq o que é bom para uma linguagem é ruim para outra. O que me assusta é que tem muitos devs hoje em dia, que exaltam uma promisse em JS normalmente, mas não sabem manipular uma struct em C. Não estou tirando o mérito do promisse, mas quero chegar em: precisamos saber o que roda debaixo do capô para fazer Benchmarks de cada linguagem.
eu fiquei com pé atrás do suposto teste porque não tinha C++ . " ... Ah mas se não esta é porque não ficou entre os melhores resultados ... " seria outra grande mentira contada.
Os testes do techempower também são ruins. Se você ver os códigos enviados, vai ver que estão otimizados não para o caso comum ou idiomático, mas para vencer os benchmarks.
Pois é, isso é o foda de gamificação e testes padrões. No fim não achei um outro exemplo representativo de web, por isso acabei usando techempower. Benchmark tem que ter muito cuidado ao se fazer e analisar, com software e framework a maioria dos benchmarks que vejo dá pra jogar no lixo
Discordo completamente, o for de 1 bilhão de interações é muito útil, principalmente para fazer jogos, todo jogo é basicamente um for loop infinito.
Pode não ser útil para a sua área, mas está bem longe de ser inútil.
Kkkkkkkkkkkkkkklkkklllllll
Dai eh foda, c tá abstraindo demais paizão. Gargalo em nenhum jogo tá na velocidade de execução de looping (a menos que tenha algo codado dentro do looping causando a lentidao, e isso q eh o que deve ser analisado)
Você não itera bilhões de vezes em x tempo, você limita as iterações de acordo com a taxa de frames que seu game suporta.
Então com 60 fps, advinha qual média de iterações por segundo vc vai ter no seu Game Loop dependendo do seu algoritmo? DIca: Perto de 60, não de 1 bi.
Portanto, escrevestes merda.
@lisbyte_ não gosto de travar meus jogos a 60FPS, tenho monitor 144hz e gosto de jogar sem input lag, logo faz sentido medir velocidade de um loop.
@@rodrigoresbi o jogo inteiro roda dentro de um loop infinito amigo, tenho jogos lançados na Steam e vivo disso. Faz sentido sim medir velocidade do loop, mesmo que não vá executar milhões de vezes.
Corre que o Sr. Waine tá pistola
"me segura"
😂😂😂
primeiro vídeo que vejo no canal, já dei subscribe. excelente conteúdo técnico, parabéns
Que massa que curtiu! Aqui o que mais tem é conteúdo técnico de baixo nível
Pra mim o teste serviu pra eu saber o nome de três linguagens que eu nunca tinha ouvido falar... kkkk
Maior utilidade dele kkkkkkkkkkkk
Kkkkkkkkkkkkkkkk
Sr desempenho, hoje o senhor baixou o nível ficando pistola, kkkkk
Um bilhão de iterações é bem factível na verdade. Mas o teste é ruim porque só testa a habilidade do compilador em transformar dois FOR em linguagem de máquina.
É factível na área de dados, mas daí o gargalo é I/O. Tô curioso em saber um caso de uso de processamento com 1b de iterações
A forma como ele tá genuinamente pistola é muito fofo kkkkkkkkkkkkkk
exatamente, benchmarks medem qual programa melhor executa aquele benchmark
é quase inútil mesmo
meu celular tá em inglês, eu abri o vídeo e o Wayne simplesmente começou a ser dublado por uma mulher estadunidense 😅
kkkkkkkkkkkkkkkk pô grava e manda no discord, quero ver
Cara, no mundo das WEB API's, você só deve começar a se preocupar com qual linguagem usar caso sua API for lidar com no mínimo 2k de requisições simultâneas. Tem um canal
Anton Putra, que esse cara faz uns benchmarks um pouco mais realistas. Para linguagens, na maioria, ele testa mais webserver's e serialização/desserialização, com massivos workloads. Tem comparações entre banco de dados tbm, load balancers, entre outros. Gosto dele porque ele traz muito próximo ao mundo real os testes.
Uma coisa que me incomoda nesses testes é que eles nem parecem saber o que estão medindo. Eu já acho toda essa questão de dizer que linguagem x é mais rápida que linguagem y balela. O vídeo "Porque que não existe LINGUAGEM lenta" do Augusto Galego sintetiza bem meu pensamento.
Linguagens de programação são linguagens formais usadas para descrever a solução de problemas computáveis para pessoas ou máquinas. Uma linguagem de programação não é uma computação, ela expressa uma computação. E essa diferença nem tão sútil leva a certas conclusões equivocadas, tipo "linguagem x é compilada e linguagem y é interpretada". Uma linguagem de programação, assim como qualquer outra linguagem, é um meio de comunicação, e essa é a chave, comunicação. Elas possuem regras sintáticas e semânticas que compõe um meio para descrever um algoritmo. Compiladores e interpretadores são apenas ferramentas que analisam o algoritmo expresso através daquela linguagem e produz um código em outra linguagem (geralmente a de máquina), as vezes até produzindo um outro programa, mas sendo consistente com o programa original no quesito entrada e saída.
Não existe linguagem compilada ou interpretada, uma linguagem pode ser interpretada, compilada ou nenhuma das duas, ela pode até mesmo ser projetada para ser um meio de comunicação entre pessoas. A gente faz isso o tempo inteiro, quando estudamos algoritmos, vemos trechos de código em linguagens de programação, mas esses programas não necessariamente foram compilados ou interpretados, pois o ponto não é se comunicar com a máquina, mas com pessoas, a comunicação de uma computação de uma pessoa para outra. "C é compilado", existem interpretadores para C. "Python é interpretado", existem compiladores para Python. "Java é compilado e interpretado, pq você primeiro compila para bytecodes e usa um intepretador", existem compiladores que compilam bytecode para a arquitetura nativa, como GraalVM, nesse caso Java seria compilado e compilado??? Obviamente, certas decisões de design tornam mais fácil uma implementação eficiente do que outras. Por exemplo, tipagem estática geralmente é mais eficiente do que a dinâmica porquê o compilador/interpretador não precisa ficar fazendo verificações em tempo de execução. Mas no fim do dia, isso ainda é detalhe de implementação.
Eu fiz toda essa argumentação para chegar a esse ponto: esses benchmarks não estão medindo desempenho de linguagens, isso sequer faz sentido, mas sim de compiladores e interpretadores. Um bom benchmarks obviamente vai dizer qual compilador/interpretador foi usado para fazer o teste, mas a questão é que isso geralmente é posto como um detalhe secundário, quando na verdade é o ponto central. E esse equívoco de achar que se está medindo linguagens ao invés dessas ferramentas, faz com que as pessoas não façam as perguntas certas. Como no caso de C, qual compilador foi usado? GCC, Clang ou outro? Flags de otimização foram usadas? Se foram, qual o nível da otimização usado? O código de saída foi analisado para ver se é coerente com o que o benchmark quer medir? Porquê se eu escrevo uma função, que apenas itera 1 milhão de vezes em C, com uma flag de otimização mais agressiva o compilador produz um código que apenas retorna da função assim que ela chamada, afinal, ela não está fazendo nenhuma computação útil de qualquer maneira. Se eu usar um compilador da linguagem C de 20 anos atrás e compilar para o padrão C99 ele certamente será menos eficiente do que o MESMO código compilado por um compilador moderno. E qual foi a mudança da linguagem? Nenhuma, o código é o mesmo, o que mudou foi o compilador, porquê é isso que importa.
Desculpe o textão, mas quis dar a minha opinião aqui que nem sei se está certa kkkkk. Mas toda vez que vejo esses testes de linguagens me parecem que eles tentam responder uma pergunta quando na verdade estão respondendo outra.
perfeito, sem tirar nem por 👏👏👏
Eu cai nessa semana passada, eu até escrevi meu próprio teste em python vs C comparando a velocidade para descobrir se 10000 é um número primo kkkk. Obrigado pelo conhecimento waine
Não sei se você conhece Waine, mas eu acompanho um canal de um cara chamado Anton Putra que ele faz benchmarks de webframeworks de várias linguagens. Me parece que a abordagem dele é mais honesta, visto que ele explica o problema (geralmente um cenário de aplicação mais simples) demonstra a solução em cada linguagem e depois demonstra os resultados do teste em tempo real explicando o que cada gráfico aponta. Ainda por cima ele sempre pega o feedback dos comentários e incentiva o público a fazer pull request para outras possíveis soluções mais performáticas. Ali dá pra ter uma noção um pouco mais real dos limites que alguns frameworks e linguagens tem devido a forma como são executados.
Já vi alguns vídeos do canal dele! Os que já vi me pareciam benchmarks bons, que consideravam essas questões que comentei no vídeo. Benchmark é muito importante saber contexto e fazer uma boa interpretação dos resultados. Uma das melhores referências pra mim é o Chips N Cheese, blog sobre microarquitetura de CPUs e GPUs, que sempre fazem benchmarks e testes pra comparar desempenho, e são sempre posts gigantes com as mais diversas análises, tomando um cuidado muito grande pra tirar qualquer conclusão.
As pessoas nem tem noção de como é muito mais fácil compilar Python (jit) do que C... e que num código real, Python está rodando C a maior parte do tempo... Python compilado é muito rápido, tão rápido qto C compilado sem otimização. O ponto é que é muito mais que rápido o suficiente para 99% dos casos.
E cada nova versão de Python é muito mais rápida... e o hw fica cada vez mais rápido tbm.
esse tipo de benchmark realmente é inútil, mas as lições que conseguimos tirar disso, como vemos no vídeo do Pedro Pessoa, é a graça do negócio na minha opinião, linguagens provavelmente usando a mesma logica e algoritmo comparados, e daí vemos como as otimizações que o compilador fazem é um puta diferencial, apesar de ser um problema para os 0,2% dos casos
Esse tipo de teste é útil pra poder falar o quanto ele é inútil.
Uso python e isso ai é bem irrelevante, não faço nada que exija tanta performance, a não ser que você trabalhe no Facebook ou alguma empresa que cada segundo reduzido economize uma boa grana, tirando esses casos isso ai não importa
Meu rubyzinho é uma carroça segundo o teste inútil 😞
Kkkkkkkkkkk Python então é o responsável pelo aquecimento global sozinho
Ruby e Python puros são carroças mesmo, se não usar os JIT que foram adicionadks recentemente. (Mesmo esses não ajudam tanto)
Mas a maioria do código dessas linguagem só chama funções escritas em C, então meio que não importa.
Uma coisa que eu entendi, é que algo bem aplicado em uma "linguagem lenta" é n vezes mais rápido que qualquer lixo
Nem isso dá pra concluir de tão inútil que é o teste, além de não servir pra nada, quem escreveu o código é o ChatGPT.
Esse teste só funciona pra vendedor de curso de framework, " olha só como a linguagem que usamos se destaca no mercado! ". 😂😂😂😂
"ESSE TESTE É INUTIL" disse o programador de R kkkkkkkkkkkkkkkk
Ai a galera mete micro serviço pra tudo e toma dano de IO e rede pra quase tudo, em vario sservidores diferentes AHHAHAHHAHA
"é pra ficar mais performático", microsserviço é muito mais pra resolver problema organizacional do que técnico. Aí surgem as pérolas do app com mais microsserviços que usuários kkkkkkk
@waine_jr na verdade não, já na década de 90, Java era focada em grandes times (programming in the large), a ideia era usar OOP em peso para criar módulo independentes, de forma que um software poderia ser desenvolvido por vários times em paralelo, com menos comunicação.
A única vantagem que micro serviços tem é que você pode fazer cada serviço em uma linguagem diferente, porque os dados são armazenados em JSON ao invés de objetos da linguagem.
Sr. Waine. Eu vi o video do cidadão. Sou dev a mais de 25 anos e com todo respeito a comunidade... muito inútil esse benchmark. Concordo com você. Cada linguagem possui suas características próprias e suas otimizações. Benchmarks por benchmark (de Fibonacci por exemplo) não pode ser aplicado em tudo, pq o que é bom para uma linguagem é ruim para outra. O que me assusta é que tem muitos devs hoje em dia, que exaltam uma promisse em JS normalmente, mas não sabem manipular uma struct em C. Não estou tirando o mérito do promisse, mas quero chegar em: precisamos saber o que roda debaixo do capô para fazer Benchmarks de cada linguagem.
Inútil nada, fez a glr inclusive yt falarem sobre e estudar para ensinar a outros, gênio demais, agora povo sabe melhor como medir desempenho. kkkkk
kkkkkkkkkkkkkkkk tem um bom ponto
Boa. 😂
eu fiquei com pé atrás do suposto teste porque não tinha C++ . " ... Ah mas se não esta é porque não ficou entre os melhores resultados ... " seria outra grande mentira contada.
Eu pensei que era pq não tinha muita diferença comparado com C, já que usam os mesmos compiladores.
Como diria o agner fog, o IPC mais alto de qualquer CPU é o mesmo que o das instruções NOP kkkk.
O Waine putasso!? 😱
Oba , nao vi objective C? 0:38, mas é legal. 1:28 infelizmente ja sabemos wue parte do desempenho, depende do conhecimento do hardware
Esse teste é a Choquei da Programação. Clickbait pra gerar engajamento.
Eu gosto de fofoca, nessa linha é legal mesmo o post kkkkkkkk mas inútil ainda
Os testes do techempower também são ruins. Se você ver os códigos enviados, vai ver que estão otimizados não para o caso comum ou idiomático, mas para vencer os benchmarks.
Pois é, isso é o foda de gamificação e testes padrões.
No fim não achei um outro exemplo representativo de web, por isso acabei usando techempower. Benchmark tem que ter muito cuidado ao se fazer e analisar, com software e framework a maioria dos benchmarks que vejo dá pra jogar no lixo
Luan santana, mudou de profissão
kkkkkkkkkkkkkkkkk agr vou ter que cortar o cabelo
Sério que acesso a memória é lento? Eu achei que era um dos mais rápidos
se comparado a instruções da CPU, um cache miss é bem lento (+50 ciclos). Se comparado a IO (disco ou net) é bem rápido
top
first