Skip to content

Cleanup workload directory structure #276

Open

Description

@danleh

Definitely not urgent and only for after the 3.0 release, but it's a bit of a mess right now: Some workloads don't have their own directory (e.g., tfjs-wasm is just inside the wasm/ directory); some Wasm workloads are under wasm/, some are not; and for those workloads in their own directory, the directory doesn't always match the workload name.

Let's:

  • put all workloads under workloads/,
  • put each workload in their own subdirectory, where the directory name matches precisely the workload name (except for those workloads that are closely related or have lots of files in common)
  • don't put Wasm workloads under wasm/ but just next to the JS ones.

Activity

  1. harini9803 commented on Sep 14, 2026

    @harini9803

    I'd like to take this on.

    To confirm my understanding of the plan before I start:

    • Move all workloads under a top-level workloads/ directory
    • Each workload gets its own subdirectory matching its exact registered name in JetStreamDriver.js, except for closely-related ones that share files (e.g. I'm assuming existing multi-benchmark suites like Octane, SunSpider, ARES-6, and RexBench stay as-is, since they're already grouped and share a lot of infrastructure — let me know if that's wrong)
    • Wasm workloads currently loose inside wasm/ (richards, quicksort, gcc-loops, HashSet, tsf, tfjs, etc.) get pulled out into their own subdirectories alongside the JS ones, instead of staying segregated

    Given the size of this, I'll start with a small batch (the loose wasm/ files) as a first PR to validate the approach and path updates in JetStreamDriver.js, then follow up with the rest once that's reviewed. Let me know if that sounds reasonable or if you'd rather see it done differently.

  2. danleh commented on Sep 16, 2026

    @danleh
    ContributorAuthor

    That sounds great, thanks for helping out! We are preparing a 3.1 release soon-ish and would like to land some patches on main, but they would likely conflict with such a reorganization. Would you be able to create a PR of this reorganization in the next ~2-3 weeks, so we can review it? Please don't change any of the workloads materially, this should be a pure cleanup/reorg.

    Let me know if you need more help with this :) Out of curiosity: How did you come about this?

  3. harini9803 commented on Sep 17, 2026

    @harini9803

    That sounds great, thanks for helping out! We are preparing a 3.1 release soon-ish and would like to land some patches on main, but they would likely conflict with such a reorganization. Would you be able to create a PR of this reorganization in the next ~2-3 weeks, so we can review it? Please don't change any of the workloads materially, this should be a pure cleanup/reorg.

    Let me know if you need more help with this :) Out of curiosity: How did you come about this?

    Sounds good, thanks! I'll do the full reorganization as a single PR and aim to have it up well within the 2-3 week window so it doesn't collide with the 3.1 work.

    As for how I came across it: I've worked with browser benchmark suites like Speedometer, JetStream, and MotionMark in some of my own projects, so I'd been wanting to contribute back.

    One thing I'd like to confirm before I start moving files: tfjs currently has its files sitting directly in wasm/ without a directory of its own, and it looks like there may be more than one registered workload sharing that same set of files (e.g. the SIMD and non-SIMD variants). Should those share a single directory, or would you prefer them split? Same question for dotnet, if it covers multiple registered workloads.

  4. danleh commented on Sep 17, 2026

    @danleh
    ContributorAuthor

    Ah, if you can, share the files, so maybe just one folder for such closely related workloads.

  5. harini9803 commented on Sep 20, 2026

    @harini9803

    Ah, if you can, share the files, so maybe just one folder for such closely related workloads.

    @danleh Raised #318 with the full reorganization, as discussed.

    One thing needs you: CI is sitting at action_required since it's my first PR
    here, so the workflows need a maintainer to approve them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions