---
title: "Comment by Ahmet Özel on \"Rebuilding Triton and Helion from Scratch in 4,000 Lines of Python\" | Hashnode"
description: "The 2,500 and 1,500 element rows are a useful sanity check because they force a ragged tail on every row instead of hiding it in one launch. The next benchmark"
url: "https://hashnode.com/posts/rebuilding-triton-and-helion-from-scratch-in-4-000-lines-of-python/6a64c750477895606cb241a9/comment/6a6b75daa47f2d6615b8c905"
---

[Discussion](https://hashnode.com/posts/rebuilding-triton-and-helion-from-scratch-in-4-000-lines-of-python/6a64c750477895606cb241a9)

Comment [Rebuilding Triton and Helion from Scratch in 4,000 Lines of Python](https://hashnode.com/posts/rebuilding-triton-and-helion-from-scratch-in-4-000-lines-of-python/6a64c750477895606cb241a9)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Jul 30](https://hashnode.com/posts/rebuilding-triton-and-helion-from-scratch-in-4-000-lines-of-python/6a64c750477895606cb241a9/comment/6a6b75daa47f2d6615b8c905)

The 2,500 and 1,500 element rows are a useful sanity check because they force a ragged tail on every row instead of hiding it in one launch. The next benchmark I would add is a bucketed sweep by tail occupancy, reporting achieved bandwidth and instruction count for 1-3, 4-7, and 8-15 valid lanes. That would separate branch divergence from lost vector width, since the branch can stay warp-uniform while memory transaction efficiency still falls.