No description
Find a file
Soham Jog 4cc72e8e4d
nvfp4 gemv (#59)
* NVFP4 GEMV

* statement edits

---------

Co-authored-by: sarthak <sarthak.robo@gmail.com>
2026-03-03 18:42:10 -05:00
.github/workflows stupid mistake 2025-03-26 21:25:53 -04:00
prisma add nvfp4 quantization (#54) 2026-02-22 23:18:42 -05:00
problems nvfp4 gemv (#59) 2026-03-03 18:42:10 -05:00
staging phasing out [VAR] (#53) 2026-02-20 03:17:22 -05:00
.env.example compiler baselines (#16) 2025-07-06 02:53:53 -04:00
.gitignore Init 2025-03-07 02:26:04 +05:30
baselineBenchmark.ts compiler baselines (#16) 2025-07-06 02:53:53 -04:00
package.json prisma pls fix 2025-09-23 23:15:56 -04:00
pnpm-lock.yaml prisma pls fix 2025-09-23 23:15:56 -04:00
README.md Fix URL in get_flops documentation 2026-01-12 09:47:41 -05:00
sync-baselines.ts compiler baselines (#16) 2025-07-06 02:53:53 -04:00
sync-problems.ts add nvfp4 quantization (#54) 2026-02-22 23:18:42 -05:00

Problems

This repository contains problems hosted on Tensara. Our immediate goal is to port over all KernelBench Level 1 and 2 challenges.

Local Setup

Use the same database URL from the initial setup of the original repository. Create an .env file and add the following:

DATABASE_URL="<your database url>"

Then, you can run:

pnpm i
pnpm prisma generate
pnpm sync-problems

This will take contents from the problems/ folder and sync it with the database. You should be able to see the changes in your local instance of Tensara if you're running one.

Adding a Problem

A problem is defined by two files def.py and problem.md:

The def.py file is extended from the problems class and requires:

  • reference_solution: this is treated as the correct implementation of the problem, and each submission is checked against this function. We recommend using pre-defined PyTorch functions when possible (with autocasting disabled), but CUDA reference solutions are also possible.
  • generate_test_cases: returns a set of test cases that will be used to validate submissions.
  • verify_result: implement logic to check whether the output of a submission matches the expected result. This is flexible -- you can include comparisons for numerical values or verify algorithmically.
  • get_function_signature: return argtypes based on ctypes.
  • get_flops: get the number of FLOPs as a function of the testcase size. Relevant for benchmarking submissions. TODO: Get generalized FLOP counting?
  • get_extra_params: (soon to be phased out) returns function parameters not used by reference_solution.

The problem.md file should contain a description of the problem written in Markdown (LaTeX supported!). The YAML Front Matter should contain:

  • slug
  • title
  • difficulty: EASY, MEDIUM, or HARD
  • author
  • tags (soon to be cleaned up!)
  • parameters
    • name
    • type: [VAR] if it's dependent on what dtype the problem is configured for, otherwise the C++ type
    • pointer: boolean
    • const: boolean

Once you add a problem, make sure to test both correct (slow/fast) and incorrect submissions. Let us know if you encounter any issues/bugs!