hivehacks

Inspiration

We needed GPU power for computation, but accessing high-powered GPUs often meant paying for hardware or cloud services. As students working with limited resources and short demo timelines, we wondered whether we could combine the devices we already had.

That idea became HiveHacks, a shared compute cluster where everyday devices contribute processing power, much like bees working together in a hive.

What it does

HiveHacks distributes supported computations across connected devices through their browsers. Compatible phones, tablets, Windows laptops, and Macs can become GPU contributors by opening a link and starting to contribute.

Users upload a workload, the server views its partition analysis, and sends independent chunks to available contributors. The server assigns work using measured device throughput, handles devices joining or leaving, and assembles completed results in order.

Our current modes include:

Custom WGSL: Distribute supported GPU computations, including our Mandelbulb renderer, and download the final output.
Marked Python: Identify supported independent loops and translate them into WGSL for GPU execution and also supports CPU and ONNX.
Animation: Render independent frames or image tiles and assemble them into an animation.

How we built it

We built the interface with React and the backend with Python and FastAPI. A central server coordinates contributors through WebSockets, while WebGPU lets each browser interact with its device’s GPU.

WGSL provides a shared shader language across supported GPU architectures. For supported Python computations, our translator translates restricted operations into WGSL. For the Mandelbulb Python renderer, the backend extracts its embedded shader and configuration without executing the uploaded program.

The server divides work into chunks, assigns them using contributor throughput measurements, and tracks completion. If a contributor disconnects, unfinished work can be reassigned. Returned arrays, image tiles, and frames are placed back into their correct positions.

We also used Cloudflare Tunnel to make the application accessible to contributors on different networks.

Challenges we ran into

WGSL and GPU programming were new to us. Translating Python logic into GPU work required understanding which operations could run independently and which depended on earlier results. We learned quickly that arbitrary Python cannot simply be converted into a shader.

Orchestration was another challenge. Devices have different capabilities, finish work at different times, and can disconnect mid-task. We had to manage assignments, retries, and result ordering while keeping the interface responsive.

Creating realistic test workloads also took more effort than expected. Small examples could prove that computation worked, but meaningful performance tests needed enough work to outweigh dispatch and communication overhead. Image rendering introduced additional challenges around global pixel coordinates, texture layouts, and stitching tiles without seams.

Accomplishments that we're proud of

Getting distributed computation to work across browser contributors was an exciting milestone. Watching separate devices return pieces of a shared result made the original idea tangible.

We’re especially proud that our Mandelbulb renderer works through the upload interface. In our browser checks, the stitched image exactly matched the full-frame reference, including at its default 1280 × 1024 resolution.

We also measured improvements in our CPU experiments, while learning to distinguish those results from GPU scaling that we haven’t measured yet.

Designing the hive-inspired interface was another highlight. We drew the bees and honeycomb ourselves, giving the project a visual identity connected to how its contributors work together.

What we learned

We learned that parallel computing starts with identifying independent work. Adding more devices only helps when a task can be divided safely and the computation is substantial enough to justify communication and coordination.

We also learned that correctness must come before performance. Comparing distributed results against a single-worker reference helped us catch problems with indexing, output ordering, and image boundaries.

Device strength alone does not determine performance. Workload size, transfer overhead, uneven computation, and contributor availability all affect how quickly a job finishes.

Most importantly, we learned to measure our claims. Multiple browser contributors demonstrate coordination, but contributors sharing one physical GPU do not prove multi-GPU speedup. Reliable benchmarks and honest limitations became an essential part of the project.

What's next for hivehacks

Longer term, we’d like to explore additional languages, such as C++, through carefully scoped translation or execution layers. We also want to benchmark across more physical devices and networks to understand where distributed execution provides the greatest benefit.