Executando verificação de segurança...

JoasSurfer

"Forçar inline indiscriminadamente é impacta no cache de instruções e o aumento do tamanho do binário, pode acabar poluindo o cache de instruções Sim, claro. Não estava sugerindo fazer inline de tudo. Isso obviamente é impraticável e é exatamente por is..."
· 0 comentário · ·
"Não sei porque ficou mais lento. De novo AOT não consegue fazer milagres. Não testei com PGO, mas mesmo assim acredito que ficaria mais lento. Assim que tiver um tempo vou testar GraalVM com PGO. $ native-image --gc=G1 -R:+AlwaysPreTouch -R:InitialHeap..."
· 0 comentário · ·
"AOT: Passei uma vez pelo código e o binário vai ser justamente isso aqui x. JIT: Tive que passar várias vezes pelo mesmo trecho de código então acho que posso otimizar isso aqui x. Valeu pelas dicas, vou assistir. Eu vejo o trade-off assim: AOT: Não va..."
· 2 comentários · ·
"E se você estiver realmente preocupado com desempenho, poderia ajustar esse tamanho para preencher a cache L1 do seu processador. Com o Java também dá para fazer isso. Tenho um exemplo usando o Java heap e outro usando memória nativa via sun.misc.Unsaf..."
· 0 comentário · ·
"Exatamente. A otimização da alocação de memória é uma responsabilidade do programador. Isso envolve técnicas como alocação em blocos, uso de pools de memória e até mesmo a implementação de alocadores personalizados. O compilador, neste caso, não vai of..."
· 2 comentários · ·
"Boa dica! Uma maneira de provar/desprovar isso seria pre-allocar um monte de Entry objects e rodar o benchmark dos puts com os objetos já pre-allocados pelo C++. Concorda? Agora isso explicaria a vantagem do put, mas não explica a vantagem do get e do..."
· 4 comentários · ·
"É quase certo que sempre você conseguirá obter um resultado melhor em C++ do que em Java ou C#, aina mais no estado que eles estão hoje que ainda tem muito potencial para melhor (até C++ ainda tem) nas otimizações. Mas o trabalho será cada vez maior pa..."
· 0 comentário · ·

AnteriorPróximo