Me deu uma boa ideia de projeto mesmo. No vídeo de build quero mostrar como fazer esse tipo de coisa e os "binfings" de C/C++/Zig pra Python usando Cython
Da hora! Na verdade, Python é um high-level wrapper para C! rs Por isso, é a linguagem mais legal! Quando está com preguiça, use high level, quando o chefe enche saco que o app tem que ser mais rápido, use low-level rs Tudo possível com Python.
@@waine_jr Sabia que era a macumba alemã que te levou a usar Cython. Vou gravar um vídeo agora que vai te inspirar mais ainda :) Pelo jeito, você usa principalmente Python no seu trabalho, né?
@@pyajudeme9245 Uso Python principalmente no trabalho sim, mas sempre com integração com C/CUDA, então sempre busquei maneiras de integrar com baixo nível e o Cython caiu como uma luva
@@waine_jr Vou te mostrar muitas coisas da hora com Cython. Hoje em dia, uso 90% Cython nos meus projetos., só pouco de Python. A integração de unordered_map em Python vai ser da hora! Vai ver!:)
Ainda bem que você fez meio que um "disclaimer" a respeito do que você quis dizer com baixo nível, porque na prática é um subset específico de implementações(FFI) para se aproximar mais da máquina que também está presente em outras linguagens alto nível. Basicamente está terceirizando o trabalho, não está relacionado a performance da linguagem em si, age como um proxy. Parabéns pelo vídeo, esperando pelo vídeo do bind com o zig. heheh
De certa maneira é terceirizar sim, mas é um processo comum em todas as linguagens. Até porque pra você fazer chamadas de sistema em qualquer SO é por meio de FFI, então todas fazem esse processo tmb. Acho que o argumento principal é da "ergonomia" de como fazer esse proxy de chamadas. Sobre Zig quero lançar essa semana ainda o vídeo, apanhei um monte pra conseguir mas acho que finalmente ficou ok hahahahaha
Vídeo muito bom, explicativo e com bons argumentos!!! . . . Um feedback: Como comentei há algum tempo atrás, venho acompanhando seu canal desde abril ("Como programar em uma GPU") e fiz uma crítica em um video posteriormente sobre o uso da "lousa" e como a sua letra atrapalhava um pouco o entendimento por ser muito cursiva. Lembro até de dizer para usar as ferramentas de texto do software de desenho para melhorar o uso da "lousa", mas tu comentou que gostava de fazer dessa forma e disse que iria melhorar a letra, então foi lá e realmente melhorou!! Nos últimos videos e lives, deu pra perceber a diferença pra melhor nesse ponto prático da didática, está muito mais legíveis as tuas explicações usando esse recurso. Meus parabéns, de verdade 🤝!
Hahahaha eu lembro que comentou, comecei a escrever letra de forma e maior pra conseguir deixar mais legível. Depois fui rever algumas anotações e nem eu entendia direito o que tava escrito, mt obrigado pelo feedback mesmo!
@@waine_jr hahahahahaha que ótimo que pude ajudar! Eu não falo muito nas lives, mas sempre assisto. Logo me tornarei membro, preciso revisar as minhas assinaturas... Tenho muitas "inúteis", vou revisar, cancelar umas e assinar outras, como a sua. Acho o seu canal muito bom mesmo, continue assim!
@@pypees muito massa que acompanha as lives! Dá pra ter uma interação muito legal com vocês, falar e ver curiosidades, mostrar o Chico hahahaha E os membros não vai se arrepender, atualmente tem as duas séries de ZigZagOS, que agr vou começar a migrar pra ESP32, e o zLBM que daqui a pouco vou começar a migrar pra GPU também. Também vou começar a fazer alguns vídeos técnicos "avulsos" mostrando códigos, algoritmos e otimizações que utilizo
Bom vídeo, mas acho que dá pra questionar algumas premissas, tais como C ser baixo nível. Também não sei se a capacidade de invocar alguma coisa nativamente é suficiente pra mudar o nível da linguagem, quando os recursos próprios da linguagem não estão próximos da máquina.
Essa questão de nível tem os dois lados, a linguagem é tão baixa quanto mais perto da máquina dá pra ir, ou tão alto nível quanto o seu maior nível de abstração? É uma discussão válida e nem sei o que penso disso.
Python é considerado uma linguagem de alto nível porque abstrai muitos detalhes da implementação, permitindo que os desenvolvedores escrevam código de forma mais intuitiva e produtiva, sem se preocupar com a gestão de memória ou a sintaxe complexa de linguagens de baixo nível. Cython, por outro lado, é uma extensão de Python que permite escrever código que pode ser compilado em C. Isso não muda a natureza de Python, mas oferece uma maneira de otimizar o desempenho em casos específicos, permitindo que desenvolvedores utilizem tanto a simplicidade do Python quanto a eficiência do C. Portanto, Python continua sendo uma linguagem de alto nível, enquanto Cython é uma ferramenta que pode ser usada quando é necessário desempenho adicional.
cara, seria interessante sim, não só de Cython mas de C/C++ tbm. Eu tenho uma dificuldade para gerenciar dependências de projetos de C/C++, justamente por conta do build. Em alguns projetos eu usava o Conan, mas as libs do conancenter o pessoal não mantem atualizada, o vckpg sempre da pau e acabo usando o Makefile/CMake no final. Em outras linguagens que tbm expõe .so não achamos uma boa documentação para a solução que quero ou libs maduras.
Acho que Zig é uma boa alternativa pra esse caso, no vídeo de build vou usar Zig+Python setup pra fazer todo esse processo automaticamente. Importante lembrar que Zig tmb compila C/C++, então dá pra usar ele pra projetos nessa linguagem tmb. Mas assim, não tem milagre, em geral é bem chato fazer esses gerenciamentos e dá um trabalho do caramba pra fazer a primeira vez. Pelo menos depois da primeira é só replicar.
A questão não é ser feito em C, a linguagem de implementação não diz nada sobre o resultado final. O que foi abordado no vídeo é a capacidade de interagir com C usando FFI, o que não é garantido só pq o interpretador ou compilador foi escrito usando C (embora seja relativamente fácil de implementar nesses casos). Também pode ocorrer o oposto, a implementação da linguagem não é em C, mas ainda assim ela provê uma FFI que permite interagir com código C, o que é bem útil para usar bibliotecas do SO, por exemplo.
@@Israel220500 Ótima colocação. O que me pareceu é que a implementação da linguagem python através de seu compilador e ou interpretador permite acessar baixos níveis a ponto de poder realizar chamadas de através de FFI/ABI de funções escritas em C ou C++, de forma que pode-se ter acesso a funções de baixo nível. Mas, usar o python pra "chamar funções de outro linguagem" não significa que vc está escrevendo em python. Você está usando o interpretador ou o compilador de uma linguagem pra fazer chamadas a funções escritas em outra. Isso provavelmente é viavél em pouquíssimos e específicos casos. Seria como escrever assemby dentro do C. Não deveria ser comum, caso contrário, seja melhor migrar para o C ou Assembly de uma vez. Perdoem minhas limitações, estou aprendendo ainda. É uma opinião. Por favor, me corrija se estiver falando merda. Obrigado e Abraços. Douglas.
Fiz um algoritmo de resolver 2048 usando monte carlo tree search em python e selenium. Eu pego a representação no html e transformo numa matrix do numpy (eu espero que o numpy represente essa matriz como um array contíguo pra tirar vantagem do cache da CPU). O problema: Eu só consigo simular em tempo hábil, 7 níveis de jogadas à frente, depois disso nosso python véio fica too much lento. Uma solução iterativa não foi muito melhor. Será que FFI pra C seria uma boa opção? Escrever toda a parte de simular e escolher a melhor jogada em C e mandar nosso python véio usar. O foda seria eu fazer isso e não adiantar nada kkkk. Mas já tá óbvio que o gargalo tá na quantidade de níveis que a minha árvore de ações tem. já que ela cresce exponencialmente.
Eu não manjo de simulação monte carlo, mas de árvore tem que tomar muito cuidado com a complexidade do algoritmo que tá usando. se tiver sempre considerando quatro jogadas, isso dá 4^lvl que pro 7 nível daria 4^7=2^14=1024*16=16k, o que já são bastante árvores e branches pro Python mesmo. Eu recomendo tentar alguma linguagem mais de baixo nível pra esse tipo de coisa mesmo, um C deve ser muito melhor do que Python. Além disso se conseguir paralelizar parte das árvores ajudaria mt também. Mas aconselho a fazer análise de desempenho com profile (pra Python o py-spy é mt bom) e fazer prototipagem em uma linguagem de baixo nível. Vou lançar um vídeo mostrando como fazer essa integração, aí pode usar de base pra escrever o baixo nível em C, Zig, C++ ou qualquer outra linguagem que quiser.
@@waine_jr Sim, talvez tenha sido burrada usar python pra computar algoritmo de árvore. Mas o meu projeto usa selenium pra jogar no site original do 2048, e python tem uma das melhores interfaces pra selenium, IMO. Pensei em fazer o profiling mesmo antes de sair escrevendo código. No mais, vlw pelos insights.
Uma das coisas que mais uso eh FFI, em C# eh simples e pratico assim como python, em zig nem se fala, nem parece que eu tou fazendo uma chamada externa, agora em rust eh ruim demais, tem que usar unsafe em tudo, o compilador chora o tempo todo
O complicado de Rust é sempre o compilador mesmo kkkkkkk nesse sentido Zig é muito superior, e adiciona boa parte das questões de segurança que dão mais problemas em C, além de outras a mais no modo Safe (se você tenta converter null pra ponteiro pra algo dá erro). E depois que inventaram o FFI não existe desculpa pra problema de desempenho em alto nível, só converter o módulo ou parte crítica pra uma linguagem de baixo nível e feshow.
Se tem capacidade de escrever código na própria linguagem que é compilado pra C, com mesmo desempenho, então chamado por meio de FFI, aí sim, pode ser baixo nível tmb
Muito bom video, parabens! Apesar d ja ter usado eg, P/Invoke no C# e JNI no Java, nunca tinha ouvido falar em FFI. Nao como um conceito proprio. E pelo q eu entendi, FFI eh um conceito de alto nivel q usa conceitos d nivel mais baixo - ie, conceitos em outros niveis d abstracao - pra permitir interoperabilidade entre programas escritos em linguagens diferentes (eg, "usa" a calling convention da ABI pra determinar - dentre outras coisas - a passagem d argumentos e retorno d valores, "usa" os mecanismos d linkagem externa/dinamica do OS, converte tipos, compatibiliza diferentes estrategias d gerenciamento de memoria, compatibiliza estrategias d tratamento de erro - q geralmente sao conceitos do "runtime" da linguagem -, etc). Assim, eu acho q o uso do conceito d FFI - q essencialmente faz uso d conceitos extrinsecos - pra argumentar q Python seja intrinsecamente baixo nivel seja... Problematico. Pudera mtos contra argumentarem q, por este msm criterio (ie, ter uma FFI), todas linguagens alto nivel tb poderiam ser consideradas baixo nivel! No entanto, entendo q diferentes implementacoes d FFIs variem em "eficiencia" no uso desses outros conceitos e em "verbosidade" na maneira com q sao expressas em codigo. Desta forma, interpretei seu argumento como sendo uma ode a eficiencia e facilidade d uso da FFI do Python (ctypes?). Quanto ao Cython... Nao seria o Cython um mecanismo d transpilacao/traducao pra outra linguagem (C), e, assim, nao propriamente uma implementacao d FFI? Alem disso, a existencia d um mecanismo de traducao pra uma linguagem baixo nivel nao seria uma evidencia d q a linguagem traduzida nao eh baixo nivel? Abçs,
Muito bom seu comentário! Resumiu o vídeo mt bem e ainda adicionou pontos bem importantes de discussão, vocês da comunidade do desempenho são mt f*das O argumento principal é esse mesmo com relação a facilidade e eficiência de desenvolver e chamar código "em C" utilizando Python. Essa praticidade ao meu ver não é tão comum nas linguagens, mesmo aquelas que apresentam integração com FFI nativamente (desenvolver e integrar um módulo de C++ pra JS é bem mais complicado que em Python/Cython). A principal vantagem do Cython em comparação a outras alternativas como ctypes e CFFI é seu desempenho e integração nativos com Python, o overhead de troca de contexto é menor e a conversão e checagem de tipos é feita automaticamente. O operacional dele é uma geração de código em C, compilação dele e gerar o .so pra ser importado e chamado diretamente pelo Python. E com relação a essa tradução, é praticamente uma conversão de 1 pra 1 se você utilizar só a sintaxe de C (cdef), ele só adiciona coisas em volta das chamadas de Python necessárias, mas é uma boa discussão e um bom ponto sim Novamente, mt bom ver esse tipo de comentário e discussão por aqui, mt orgulho da comunidade do desempenho.
Ola@@waine_jr , obrigado pela resposta! Entendi esse seu novo argumento assim: se ha uma traducao quase q direta pra uma linguagem d baixo nivel, entao isso eh uma evidencia d q a linguagem traduzida tem um baixo nivel de abstracao. No entanto, e apesar deu nao conhecer o Cython, eu contra argumento q isso depende muito de como o tradutor cria essa ponte entre conceitos d alto nivel pra baixo nivel, ie, qnto codigo eh "gerado" e quao complexo esse codigo eh. Alem disso, parecem existir inumeras ferramentas d traducao direta d outras linguagens d alto pra baixo nivel eg, swig, emscripten/embind, o velho e morto gcj, etc., o q IMO "dilui" o argumento da traducao direta ser evidencia d baixo nivel. E vou alem: mtas linguagens d alto nivel usam/podem usar um backend comum com C/C++, eg, julia, swift, kotlin, haskell, ocaml, etc. q usam o backend do LLVM. Todas elas, a despeito de suas peculiaridades no lido e alto nivel d abstracao d certos conceitos, sao capazes d serem traduzidas pra uma representacao intermediaria e gerar codigo de maquina d maneira relativamente otimizada "como C". Ou seja: o fato dessas linguagens produzirem codigo de maquina d maneira "otima" parece mais um testemunho sobre a qualidade dos tradutores/compiladores do q uma evidencia d baixo nivel d abstracao. Eu particularmente nao vejo Python como baixo nivel, ou como um "wrapper de C" como uns disseram aqui, mas como uma ferramenta de automacao por excelencia e, portanto, com inumeras facilidades pra operar em diversos contextos, como VMs ou com a plataforma nativa. Abçs,
Dito isso, penso q Python seja quase q um pseudocodigo com algumas abstracoes sobre listas. Portanto, imagino q codigo em "vanilla Python syntax" nao seja tao dificil traduzir eficiente e eficazmente prum nivel mais baixo, mais proximo da plataforma. Ainda mais se vc usar um conjunto sintatico sobre Python (o cdef) q facilita o trabalho do tradutor.
@@VulgoGS bem como codigo compilado (d maquina) tb eh "interpretado" em microcodigo :p Tudo depende d como as abstracoes q tu usa mapeiam pras capacidades da maquina!
eu parei tb.. pq isso se chama "fanboy" de linguagem..kkk.. loucura ai.. se fosse assim até na minha BMW os módulos embarcados seriam feitos em Python.. só rindo. kkkk.
Python muito construir scripts de C, muitos do recursos de baixo nível que podemos ter com o Python e graças a C, senão estou enganado o interpretador do Python é escrito em C, eu sempre pensei que o Python a ideia é sempre esta focado a ser mais alto nível possível.
O interpretador de Python é em C sim, o CPython, e acho que isso ajuda muito a acelerar as chamadas pra C, tem um overhead muito baixo. Python ao meu ver tem essa flexibilidade de vc conseguir escolher alto ou baixo nível num mesmo ecossistema, e pra mim isso é o maior diferencial e o pq gosto tanto da linguagem.
![Curso Lógica de Programação Completo 2024 [Iniciantes] + Desafios + Muita prática](http://i.ytimg.com/vi/iF2MdbrTiBM/mqdefault.jpg)
![Curso Lógica de Programação Completo 2024 [Iniciantes] + Desafios + Muita prática](/img/tr.png)
cara, seria incrivel um video criando uma lib em cython pra renderizar 3d com opengl e etc
Me deu uma boa ideia de projeto mesmo. No vídeo de build quero mostrar como fazer esse tipo de coisa e os "binfings" de C/C++/Zig pra Python usando Cython
@@andreplacet vc tem interesse em programacao grafica, camarada?
Da hora! Na verdade, Python é um high-level wrapper para C! rs Por isso, é a linguagem mais legal! Quando está com preguiça, use high level, quando o chefe enche saco que o app tem que ser mais rápido, use low-level rs Tudo possível com Python.
Perfeito! Inclusive seu vídeo me inspirou mt a saber mais sobre Cython, o processo dele e como integrar com lib de C/C++ (e Zig, por consequência)
@@waine_jr Sabia que era a macumba alemã que te levou a usar Cython. Vou gravar um vídeo agora que vai te inspirar mais ainda :) Pelo jeito, você usa principalmente Python no seu trabalho, né?
@@pyajudeme9245 Uso Python principalmente no trabalho sim, mas sempre com integração com C/CUDA, então sempre busquei maneiras de integrar com baixo nível e o Cython caiu como uma luva
O professor hans curte então é bom.. e é mesmo... parabéns pelo conteúdo
@@waine_jr Vou te mostrar muitas coisas da hora com Cython. Hoje em dia, uso 90% Cython nos meus projetos., só pouco de Python. A integração de unordered_map em Python vai ser da hora! Vai ver!:)
Ainda bem que você fez meio que um "disclaimer" a respeito do que você quis dizer com baixo nível, porque na prática é um subset específico de implementações(FFI) para se aproximar mais da máquina que também está presente em outras linguagens alto nível. Basicamente está terceirizando o trabalho, não está relacionado a performance da linguagem em si, age como um proxy.
Parabéns pelo vídeo, esperando pelo vídeo do bind com o zig. heheh
De certa maneira é terceirizar sim, mas é um processo comum em todas as linguagens. Até porque pra você fazer chamadas de sistema em qualquer SO é por meio de FFI, então todas fazem esse processo tmb. Acho que o argumento principal é da "ergonomia" de como fazer esse proxy de chamadas.
Sobre Zig quero lançar essa semana ainda o vídeo, apanhei um monte pra conseguir mas acho que finalmente ficou ok hahahahaha
Vim através do Pyajudeme, que canal maravilho cara, trampo sensacional.
Valeu, meu querido! O canal dele é mt bom, foi o que me inspirou a fazer tudo isso e me ensinou a integração de Zig com Python usando o Cython
Vídeo muito bom, explicativo e com bons argumentos!!!
.
.
.
Um feedback:
Como comentei há algum tempo atrás, venho acompanhando seu canal desde abril ("Como programar em uma GPU") e fiz uma crítica em um video posteriormente sobre o uso da "lousa" e como a sua letra atrapalhava um pouco o entendimento por ser muito cursiva.
Lembro até de dizer para usar as ferramentas de texto do software de desenho para melhorar o uso da "lousa", mas tu comentou que gostava de fazer dessa forma e disse que iria melhorar a letra, então foi lá e realmente melhorou!!
Nos últimos videos e lives, deu pra perceber a diferença pra melhor nesse ponto prático da didática, está muito mais legíveis as tuas explicações usando esse recurso. Meus parabéns, de verdade 🤝!
Hahahaha eu lembro que comentou, comecei a escrever letra de forma e maior pra conseguir deixar mais legível. Depois fui rever algumas anotações e nem eu entendia direito o que tava escrito, mt obrigado pelo feedback mesmo!
@@waine_jr hahahahahaha que ótimo que pude ajudar!
Eu não falo muito nas lives, mas sempre assisto. Logo me tornarei membro, preciso revisar as minhas assinaturas... Tenho muitas "inúteis", vou revisar, cancelar umas e assinar outras, como a sua.
Acho o seu canal muito bom mesmo, continue assim!
@@pypees muito massa que acompanha as lives! Dá pra ter uma interação muito legal com vocês, falar e ver curiosidades, mostrar o Chico hahahaha
E os membros não vai se arrepender, atualmente tem as duas séries de ZigZagOS, que agr vou começar a migrar pra ESP32, e o zLBM que daqui a pouco vou começar a migrar pra GPU também. Também vou começar a fazer alguns vídeos técnicos "avulsos" mostrando códigos, algoritmos e otimizações que utilizo
Bom vídeo, mas acho que dá pra questionar algumas premissas, tais como C ser baixo nível. Também não sei se a capacidade de invocar alguma coisa nativamente é suficiente pra mudar o nível da linguagem, quando os recursos próprios da linguagem não estão próximos da máquina.
Essa questão de nível tem os dois lados, a linguagem é tão baixa quanto mais perto da máquina dá pra ir, ou tão alto nível quanto o seu maior nível de abstração? É uma discussão válida e nem sei o que penso disso.
Python é considerado uma linguagem de alto nível porque abstrai muitos detalhes da implementação, permitindo que os desenvolvedores escrevam código de forma mais intuitiva e produtiva, sem se preocupar com a gestão de memória ou a sintaxe complexa de linguagens de baixo nível.
Cython, por outro lado, é uma extensão de Python que permite escrever código que pode ser compilado em C. Isso não muda a natureza de Python, mas oferece uma maneira de otimizar o desempenho em casos específicos, permitindo que desenvolvedores utilizem tanto a simplicidade do Python quanto a eficiência do C.
Portanto, Python continua sendo uma linguagem de alto nível, enquanto Cython é uma ferramenta que pode ser usada quando é necessário desempenho adicional.
cara, seria interessante sim, não só de Cython mas de C/C++ tbm.
Eu tenho uma dificuldade para gerenciar dependências de projetos de C/C++, justamente por conta do build.
Em alguns projetos eu usava o Conan, mas as libs do conancenter o pessoal não mantem atualizada, o vckpg sempre da pau e acabo usando o Makefile/CMake no final.
Em outras linguagens que tbm expõe .so não achamos uma boa documentação para a solução que quero ou libs maduras.
Acho que Zig é uma boa alternativa pra esse caso, no vídeo de build vou usar Zig+Python setup pra fazer todo esse processo automaticamente. Importante lembrar que Zig tmb compila C/C++, então dá pra usar ele pra projetos nessa linguagem tmb.
Mas assim, não tem milagre, em geral é bem chato fazer esses gerenciamentos e dá um trabalho do caramba pra fazer a primeira vez. Pelo menos depois da primeira é só replicar.
@@waine_jr vai ser animal, vou esperar o vídeo
Python é de alto nível
Resposta correta: é feito em C e C é baixo nivel, logo python tbm é
A questão não é ser feito em C, a linguagem de implementação não diz nada sobre o resultado final. O que foi abordado no vídeo é a capacidade de interagir com C usando FFI, o que não é garantido só pq o interpretador ou compilador foi escrito usando C (embora seja relativamente fácil de implementar nesses casos). Também pode ocorrer o oposto, a implementação da linguagem não é em C, mas ainda assim ela provê uma FFI que permite interagir com código C, o que é bem útil para usar bibliotecas do SO, por exemplo.
@@Israel220500 to só zuando amigo, nem vi o video ainda kkj
@@Israel220500 Ótima colocação. O que me pareceu é que a implementação da linguagem python através de seu compilador e ou interpretador permite acessar baixos níveis a ponto de poder realizar chamadas de através de FFI/ABI de funções escritas em C ou C++, de forma que pode-se ter acesso a funções de baixo nível. Mas, usar o python pra "chamar funções de outro linguagem" não significa que vc está escrevendo em python. Você está usando o interpretador ou o compilador de uma linguagem pra fazer chamadas a funções escritas em outra. Isso provavelmente é viavél em pouquíssimos e específicos casos. Seria como escrever assemby dentro do C. Não deveria ser comum, caso contrário, seja melhor migrar para o C ou Assembly de uma vez. Perdoem minhas limitações, estou aprendendo ainda. É uma opinião. Por favor, me corrija se estiver falando merda. Obrigado e Abraços. Douglas.
Agora que o governo dos Estados Unidos proibiu C, o interpretador Python vai ser escrito em JavaScript 😅
@@FodaseGoogreorio-h7v Rust é mais factível
Fiz um algoritmo de resolver 2048 usando monte carlo tree search em python e selenium. Eu pego a representação no html e transformo numa matrix do numpy (eu espero que o numpy represente essa matriz como um array contíguo pra tirar vantagem do cache da CPU).
O problema: Eu só consigo simular em tempo hábil, 7 níveis de jogadas à frente, depois disso nosso python véio fica too much lento. Uma solução iterativa não foi muito melhor. Será que FFI pra C seria uma boa opção? Escrever toda a parte de simular e escolher a melhor jogada em C e mandar nosso python véio usar.
O foda seria eu fazer isso e não adiantar nada kkkk. Mas já tá óbvio que o gargalo tá na quantidade de níveis que a minha árvore de ações tem. já que ela cresce exponencialmente.
Eu não manjo de simulação monte carlo, mas de árvore tem que tomar muito cuidado com a complexidade do algoritmo que tá usando. se tiver sempre considerando quatro jogadas, isso dá 4^lvl que pro 7 nível daria 4^7=2^14=1024*16=16k, o que já são bastante árvores e branches pro Python mesmo.
Eu recomendo tentar alguma linguagem mais de baixo nível pra esse tipo de coisa mesmo, um C deve ser muito melhor do que Python. Além disso se conseguir paralelizar parte das árvores ajudaria mt também. Mas aconselho a fazer análise de desempenho com profile (pra Python o py-spy é mt bom) e fazer prototipagem em uma linguagem de baixo nível.
Vou lançar um vídeo mostrando como fazer essa integração, aí pode usar de base pra escrever o baixo nível em C, Zig, C++ ou qualquer outra linguagem que quiser.
@@waine_jr Sim, talvez tenha sido burrada usar python pra computar algoritmo de árvore. Mas o meu projeto usa selenium pra jogar no site original do 2048, e python tem uma das melhores interfaces pra selenium, IMO.
Pensei em fazer o profiling mesmo antes de sair escrevendo código.
No mais, vlw pelos insights.
Uma das coisas que mais uso eh FFI, em C# eh simples e pratico assim como python, em zig nem se fala, nem parece que eu tou fazendo uma chamada externa, agora em rust eh ruim demais, tem que usar unsafe em tudo, o compilador chora o tempo todo
O complicado de Rust é sempre o compilador mesmo kkkkkkk nesse sentido Zig é muito superior, e adiciona boa parte das questões de segurança que dão mais problemas em C, além de outras a mais no modo Safe (se você tenta converter null pra ponteiro pra algo dá erro).
E depois que inventaram o FFI não existe desculpa pra problema de desempenho em alto nível, só converter o módulo ou parte crítica pra uma linguagem de baixo nível e feshow.
"promete oque entrega"? 🤔😂
kkkkkkkkkkkkkkkkkk Cython quebrando paradigmas e frases
@@waine_jr coisas de little endian. 😂
@@edmarhenches875 kkkkkkkkkkkkkkkkkkk troquei a endianess do sistema e olha no que deu
Sendo assim qualquer linguagem com ffi é baixo nível. Inclusive Java com JNI
Se tem capacidade de escrever código na própria linguagem que é compilado pra C, com mesmo desempenho, então chamado por meio de FFI, aí sim, pode ser baixo nível tmb
Muito bom video, parabens!
Apesar d ja ter usado eg, P/Invoke no C# e JNI no Java, nunca tinha ouvido falar em FFI. Nao como um conceito proprio.
E pelo q eu entendi, FFI eh um conceito de alto nivel q usa conceitos d nivel mais baixo - ie, conceitos em outros niveis d abstracao - pra permitir interoperabilidade entre programas escritos em linguagens diferentes (eg, "usa" a calling convention da ABI pra determinar - dentre outras coisas - a passagem d argumentos e retorno d valores, "usa" os mecanismos d linkagem externa/dinamica do OS, converte tipos, compatibiliza diferentes estrategias d gerenciamento de memoria, compatibiliza estrategias d tratamento de erro - q geralmente sao conceitos do "runtime" da linguagem -, etc).
Assim, eu acho q o uso do conceito d FFI - q essencialmente faz uso d conceitos extrinsecos - pra argumentar q Python seja intrinsecamente baixo nivel seja... Problematico. Pudera mtos contra argumentarem q, por este msm criterio (ie, ter uma FFI), todas linguagens alto nivel tb poderiam ser consideradas baixo nivel!
No entanto, entendo q diferentes implementacoes d FFIs variem em "eficiencia" no uso desses outros conceitos e em "verbosidade" na maneira com q sao expressas em codigo. Desta forma, interpretei seu argumento como sendo uma ode a eficiencia e facilidade d uso da FFI do Python (ctypes?).
Quanto ao Cython... Nao seria o Cython um mecanismo d transpilacao/traducao pra outra linguagem (C), e, assim, nao propriamente uma implementacao d FFI? Alem disso, a existencia d um mecanismo de traducao pra uma linguagem baixo nivel nao seria uma evidencia d q a linguagem traduzida nao eh baixo nivel?
Abçs,
Muito bom seu comentário! Resumiu o vídeo mt bem e ainda adicionou pontos bem importantes de discussão, vocês da comunidade do desempenho são mt f*das
O argumento principal é esse mesmo com relação a facilidade e eficiência de desenvolver e chamar código "em C" utilizando Python. Essa praticidade ao meu ver não é tão comum nas linguagens, mesmo aquelas que apresentam integração com FFI nativamente (desenvolver e integrar um módulo de C++ pra JS é bem mais complicado que em Python/Cython).
A principal vantagem do Cython em comparação a outras alternativas como ctypes e CFFI é seu desempenho e integração nativos com Python, o overhead de troca de contexto é menor e a conversão e checagem de tipos é feita automaticamente. O operacional dele é uma geração de código em C, compilação dele e gerar o .so pra ser importado e chamado diretamente pelo Python. E com relação a essa tradução, é praticamente uma conversão de 1 pra 1 se você utilizar só a sintaxe de C (cdef), ele só adiciona coisas em volta das chamadas de Python necessárias, mas é uma boa discussão e um bom ponto sim
Novamente, mt bom ver esse tipo de comentário e discussão por aqui, mt orgulho da comunidade do desempenho.
Ola@@waine_jr , obrigado pela resposta!
Entendi esse seu novo argumento assim: se ha uma traducao quase q direta pra uma linguagem d baixo nivel, entao isso eh uma evidencia d q a linguagem traduzida tem um baixo nivel de abstracao. No entanto, e apesar deu nao conhecer o Cython, eu contra argumento q isso depende muito de como o tradutor cria essa ponte entre conceitos d alto nivel pra baixo nivel, ie, qnto codigo eh "gerado" e quao complexo esse codigo eh. Alem disso, parecem existir inumeras ferramentas d traducao direta d outras linguagens d alto pra baixo nivel eg, swig, emscripten/embind, o velho e morto gcj, etc., o q IMO "dilui" o argumento da traducao direta ser evidencia d baixo nivel. E vou alem: mtas linguagens d alto nivel usam/podem usar um backend comum com C/C++, eg, julia, swift, kotlin, haskell, ocaml, etc. q usam o backend do LLVM. Todas elas, a despeito de suas peculiaridades no lido e alto nivel d abstracao d certos conceitos, sao capazes d serem traduzidas pra uma representacao intermediaria e gerar codigo de maquina d maneira relativamente otimizada "como C". Ou seja: o fato dessas linguagens produzirem codigo de maquina d maneira "otima" parece mais um testemunho sobre a qualidade dos tradutores/compiladores do q uma evidencia d baixo nivel d abstracao.
Eu particularmente nao vejo Python como baixo nivel, ou como um "wrapper de C" como uns disseram aqui, mas como uma ferramenta de automacao por excelencia e, portanto, com inumeras facilidades pra operar em diversos contextos, como VMs ou com a plataforma nativa.
Abçs,
Dito isso, penso q Python seja quase q um pseudocodigo com algumas abstracoes sobre listas. Portanto, imagino q codigo em "vanilla Python syntax" nao seja tao dificil traduzir eficiente e eficazmente prum nivel mais baixo, mais proximo da plataforma. Ainda mais se vc usar um conjunto sintatico sobre Python (o cdef) q facilita o trabalho do tradutor.
Python na verdade é uma API pra vc rodar código de outras linguagens
Linguagem cola, muito bom
Melhor lua pra isso fera
Com certeza, mas infelizmente lua não tem sympy e pacote pra todos os casos de uso do mundo, aí prefiro o Python mesmo kkkkkkkkkk
@@waine_jr ah era só isso. !!! Aí nesse caso era melhor usar o Gnu octaveio. Converte em C++
Parei no "mesmo desempenho de c++", se fosse assim teria jogo em python kk linguagem compilada > interpretada.
se os pais do batman morreram, como ele nasceu?
@@VulgoGS bem como codigo compilado (d maquina) tb eh "interpretado" em microcodigo :p
Tudo depende d como as abstracoes q tu usa mapeiam pras capacidades da maquina!
@@waine_jr ele nasceu quando os pais estavam vivos, isso não muda o fato de q C++ sola o Python com as 2 mãos nas costas.
eu parei tb.. pq isso se chama "fanboy" de linguagem..kkk.. loucura ai.. se fosse assim até na minha BMW os módulos embarcados seriam feitos em Python.. só rindo. kkkk.
Python e só uma interface pra usar C. Falei e tô leve
Errado não tá hahahaaha
Python é uma linguagem completa, com recursos próprios, que permite desenvolvimento rápido e fácil, sem a necessidade de se ater a C.
Python muito construir scripts de C, muitos do recursos de baixo nível que podemos ter com o Python e graças a C, senão estou enganado o interpretador do Python é escrito em C, eu sempre pensei que o Python a ideia é sempre esta focado a ser mais alto nível possível.
O interpretador de Python é em C sim, o CPython, e acho que isso ajuda muito a acelerar as chamadas pra C, tem um overhead muito baixo. Python ao meu ver tem essa flexibilidade de vc conseguir escolher alto ou baixo nível num mesmo ecossistema, e pra mim isso é o maior diferencial e o pq gosto tanto da linguagem.
Lá ele 1000x 4:31
kkkkkkkkkkkkkkkkkk
Isso foi muito baixo de sua parte 😕
que toppp
Valeu, meu querido! Disseminar a palavra do Python+Cython+Zig pra comunidade dev kkkkkk