O método de entrada em coreano era tão inconveniente que eu nem conseguia usar; hoje em dia melhorou bastante? Problemas como no Chrome, em que a digitação falha ou o último caractere é apagado, eram bem sérios.
Esse era o jeito como eu trabalhava com código de depuração quando eu estava numa empresa de jogos há 25 anos, e não era só o strcpy, né. No release, isso voltava a ficar liberado para ganhar desempenho e assim era colocado em produção. Na verdade, no lado de jogos, colisão de memória é uma das coisas mais sensíveis, então o trabalho também era feito com muita cautela e atenção, a ponto de criarmos e usarmos nosso próprio depurador de memória. Mas hoje, olhando para trás, vejo que aquilo estava basicamente criando um garbage collector. Que lembrança nostálgica.
Ah, li com bastante interesse. Você disse que a necessidade de validação adicional é determinada com base na confiabilidade; também fiquei curioso para saber como esse valor de confiabilidade foi medido.
Parece um texto que resolveu bem o problema usando VLM, gostei bastante de ler.
Mas fiquei com uma dúvida ao ler o texto:
Detecção com YOLO – recortar apenas o objeto principal para reduzir a área de análise
Gostaria de saber como vocês incluíram esse processo.
Enquanto eu lia, pensei que o VLM provavelmente teria desempenho melhor que o YOLO; então, ao recortar, não existiria o risco de o modelo YOLO julgar errado e informações importantes se perderem antes mesmo de serem passadas ao VLM?
O que levou vocês a pensar nesse recorte como solução, e como validaram a precisão antes de adotá-lo?
Em alguns MCUs de alto desempenho, como você mencionou, é possível usar a MPU para configurar por região não apenas as permissões de acesso, mas também propriedades relacionadas ao cache. O material da ST a seguir é uma boa referência: https://community.st.com/t5/stm32-mcus/…
No entanto, no ESP32-S3 usado neste texto, não é oferecido um mecanismo como o de CPUs de uso geral ou de alguns MCUs, em que os atributos cacheable / non-cacheable podem ser configurados por região de memória via MPU ou algo semelhante.
No caso do ESP32-S3, a memória externa (Flash/PSRAM) foi projetada para ser acessada por meio do cache/MMU (TRM 4.3.3 External Memory), e o controle de permissões de acesso é feito pelo PMS (Permission Management System) (TRM Capítulo 15), mas esse recurso serve para proteção de acesso e não tem o papel de alterar se o acesso passa pelo cache nem o próprio caminho de acesso.
Erro C4996 'strcpy': esta função ou variável pode não ser segura. Considere usar strcpy_s em vez disso. Para desativar a descontinuação, use _CRT_SECURE_NO_WARNINGS. Veja a ajuda online para mais detalhes.
Pode até haver grande influência e uma remuneração correspondente elevada, mas isso não pode ser automaticamente equiparado a ser a “única pessoa na empresa a assumir risco ativo”. Dependendo inclusive de quem a escolheu para o cargo, se é ou não o acionista controlador, menos ainda.
Pela mesma lógica, um funcionário teria uma influência menor, portanto assumiria uma responsabilidade menor e receberia um salário menor, mas ainda assim seria um empregado que assume responsabilidade de forma ativa, e também não há motivo para que o CEO não possa ser substituído por IA.
O ponto que você havia deixado no comentário inicial não era que o CEO é a única pessoa que arca com risco ativo e, por isso, não pode ser substituído por IA?
Ah, ao contrário de computadores de uso geral, em MCUs como o ESP32 não há uma MMU que permita alterar em tempo de execução os atributos da memória por página, e se a memória é cacheable ou non-cacheable é definido previamente por região de memória, então realmente não dá para usar da forma que você mencionou (a SRAM interna é fixa como memória non-cacheable, e a PSRAM fica inteiramente fixa como memória cacheable).
Entendi, por causa da consistência de cache que você mencionou, imagino que seria necessário fazer cache invalidate toda vez, então fiquei curioso para saber por que não usar simplesmente uma região não cacheável.
É por isso que dizem hoje em dia que os gurus preferem até dizer que os novatos usam agentes muito melhor. Como isso foi o que lhes deu dinheiro por muito tempo, não conseguem fazer o unlearning.
Recomendo o método de entrada Kime
O método de entrada em coreano era tão inconveniente que eu nem conseguia usar; hoje em dia melhorou bastante? Problemas como no Chrome, em que a digitação falha ou o último caractere é apagado, eram bem sérios.
É uma observação precisa. A taxa de erro humana é ainda maior..
Esse era o jeito como eu trabalhava com código de depuração quando eu estava numa empresa de jogos há 25 anos, e não era só o
strcpy, né. No release, isso voltava a ficar liberado para ganhar desempenho e assim era colocado em produção. Na verdade, no lado de jogos, colisão de memória é uma das coisas mais sensíveis, então o trabalho também era feito com muita cautela e atenção, a ponto de criarmos e usarmos nosso próprio depurador de memória. Mas hoje, olhando para trás, vejo que aquilo estava basicamente criando um garbage collector. Que lembrança nostálgica.Ah, li com bastante interesse. Você disse que a necessidade de validação adicional é determinada com base na confiabilidade; também fiquei curioso para saber como esse valor de confiabilidade foi medido.
Como referência, o modelo gpt-4o-mini tem um custo excessivamente alto de tokens de entrada ao processar imagens, então recomendo considerar também outros modelos leves!
Parece um texto que resolveu bem o problema usando VLM, gostei bastante de ler.
Mas fiquei com uma dúvida ao ler o texto:
Gostaria de saber como vocês incluíram esse processo.
Enquanto eu lia, pensei que o VLM provavelmente teria desempenho melhor que o YOLO; então, ao recortar, não existiria o risco de o modelo YOLO julgar errado e informações importantes se perderem antes mesmo de serem passadas ao VLM?
O que levou vocês a pensar nesse recorte como solução, e como validaram a precisão antes de adotá-lo?
Oh, ficou bem bonito. Seria ótimo se fosse portado para várias linguagens!
Parece que, em vez de resolver ao converter para um problema estrutural, vocês acabaram criando um novo modelo, não é?
Em alguns MCUs de alto desempenho, como você mencionou, é possível usar a MPU para configurar por região não apenas as permissões de acesso, mas também propriedades relacionadas ao cache. O material da ST a seguir é uma boa referência: https://community.st.com/t5/stm32-mcus/…
No entanto, no ESP32-S3 usado neste texto, não é oferecido um mecanismo como o de CPUs de uso geral ou de alguns MCUs, em que os atributos
cacheable/non-cacheablepodem ser configurados por região de memória via MPU ou algo semelhante.No caso do ESP32-S3, a memória externa (Flash/PSRAM) foi projetada para ser acessada por meio do cache/MMU (TRM 4.3.3 External Memory), e o controle de permissões de acesso é feito pelo PMS (Permission Management System) (TRM Capítulo 15), mas esse recurso serve para proteção de acesso e não tem o papel de alterar se o acesso passa pelo cache nem o próprio caminho de acesso.
Link do TRM (Technical Reference Manual): https://documentation.espressif.com/esp32-s3_technical_reference_manua….
Erro C4996
'strcpy': esta função ou variável pode não ser segura. Considere usarstrcpy_sem vez disso. Para desativar a descontinuação, use_CRT_SECURE_NO_WARNINGS. Veja a ajuda online para mais detalhes.Não há MMU, mas é possível definir regiões de memória e suas propriedades com a MPU.
Acho que valeria a pena dar uma olhada.
Pode até haver grande influência e uma remuneração correspondente elevada, mas isso não pode ser automaticamente equiparado a ser a “única pessoa na empresa a assumir risco ativo”. Dependendo inclusive de quem a escolheu para o cargo, se é ou não o acionista controlador, menos ainda.
Pela mesma lógica, um funcionário teria uma influência menor, portanto assumiria uma responsabilidade menor e receberia um salário menor, mas ainda assim seria um empregado que assume responsabilidade de forma ativa, e também não há motivo para que o CEO não possa ser substituído por IA.
O ponto que você havia deixado no comentário inicial não era que o CEO é a única pessoa que arca com risco ativo e, por isso, não pode ser substituído por IA?
Não parece ter muita utilidade...
Ah, ao contrário de computadores de uso geral, em MCUs como o ESP32 não há uma MMU que permita alterar em tempo de execução os atributos da memória por página, e se a memória é
cacheableounon-cacheableé definido previamente por região de memória, então realmente não dá para usar da forma que você mencionou (a SRAM interna é fixa como memórianon-cacheable, e a PSRAM fica inteiramente fixa como memóriacacheable).Obrigado pela ótima pergunta!
Uau, eles realmente estão distribuindo isso... é uma empresa realmente assustadora.
Quando será que essa confusão vai se acalmar, seja de um jeito ou de outro,,
Adorei a indicação dos feriados
> Luck = [Doing Things] × [Telling People]
Acho que já vi essa fórmula alguns anos atrás, mas não consegui colocá-la em prática direito nesse meio-tempo
Entendi, por causa da consistência de cache que você mencionou, imagino que seria necessário fazer
cache invalidatetoda vez, então fiquei curioso para saber por que não usar simplesmente uma região não cacheável.É por isso que dizem hoje em dia que os gurus preferem até dizer que os novatos usam agentes muito melhor. Como isso foi o que lhes deu dinheiro por muito tempo, não conseguem fazer o unlearning.