// playground
Research Playground
1. Read the baseline code and task info. 2. Write your hypothesis — what to change and why. 3. Click Run and watch the agent iterate: propose, test, measure, revise.
starter tasks (free tier)
solve.c
solve.c (baseline)c
1#include "solve.h"2#include <stdlib.h>3#include <string.h>45// Comparison function for qsort6static int compare_uint32(const void *a, const void *b) {7 uint32_t va = *(const uint32_t *)a;8 uint32_t vb = *(const uint32_t *)b;9 if (va < vb) return -1;10 if (va > vb) return 1;11 return 0;12}1314// Baseline: stdlib qsort on 50M uint32 values15// This is O(n log n) but with high constant factors16// due to comparison function pointer overhead and17// poor cache locality during partitioning.18void radix_sort(uint32_t *data, size_t n) {19 qsort(data, n, sizeof(uint32_t), compare_uint32);20}markdown
What is your core insight?
What specific changes would you make to solve.c?
What improvement do you expect on runtime?
guiding questions
- 1.Why is qsort slow for 50M integers despite being O(n log n)?
- 2.How many passes does an LSD radix sort need for 32-bit keys?
- 3.What radix (bits per pass) minimizes total cache misses?
- 4.How can you avoid branch mispredictions in the counting step?
solve.c (baseline)c
1#include "solve.h"2#include <stdlib.h>3#include <string.h>45// Comparison function for qsort6static int compare_uint32(const void *a, const void *b) {7 uint32_t va = *(const uint32_t *)a;8 uint32_t vb = *(const uint32_t *)b;9 if (va < vb) return -1;10 if (va > vb) return 1;11 return 0;12}1314// Baseline: stdlib qsort on 50M uint32 values15// This is O(n log n) but with high constant factors16// due to comparison function pointer overhead and17// poor cache locality during partitioning.18void radix_sort(uint32_t *data, size_t n) {19 qsort(data, n, sizeof(uint32_t), compare_uint32);20}Free tier uses Haiku 4.5. Select a different model and bring your own API key for stronger results.