You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
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.
Activity
harini9803 commentedon Sep 14, 2026
I'd like to take this on.
To confirm my understanding of the plan before I start:
workloads/directorywasm/(richards, quicksort, gcc-loops, HashSet, tsf, tfjs, etc.) get pulled out into their own subdirectories alongside the JS ones, instead of staying segregatedGiven 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.danleh commentedon Sep 16, 2026
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?
harini9803 commentedon Sep 17, 2026
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:
tfjscurrently has its files sitting directly inwasm/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 fordotnet, if it covers multiple registered workloads.danleh commentedon Sep 17, 2026
Ah, if you can, share the files, so maybe just one folder for such closely related workloads.
harini9803 commentedon Sep 20, 2026
@danleh Raised #318 with the full reorganization, as discussed.
One thing needs you: CI is sitting at
action_requiredsince it's my first PRhere, so the workflows need a maintainer to approve them.