Programmierung
Vergleicht Korrektheit, Qualität und Praxistauglichkeit des erzeugten Codes.
In diesem Genre werden vor allem Faehigkeiten wie Korrektheit, Vollstandigkeit, Codequalitat betrachtet.
Anders als system design geht es hier staerker darum, ob der Code wirklich funktioniert als um Architekturentscheidungen auf hohem Niveau.
Ein hoher Wert hier garantiert weder besseres Produkturteil noch bessere Architektur oder bessere Erklaerungen fuer Einsteiger.
Wofuer starke Modelle in diesem Genre gut geeignet sind
Implementierung, Debugging, Refactoring und praktische Programmierunterstuetzung.
Was dieses Genre allein nicht zeigen kann
ob das Modell besser fuer Architektur, Stakeholder-Dokumente oder offene Ideation geeignet ist.
Programmierung: Die GPT-5-Familie dominiert die Spitze, meist auf dünner Stichprobe
OpenAI
OpenAI
OpenAI
Durchschnittswert je Modell
Gewichtung
Über 32 bewertete Coding-Antworten stammen die ersten drei Plätze allesamt aus der GPT-5-Familie. GPT-5.5 steht mit einem Schnitt von 8,85 und makelloser Bilanz auf Platz 1, doch das beruht auf einer einzigen Stichprobe und ist eher als vielversprechendes Signal denn als gesichertes Ergebnis zu lesen. Das am besten belegte Spitzenergebnis liefert GPT-5 mini auf Platz 2: 8,22 über 5 Stichproben, 5 erste Plätze und 100 % Siegquote – ein klarer Durchmarsch zu Kosten der leichten Klasse.
Durchschnitt und Rang weichen voneinander ab, weil die Siegquote (direkte erste Plätze) das Ranking stärker bestimmt als der reine Schnitt. GPT-5.4 erreicht 8,41 über 8 Stichproben, die größte Evidenzbasis hier, mit 75 % Siegquote und Platz 3. Gemini 2.5 Pro erzielt denselben Schnitt von 8,41, liegt aber nur auf Platz 5, weil es keines seiner 3 Duelle gewann. Wer absolute Qualität höher gewichtet als das direkte Duell, sieht GPT-5.4 und Gemini 2.5 Pro näher beieinander, als die Ränge nahelegen.
Das Mittelfeld führt Claude Sonnet 4.6 (Schnitt 7,7, 50 % über 4 Stichproben) an, rund 0,5 bis 1,1 Punkte hinter der GPT-5-Gruppe. Die leichteren, schnelleren Klassen liegen tiefer: Gemini 2.5 Flash (7,31), Flash-Lite (7,17) und Claude Haiku 4.5 (6,48) liegen 1,5 bis 2,4 Punkte hinter dem Spitzenreiter. Da Korrektheit mit 35 am höchsten gewichtet ist, vor Codequalität und Vollständigkeit (je 20), deuten diese Abstände auf schwächere Korrektheit bei den schwereren Aufgaben hin, nicht bloß auf Stil.
Der größte Vorbehalt ist die Stichprobengröße. GPT-5.5 beruht auf 1 Stichprobe, die meisten liegen bei 3 bis 8, sodass die Schnitte mit wenigen Prompts schwanken können. Die Spanne von 2,37 Punkten zwischen Erstem und Letztem ist real, doch die Feinordnung innerhalb des 8-Punkte-Clusters (GPT-5.5, GPT-5.4, GPT-5 mini, Gemini 2.5 Pro) ist als vorläufig zu lesen. Es sind bedingungsabhängige Messwerte, kein Urteil darüber, welches Modell insgesamt am besten programmiert.
Fazit
Für verlässliches Programmieren heute ist GPT-5 mini die am besten begründbare Wahl (100 % Siegquote über 5 Stichproben zu Kosten der leichten Klasse), während GPT-5.4 die am gründlichsten belegte Oberklasse-Option ist (8,41 über 8 Stichproben). Behandle den Ein-Stichproben-Vorsprung von GPT-5.5 als vielversprechend, aber unbewiesen.
Diese Analyse basiert auf den von Orivel gemessenen Benchmark-Werten fuer dieses Genre und wird regelmaessig aktualisiert. Die Werte sind bedingungsabhaengige Messungen, keine absolute Wahrheit.
Ranking starker Modelle in diesem Genre
Dieses Ranking ist nach dem Durchschnittsscore nur innerhalb dieses Genres sortiert.
Zuletzt aktualisiert: 12 Jun 2026 09:39
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
| Gerankte Modelle | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Bewertung und Punktzahl von GPT-5 mini ansehen |
| #2 | GPT-5.4 | OpenAI |
75%
|
84
|
6 | 8 | Bewertung und Punktzahl von GPT-5.4 ansehen |
| #3 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Bewertung und Punktzahl von GPT-5.5 ansehen |
| #4 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Bewertung und Punktzahl von Claude Sonnet 4.6 ansehen |
| #5 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Bewertung und Punktzahl von Gemini 2.5 Pro ansehen | |
| #6 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Bewertung und Punktzahl von Gemini 2.5 Flash ansehen | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Bewertung und Punktzahl von Gemini 2.5 Flash-Lite ansehen | |
| #8 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Bewertung und Punktzahl von Claude Haiku 4.5 ansehen |
Was in Programmierung bewertet wird
Kriterien und Gewichte fuer dieses Genre-Ranking.
Korrektheit
35.0%
Dieses Kriterium ist enthalten, um Korrektheit in der Antwort zu pruefen. Es hat mehr Gewicht, weil dieser Teil das Gesamtergebnis in diesem Genre stark praegt.
Vollstandigkeit
20.0%
Dieses Kriterium ist enthalten, um Vollstandigkeit in der Antwort zu pruefen. Es hat ein klares Gewicht, weil es die Qualitaet sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Codequalitat
20.0%
Dieses Kriterium ist enthalten, um Codequalitat in der Antwort zu pruefen. Es hat ein klares Gewicht, weil es die Qualitaet sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Praktischer Nutzen
15.0%
Dieses Kriterium ist enthalten, um Praktischer Nutzen in der Antwort zu pruefen. Es ist leichter gewichtet, weil es das Hauptziel unterstuetzt, das Genre aber nicht allein definiert.
Befolgung der Anweisungen
10.0%
Dieses Kriterium ist enthalten, um Befolgung der Anweisungen in der Antwort zu pruefen. Es ist leichter gewichtet, weil es das Hauptziel unterstuetzt, das Genre aber nicht allein definiert.
Aktuelle Aufgaben
Programmierung
Implementieren Sie einen auf Abhängigkeiten basierenden Aufgabenplaner in Python
Schreiben Sie eine Python-Funktion oder -Klasse, die eine Liste von Aufgaben basierend auf ihren Abhängigkeiten plant. Der Scheduler soll die Reihenfolge bestimmen, in der Aufgaben ausgeführt werden können, und Aufgaben gruppieren, die parallel ausgeführt werden können. Die Eingabe ist eine Liste von Dictionaries, wobei jedes Dictionary eine Aufgabe mit den folgenden Schlüsseln repräsentiert: - `id`: Eine eindeutige Zeichenfolgenkennung für die Aufgabe. - `name`: Ein String-Name für die Aufgabe. - `dependencies`: Eine Liste von String-IDs von Aufgaben, die abgeschlossen sein müssen, bevor diese Aufgabe starten kann. Ihre Implementierung sollte: 1. Die Liste der Aufgaben-Dictionaries als Eingabe entgegennehmen. 2. Einen gültigen Ausführungsplan als Liste von Listen zurückgeben. Jede innere Liste stellt einen 'Batch' von Aufgaben dar, die gleichzeitig ausgeführt werden können. Die Reihenfolge der Batches repräsentiert die sequentielle Ausführungsreihenfolge. Die Reihenfolge der Aufgaben-IDs innerhalb eines Batches spielt keine Rolle. 3. Zirkuläre Abhängigkeiten erkennen und behandeln. Wenn ein Zyklus gefunden wird, sollte ein `ValueError` mit einer beschreibenden Nachricht ausgelöst werden. 4. Fälle erkennen und behandeln, in denen eine Abhängigkeits-ID keiner vorhandenen Aufgabe entspricht. Dies sollte ebenfalls einen `ValueError` auslösen.
Programmierung
Ratenbegrenzer mit gleitendem Fenster und Burst-Zulassung
Entwerfen und implementieren Sie einen threadsicheren Ratenbegrenzer in einer Sprache Ihrer Wahl (Python, Go, Java, TypeScript oder Rust), der die folgenden Anforderungen unterstützt: 1. **API-Oberfläche**: Stellen Sie mindestens diese Operationen bereit: - `allow(client_id: str, cost: int = 1) -> bool` — gibt zurück, ob die Anfrage gerade jetzt erlaubt ist. - `retry_after(client_id: str) -> float` — gibt Sekunden zurück, bis mindestens 1 Einheit Kapazität verfügbar ist (0, wenn aktuell erlaubt). - Ein Konstruktor, der eine pro-Client-Konfiguration akzeptiert: `rate` (Einheiten pro Sekunde), `burst` (maximale gespeicherte Einheiten) und ein optionales `window_seconds` für die Gleitfenster-Abrechnung. 2. **Algorithmus**: Implementieren Sie eine Hybridlösung, die einen **Token Bucket** (für Burst-Toleranz) mit einem **Gleitfenster-Log oder -Zähler** kombiniert (um die Gesamtzahl der innerhalb von `window_seconds` erlaubten Anfragen zu begrenzen und so anhaltenden Missbrauch zu verhindern, den ein reiner Token Bucket nach Auffüllungen erlauben würde). Eine Anfrage ist nur dann erlaubt, wenn beide Prüfungen bestehen. Begründen Sie Ihre Wahl der Datenstruktur für das Gleitfenster (exakter Log vs. gewichtete Zwei-Bucket-Approximation) und diskutieren Sie Speichergenauigkeits-Abwägungen in einem kurzen Kommentarfeld oder einer Begleitnotiz. 3. **Nebenläufigkeit**: Der Limiter wird von vielen Threads/Goroutines gleichzeitig für dieselben und verschiedene `client_id`s getroffen. Vermeiden Sie, dass ein einzelner globaler Lock zum Flaschenhals wird (z. B. per-Client-Locks oder Lock-Striping). Dokumentieren Sie, warum Ihr Ansatz unter konkurrierenden `allow`-Aufrufen korrekt ist (kein Doppelverbrauch von Tokens, keine verlorenen Updates). 4. **Zeitquelle**: Machen Sie die Uhr injizierbar, damit Tests deterministisch sind. Verwenden Sie standardmäßig eine monotonische Uhr. 5. **Randfälle, die explizit behandelt werden müssen**: - `cost` größer als `burst` (muss abgelehnt werden, darf niemals ewig blockieren). - Uhr geht rückwärts oder große Pausen (z. B. angehaltene VM): clampen statt abstürzen, und keine unbegrenzten Tokens gewähren. - Erste Anfrage für einen neuen Client (Lazy-Initialisierung). - Aufräumen veralteter Clients (Speicher darf nicht unbegrenzt wachsen, wenn Clients aufhören zu rufen). - Bruchteilige Tokens / sub-millisekunden Timing. 6. **Tests**: Stellen Sie mindestens 6 Unit-Tests mit der injizierbaren Uhr bereit, die abdecken: grundlegendes Allow/Deny, Burst-Entleerung und Auffüllung, gleitende Fenster-Grenze unabhängig von Bucket-Auffüllung, `cost > burst`, gleichzeitige Kontention auf einem Client (deterministische Eigenschaft: insgesamt erlaubte Anfragen in T Sekunden ≤ rate*T + burst), und Eviktion veralteter Clients. 7. **Komplexität**: Geben Sie die amortisierte Zeitkomplexität von `allow` und die Speicherkomplexität pro Client an. Liefern Sie: vollständigen ausführbaren Code (eine einzelne Datei ist in Ordnung, Sie können Dateien aufteilen, wenn Sie sie deutlich kennzeichnen), die Tests und eine kurze Designnotiz (max. ~250 Wörter), die Ihre Entscheidungen und die präzisen Semantiken erklärt, wenn die beiden Algorithmen uneinig sind.
Programmierung
Markdown-Subset-zu-HTML-Konverter
Schreiben Sie eine Python-Funktion `markdown_to_html(markdown_text: str) -> str`, die einen String, der eine bestimmte Teilmenge von Markdown enthält, in die entsprechende HTML-Darstellung konvertiert. Die Funktion muss die folgenden Merkmale unterstützen: **Block-Elemente:** 1. **Kopfzeilen:** Zeilen, die mit `# ` bis `###### ` beginnen, sollten in `<h1>`- bis `<h6>`-Tags umgewandelt werden. 2. **Ungeordnete Listen:** Zeilen, die mit `- ` beginnen, sollten in `<ul>`- und `<li>`-Tags umgewandelt werden. Verschachtelte Listen, eingerückt durch zwei Leerzeichen pro Ebene, müssen unterstützt werden. Eine Liste endet durch eine Leerzeile oder ein anderes Block-Element. 3. **Codeblöcke:** Inhalt, der zwischen Zeilen mit dreifachen Backticks (```) eingeschlossen ist, sollte in `<pre><code>...</code></pre>` umgewandelt werden. Der Sprachbezeichner in den öffnenden Backticks (z. B. ```python) sollte ignoriert werden. Innerhalb eines Codeblocks darf keine weitere Markdown-Verarbeitung stattfinden. 4. **Absätze:** Jeder andere Text sollte in `<p>`-Tags eingeschlossen werden. Aufeinanderfolgende Textzeilen gehören zum gleichen Absatz. Absätze werden durch eine oder mehrere Leerzeilen getrennt. **Inline-Elemente:** 1. **Fett & Kursiv:** `***text***` sollte in `<strong><em>text</em></strong>` umgewandelt werden. 2. **Fett:** `**text**` sollte in `<strong>text</strong>` umgewandelt werden. 3. **Kursiv:** `*text*` sollte in `<em>text</em>` umgewandelt werden. **Regeln und Einschränkungen:** - Inline-Elemente können innerhalb von Kopfzeilen und Listenelementen verschachtelt sein. - Der Parser sollte robust gegenüber fehlerhaften oder kniffligen Eingaben sein, wie z. B. nicht geschlossenen Inline-Tags. Zum Beispiel sollte `*italic` als `<p>*italic</p>` gerendert werden. - Die Prioritätsreihenfolge für Inline-Elemente ist `***`, dann `**`, dann `*`. - Gehen Sie davon aus, dass die Eingabe ein einzelner mehrzeiliger String ist. - Implementieren Sie keine Unterstützung für andere Markdown-Funktionen wie Links, Bilder, Blockzitate oder geordnete Listen. - Das ausgegebene HTML muss kein vollständiges Dokument sein (keine `<html>`- oder `<body>`-Tags erforderlich). **Beispiel-Eingabe:** ```markdown # Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ```
Programmierung
Implementieren Sie einen threadsicheren Token-Bucket-Rate-Limiter in Python
Schreiben Sie eine Python-Klasse mit dem Namen `TokenBucketRateLimiter`, die den Token-Bucket-Algorithmus zur Ratenbegrenzung implementiert. Die Implementierung muss threadsicher sein und darf keine externen Bibliotheken zur Zustandsverwaltung (wie Redis) verwenden. Die Klasse sollte folgende Spezifikationen haben: 1. Eine `__init__(self, capacity, refill_rate)`-Methode: * `capacity`: Die maximale Anzahl von Tokens, die der Bucket halten kann. * `refill_rate`: Die Anzahl von Tokens, die pro Sekunde dem Bucket hinzugefügt werden. 2. Eine `consume(self, tokens)`-Methode: * Diese Methode versucht, eine gegebene Anzahl von `tokens` aus dem Bucket zu verbrauchen. * Sie sollte `True` zurückgeben, wenn die Tokens erfolgreich verbraucht werden können, und `False` sonst. * Der Bucket sollte vor dem Versuch, Tokens zu verbrauchen, basierend auf der seit dem letzten Aufruf verstrichenen Zeit mit Tokens aufgefüllt werden. 3. Thread-Sicherheit: * Die Klasse muss sicher in mehreren gleichzeitig laufenden Threads verwendet werden können. Alle Operationen, die den Zustand des Buckets ändern (wie Auffüllen und Verbrauch von Tokens), müssen atomar sein. Geben Sie die vollständige Klassenimplementierung mit den notwendigen Imports an.
Programmierung
Kommandozeilen-Tool zur Dateisynchronisation
Schreiben Sie ein Python-Skript für ein Kommandozeilen-Tool zur Dateisynchronisation. Das Skript muss drei Kommandozeilenargumente akzeptieren: 1. `source_path`: Der Pfad zum Quellverzeichnis. 2. `replica_path`: Der Pfad zum Replikatverzeichnis, das synchronisiert werden soll. 3. `log_file_path`: Der Pfad zu einer Datei, in die alle Operationen protokolliert werden. Kernfunktionalität: 1. **Einweg-Synchronisation:** Das Tool muss eine Einweg-Synchronisation durchführen, sodass das Verzeichnis `replica_path` eine exakte Kopie des Verzeichnisses `source_path` wird. - Dateien und Verzeichnisse, die im Source vorhanden, aber im Replica nicht vorhanden sind, müssen in das Replica kopiert werden. - Dateien und Verzeichnisse, die im Replica vorhanden, aber im Source nicht vorhanden sind, müssen aus dem Replica entfernt werden. - Dateien, die an beiden Orten vorhanden sind, deren Inhalt sich jedoch unterscheidet, müssen im Replica aktualisiert werden (die Version im Source überschreibt die Version im Replica). 2. **Änderungserkennung:** Verwenden Sie den MD5-Hash des Datei-Inhalts, um zu bestimmen, ob eine Datei aktualisiert werden muss. Verlassen Sie sich nicht auf Änderungszeitstempel. 3. **Protokollierung:** Protokollieren Sie alle Dateioperationen (z. B. "KOPIEREN file.txt", "ENTFERNEN old_dir", "AKTUALISIEREN changed.log") sowohl in der Konsole als auch in der angegebenen Protokolldatei. Jeder Protokolleintrag sollte mit einem Zeitstempel versehen sein. 4. **Ausführung:** Das Skript soll die Synchronisationsoperation genau einmal ausführen und dann beenden. Es darf nicht in einer Schleife laufen. Anforderungen: - Verwenden Sie Python 3. - Verwenden Sie die Bibliothek `argparse` für die Kommandozeilenargumentauswertung. - Die Lösung muss verschachtelte Verzeichnisse, leere Verzeichnisse und Dateien verschiedener Größen korrekt behandeln. - Das Skript sollte eine einzelne, eigenständige Datei sein.
Programmierung
Implementiere einen sperrfreien konkurrierenden LRU-Cache
Implementiere einen threadsicheren LRU (Least Recently Used) Cache in Python, der gleichzeitig Lese- und Schreibzugriffe unterstützt, ohne für jede Operation einen globalen Lock zu verwenden. Deine Implementierung muss die folgenden Anforderungen erfüllen: 1. **Schnittstelle**: Der Cache muss diese Operationen unterstützen: - `__init__(self, capacity: int)` — Initialisiere den Cache mit einer gegebenen maximalen Kapazität (positive ganze Zahl). - `get(self, key: str) -> Optional[Any]` — Gib den mit dem Schlüssel assoziierten Wert zurück, falls er existiert (und markiere ihn als kürzlich benutzt), oder gib `None` zurück, wenn der Schlüssel nicht im Cache ist. - `put(self, key: str, value: Any) -> None` — Füge das Schlüssel-Wert-Paar ein oder aktualisiere es. Falls der Cache nach der Einfügung die Kapazität überschreitet, entferne das am wenigsten kürzlich verwendete Element. - `delete(self, key: str) -> bool` — Entferne den Schlüssel aus dem Cache. Gib `True` zurück, wenn der Schlüssel vorhanden war, sonst `False`. - `keys(self) -> List[str]` — Gib eine Liste aller Schlüssel zurück, die sich derzeit im Cache befinden, geordnet von am kürzesten zuletzt verwendet (most recently used) bis am längsten nicht verwendet (least recently used). 2. **Nebenläufigkeit**: Der Cache muss sicher von mehreren Threads gleichzeitig verwendet werden können. Ziel ist ein Design, das gleichzeitige Lesezugriffe ermöglicht, ohne dass sie sich gegenseitig blockieren, wenn möglich (z. B. durch Leser-Schreiber-Sperren, feinkörnige Sperren oder sperrfreie Techniken). Ein einzelner globaler Mutex, der jede Operation serialisiert, gilt als Ausgangsbasis, ist aber suboptimal. 3. **Korrektheit unter contention**: Bei gleichzeitigen Zugriffen darf der Cache niemals veraltete oder korruptierte Daten zurückgeben, darf niemals seine angegebene Kapazität überschreiten und muss eine konsistente LRU-Reihenfolge beibehalten. 4. **Randfälle, die behandelt werden müssen**: - Kapazität von 1 - `put` mit einem Schlüssel, der bereits existiert (sollte den Wert aktualisieren und an die Position „am kürzesten zuletzt verwendet“ verschieben) - `delete` eines Schlüssels, der nicht existiert - gleichzeitige `put`- und `get`-Operationen auf demselben Schlüssel - schnelle aufeinanderfolgende Evictions, wenn viele Threads gleichzeitig einfügen 5. **Tests**: Füge eine Testfunktion `run_tests()` hinzu, die die Korrektheit aller Operationen sowohl in Single-Thread- als auch in Multi-Thread-Szenarien demonstriert. Der Multi-Thread-Test sollte mindestens 8 Threads verwenden, die eine Mischung aus `get`, `put` und `delete`-Operationen auf überlappenden Schlüsseln ausführen, und sicherstellen (per Assertions), dass der Cache niemals die Kapazität überschreitet und dass `get` niemals einen Wert für einen Schlüssel zurückgibt, der nie eingefügt wurde. Gib deine vollständige Implementierung in Python an. Verwende nur die Standardbibliothek (keine Drittanbieter-Pakete). Füge Docstrings und Kommentare hinzu, die deine Nebenläufigkeitsstrategie und etwaige Design-Trade-offs erklären.