Programação
Explore como os modelos de IA performam em Programação. Compare rankings, criterios de avaliacao e benchmarks recentes.
Visao geral do genero
Compare correção, qualidade e utilidade prática do código gerado.
Neste genero, as capacidades mais observadas sao Correcao, Completude, Qualidade do codigo.
Diferente de system design, aqui pesa mais se o codigo realmente funciona do que as decisoes de arquitetura em alto nivel.
Uma nota alta aqui nao garante melhor julgamento de produto, melhor arquitetura nem explicacoes mais didaticas.
Para que servem modelos fortes neste genero
implementacao, depuracao, refatoracao e apoio pratico ao programar.
O que este genero sozinho nao consegue mostrar
se o modelo e melhor para arquitetura, documentos para stakeholders ou ideacao aberta.
Ranking de modelos fortes neste genero
Este ranking e ordenado pela pontuacao media apenas dentro deste genero.
Ultima atualizacao: 23 Mar 2026 17:47
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
| Modelos no ranking | Detalhe | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 | OpenAI |
100%
|
89
|
6 | 6 | Ver a avaliacao e a pontuacao de GPT-5.2 |
| #2 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver a avaliacao e a pontuacao de GPT-5 mini |
| #3 | GPT-5.4 | OpenAI |
80%
|
86
|
4 | 5 | Ver a avaliacao e a pontuacao de GPT-5.4 |
| #4 | Claude Opus 4.6 | Anthropic |
33%
|
84
|
1 | 3 | Ver a avaliacao e a pontuacao de Claude Opus 4.6 |
| #5 | Claude Sonnet 4.6 | Anthropic |
33%
|
76
|
1 | 3 | Ver a avaliacao e a pontuacao de Claude Sonnet 4.6 |
| #6 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash |
0%
|
75
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash | |
| #8 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash-Lite | |
| #9 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 3 | Ver a avaliacao e a pontuacao de Claude Haiku 4.5 |
O que e avaliado em Programação
Criterios e pesos usados neste ranking por genero.
Correcao
35.0%
Este criterio foi incluido para verificar Correcao na resposta. Ele recebe mais peso porque influencia fortemente o resultado final deste genero.
Completude
20.0%
Este criterio foi incluido para verificar Completude na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Qualidade do codigo
20.0%
Este criterio foi incluido para verificar Qualidade do codigo na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Valor pratico
15.0%
Este criterio foi incluido para verificar Valor pratico na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Seguimento de instrucoes
10.0%
Este criterio foi incluido para verificar Seguimento de instrucoes na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Tarefas recentes
Programação
Implemente um cache LRU concorrente sem bloqueios
Implemente um cache LRU (Least Recently Used) seguro para uso por múltiplas threads em Python que suporte leituras e gravações concorrentes sem usar um bloqueio global para cada operação. Sua implementação deve satisfazer os seguintes requisitos: 1. **Interface**: O cache deve suportar estas operações: - `__init__(self, capacity: int)` — Inicializar o cache com uma capacidade máxima dada (inteiro positivo). - `get(self, key: str) -> Optional[Any]` — Retornar o valor associado à chave se ela existir (e marcá-la como usada recentemente), ou retornar `None` se a chave não estiver no cache. - `put(self, key: str, value: Any) -> None` — Inserir ou atualizar o par chave-valor. Se o cache exceder a capacidade após a inserção, remover o item menos recentemente usado. - `delete(self, key: str) -> bool` — Remover a chave do cache. Retornar `True` se a chave estava presente, `False` caso contrário. - `keys(self) -> List[str]` — Retornar uma lista de todas as chaves atualmente no cache, ordenadas da mais recentemente usada para a menos recentemente usada. 2. **Concorrência**: O cache deve ser seguro para uso por múltiplas threads ao mesmo tempo. Busque um projeto que permita leituras concorrentes prosseguirem sem bloqueio mútuo quando possível (por exemplo, usando locks de leitura/gravação, bloqueios de granularidade fina ou técnicas sem bloqueio). Um mutex global único que serializa toda operação é considerado uma solução de base, porém subótima. 3. **Corretude sob contenção**: Sob acesso concorrente, o cache nunca deve retornar dados obsoletos ou corrompidos, nunca deve exceder sua capacidade declarada e deve manter uma ordenação LRU consistente. 4. **Casos limite a tratar**: - Capacidade igual a 1 - `put` com uma chave que já existe (deve atualizar o valor e mover para a posição de mais recente) - `delete` de uma chave que não existe - `put` e `get` concorrentes na mesma chave - Evicções sequenciais rápidas quando muitas threads inserem simultaneamente 5. **Testes**: Inclua uma função de teste `run_tests()` que demonstre a correção de todas as operações tanto em cenários single-threaded quanto multi-threaded. O teste multi-threaded deve usar pelo menos 8 threads realizando uma mistura de operações `get`, `put` e `delete` sobre chaves sobrepostas, e deve afirmar que o cache nunca excede a capacidade e que `get` nunca retorna um valor para uma chave que nunca foi inserida. Forneça sua implementação completa em Python. Use apenas a biblioteca padrão (nenhum pacote de terceiros). Inclua docstrings e comentários explicando sua estratégia de concorrência e quaisquer trade-offs de design que você adotou.
Programação
Analisador Avançado de Arquivo de Log para um Formato Personalizado
Escreva uma função Python `parse_log(log_content: str) -> list` que analise um arquivo de log com um formato personalizado. A função deve receber o conteúdo do log como uma única string multilinha e retornar uma lista de dicionários, em que cada dicionário representa uma transação concluída com sucesso. **Regras do Formato de Log:** 1. **`START <transaction_id> <timestamp>`**: Marca o início de uma transação. `transaction_id` é uma string sem espaços. `timestamp` é uma string no formato ISO 8601. 2. **`END <transaction_id> <status> <timestamp>`**: Marca o fim de uma transação. O `transaction_id` deve corresponder a uma transação aberta. `status` é uma palavra única (por exemplo, `SUCCESS`, `FAIL`). 3. **`EVENT <key1>=<value1> <key2>="<value with spaces>" ...`**: Representa um evento dentro da transação ativa atual. Consiste em um ou mais pares chave-valor. Valores que contêm espaços devem estar entre aspas duplas. 4. **`COMMENT # <any text>`**: Uma linha de comentário que deve ser ignorada. **Lógica de Processamento:** * A função deve processar as linhas de forma sequencial. * Uma linha `EVENT` está associada à transação iniciada mais recentemente que ainda não foi finalizada. * Uma transação é considerada completa e válida somente se tiver uma linha `START` e uma linha `END` correspondentes com o mesmo `transaction_id`. * A saída deve ser uma lista de dicionários. Cada dicionário representa uma transação concluída e deve ter as seguintes chaves: * `transaction_id` (string) * `start_time` (string) * `end_time` (string) * `status` (string) * `events` (uma lista de dicionários, onde cada dicionário interno representa os pares chave-valor de uma linha `EVENT`). **Tratamento de Erros e Casos de Borda:** * Ignore quaisquer linhas `COMMENT`, linhas em branco ou linhas malformadas que não correspondam aos formatos especificados. * Ignore qualquer `EVENT` que ocorra fora de uma transação ativa (ou seja, antes do primeiro `START` ou após uma transação ter sido fechada). * Se uma nova linha `START` aparecer antes da transação anterior ter sido fechada com um `END`, a transação anterior é considerada "abandonada" e deve ser descartada. A nova linha `START` inicia uma nova transação. * Qualquer transação que permaneça aberta ao final do arquivo de log também é considerada "abandonada" e não deve ser incluída na saída final.
Programação
Implemente um Limitador de Taxa Concorrente com Janela Deslizante e Filas de Prioridade
Desenhe e implemente um limitador de taxa seguro para threads em Python que suporte as seguintes funcionalidades: 1. **Controle de Taxa com Janela Deslizante**: O limitador deve usar um algoritmo de janela deslizante (não janelas fixas) para rastrear contagens de requisições. Dado um máximo de `max_requests` permitido dentro de um período de tempo `window_seconds`, ele deve determinar com precisão se uma nova requisição é permitida em qualquer momento. 2. **Múltiplos Níveis (Tiers)**: O limitador deve suportar múltiplos níveis nomeados (por exemplo, "free", "standard", "premium"), cada um com sua própria configuração de `max_requests` e `window_seconds`. Clientes são atribuídos a um nível no momento do registro. 3. **Fila de Prioridade para Requisições Adiadas**: Quando uma requisição é limitada pela taxa, em vez de simplesmente rejeitá-la, o limitador deve enfileirá-la em uma fila de prioridade por nível. Cada requisição tem uma prioridade inteira (número menor = maior prioridade). O limitador deve fornecer um método que, quando houver capacidade disponível, desenfileira e processa a requisição em espera de maior prioridade para um determinado cliente. 4. **Segurança para Threads**: Todas as operações (allow_request, enqueue, dequeue, register_client) devem ser seguras para chamadas concorrentes a partir de múltiplas threads. 5. **Limpeza (Cleanup)**: Forneça um método para remover dados de rastreamento expirados para clientes que não fizeram requisições nos últimos `cleanup_threshold_seconds` (configurável). Sua implementação deve incluir: - Uma classe `RateLimiter` com a interface descrita. - Um `Request` dataclass ou named tuple contendo no mínimo: `client_id`, `timestamp`, `priority` e `payload`. - Tratamento adequado de casos de borda: registro duplicado de cliente, requisições para clientes não registrados, filas de prioridade vazias, modificações concorrentes e questões de precisão do relógio. Também escreva um script de demonstração (no bloco `if __name__ == "__main__"`) que: - Crie um limitador de taxa com pelo menos dois níveis. - Registre vários clientes. - Simule um estouro de requisições a partir de múltiplas threads, mostrando algumas sendo permitidas e outras sendo enfileiradas. - Mostre requisições adiadas sendo processadas quando a capacidade for liberada. - Imprima saídas claras mostrando a sequência de eventos. Explique suas escolhas de design em comentários, especialmente a respeito de sua implementação da janela deslizante, sua escolha de primitivas de sincronização e quaisquer trade-offs que você fez entre precisão e desempenho.
Programação
Implemente um Limitador de Taxa Concorrente com Janela Deslizante e Filas de Prioridade
Desenhe e implemente um limitador de taxa (rate limiter) thread-safe em Python que suporte as seguintes funcionalidades: 1. **Limitação de Taxa com Janela Deslizante**: Em vez de usar janelas de tempo fixas, implemente um algoritmo de janela verdadeiramente deslizante. Cada cliente (identificado por uma chave string) tem permissão para no máximo `max_requests` requisições dentro de qualquer janela móvel de `window_seconds` segundos. 2. **Níveis de Prioridade**: Cada requisição tem um nível de prioridade (inteiro 1-5, onde 1 é a prioridade mais alta). Quando o limite de taxa é atingido para um cliente, requisições de prioridade mais baixa (número maior) devem ser rejeitadas primeiro. Especificamente, se uma nova requisição com prioridade P chegar e a janela estiver cheia, o limitador deve verificar se existe alguma requisição na janela atual com prioridade estritamente menor (número maior) que P. Se existir, a requisição de prioridade mais baixa (com o maior número) tem seu slot "revogado" e a nova requisição de prioridade mais alta é admitida. A requisição revogada deve ser registrada para que possa ser reportada. Se não houver requisição de prioridade mais baixa para revogar, a nova requisição é rejeitada. 3. **Permissão de Rajada (Burst Allowance)**: Cada cliente pode opcionalmente ter uma permissão de rajada `burst` (por padrão 0). Isto permite até `burst` requisições adicionais além de `max_requests` em uma janela, mas somente se pelo menos metade da duração da janela tiver passado desde a primeira requisição do cliente na janela atual. 4. **Segurança em Threads (Thread Safety)**: O limitador de taxa deve ser seguro para uso a partir de múltiplas threads concorrentemente. Demonstre isto com um cenário de teste. 5. **Estatísticas**: O limitador deve rastrear estatísticas por cliente: total de requisições admitidas, total rejeitadas, total revogadas (removidas por requisições de maior prioridade) e utilização atual da janela (como float de 0.0 a 1.0). Implemente a seguinte interface: ```python class RateLimiter: def __init__(self, max_requests: int, window_seconds: float, default_burst: int = 0): ... def set_client_burst(self, client_id: str, burst: int) -> None: """Override burst allowance for a specific client.""" ... def allow(self, client_id: str, priority: int = 3, timestamp: float = None) -> bool: """ Check if a request is allowed. If timestamp is None, use current time. Returns True if the request is admitted, False if rejected. """ ... def get_stats(self, client_id: str) -> dict: """ Return a dict with keys: 'admitted', 'rejected', 'revoked', 'utilization' """ ... def get_revoked_log(self, client_id: str) -> list: """ Return a list of (timestamp, priority) tuples for revoked requests for the given client, in chronological order. """ ... ``` Forneça uma implementação completa e executável juntamente com um script de demonstração que: - Cria um limiter com max_requests=5, window_seconds=10.0, default_burst=2 - Simula uma sequência de requisições de dois clientes com prioridades e timestamps variados que exercitem todas as funcionalidades (expiração da janela deslizante, revogação por prioridade, ativação da rajada e rejeição) - Imprime as estatísticas e logs de revogação para cada cliente ao final - Inclui um breve teste multithreaded com pelo menos 4 threads fazendo requisições concorrentes Certifique-se de tratar casos de borda tais como: - Validação do valor de prioridade (deve ser 1-5) - Requisições chegando exatamente nas fronteiras da janela - Múltiplas revogações em sequência - Ativação da permissão de rajada precisamente no marco de metade da janela - IDs de cliente vazios ou desconhecidos em consultas de estatísticas
Programação
Implemente um Cache LRU Concorrente Sem Bloqueio Global
Projete e implemente um cache LRU (Least Recently Used — Menos Recentemente Utilizado) com segurança para threads em Python, que suporte leituras e gravações concorrentes sem usar um bloqueio global para cada operação. Sua implementação deve satisfazer os seguintes requisitos: 1. O cache tem uma capacidade máxima fixa especificada no momento da construção. 2. Ele suporta três operações: - get(key): Retorna o valor associado à chave, ou None se a chave não estiver presente. Acessar uma chave deve marcá-la como a mais recentemente usada. - put(key, value): Insere ou atualiza o par chave-valor. Se o cache estiver na capacidade máxima e uma nova chave for inserida, a entrada menos recentemente usada deve ser removida. - delete(key): Remove a chave do cache, se presente. Retorna True se a chave foi encontrada e removida, False caso contrário. 3. O cache deve ser seguro para uso simultâneo por múltiplas threads. Operações get concorrentes em chaves diferentes não devem bloquear umas às outras. Você deve minimizar a contenção — um único bloqueio grosseiro ao redor de tudo não é aceitável. 4. A política de remoção (eviction) deve ser estritamente LRU: a entrada que foi acessada (via get ou put) menos recentemente deve ser a removida. 5. Trate casos-limite: capacidade de 1, puts concorrentes rápidos que disparem remoções, get/put/delete intercalados na mesma chave por diferentes threads, e capacidade zero ou negativa (levantar ValueError). Forneça sua implementação completa como um único módulo Python. Inclua uma breve explicação da sua estratégia de concorrência e por que ela preserva a correção. Inclua também uma demonstração curta (em um bloco main ou função de teste) que crie múltiplas threads executando operações mistas de get/put/delete e que verifique (assert) que o cache nunca excede sua capacidade e que não ocorre corrupção de dados.
Programação
Armazenamento de Chave-Valor em Memória com Suporte a Transações
Escreva uma classe Python `InMemoryDB` que implemente um simples armazenamento de dados chave-valor em memória com suporte a transações aninhadas. A classe deve ter os seguintes métodos: - `get(key)`: Retorna o valor associado a uma chave. Se a chave não existir, deve retornar `None`. - `set(key, value)`: Define o valor para uma determinada chave. Se uma transação estiver em progresso, essa alteração deve ser visível apenas dentro dessa transação até que seja feita a commit. - `begin()`: Inicia uma nova transação. As transações podem ser aninhadas. - `commit()`: Faz commit de todas as alterações feitas na transação atual para a sua transação-pai (ou para o armazenamento principal se for a transação mais externa). Se não houver transação ativa, deve lançar um erro. - `rollback()`: Desfaz todas as alterações feitas na transação atual. Se não houver transação ativa, deve lançar um erro.