Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic compute fns #2639

Merged
merged 11 commits into from
Mar 10, 2025
Merged

Dynamic compute fns #2639

merged 11 commits into from
Mar 10, 2025

Conversation

gatesn
Copy link
Contributor

@gatesn gatesn commented Mar 10, 2025

Add the ability to define and dispatch compute at runtime.

Each compute function is now an ArcRef<dyn ComputeFn>, these are no longer hard-coded and can be defined by users.

The entry-point of a compute function can ask an array for a "kernel" for the specific compute function. This allows arrays to provide implementation kernels for any compute function, even those it doesn't have a compile-time dependency on.

It also allows arrays to define dynamic kernels runtime, for example, DictArray can define a single kernel to push-down compute for all element-wise operators.

Copy link

cloudflare-workers-and-pages bot commented Mar 10, 2025

Deploying vortex-bench with  Cloudflare Pages  Cloudflare Pages

Latest commit: 71258c5
Status: ✅  Deploy successful!
Preview URL: https://a07c0cbd.vortex-bench.pages.dev
Branch Preview URL: https://ngates-dyn-compute-fns.vortex-bench.pages.dev

View logs

Copy link

codspeed-hq bot commented Mar 10, 2025

CodSpeed Performance Report

Merging #2639 will improve performances by 13.27%

Comparing ngates/dyn-compute-fns (fcf9858) with develop (583bd23)

Summary

⚡ 1 improvements
✅ 774 untouched benchmarks

Benchmarks breakdown

Benchmark BASE HEAD Change
new_raw_prim_test_between[i32, 2048] 22 µs 19.4 µs +13.27%

@gatesn gatesn enabled auto-merge (squash) March 10, 2025 12:32
Copy link
Member

@robert3005 robert3005 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the overall design is fine, just that default behaviour of find and default kernel is a bit opaque without any comments

const FILTER: Option<KernelRef> = None;

/// Fallback implementation to lookup compute kernels at runtime.
fn _find_kernel(&self, _compute_fn: &dyn ComputeFn) -> Option<KernelRef> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't you want to pass arguments here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh, not sure. Decided against because all kernels return Option<Output>. We may want to add later if a use-case comes up

/// A trait used to register static kernels for known compute functions.
/// Dynamic kernels must be returned via the `_find_kernel` method.
pub trait ArrayComputeImpl {
const FILTER: Option<KernelRef> = None;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't sure I understand how the default is supposed to work. I think you can explain a little bit more about the end state and it could make sense but sans commentary there's some weirdness here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically the Impl things are just short-cuts to make implementing the Array trait easier. These consts allow you to return static lifetime kernels by wrapping up an impl FilterKernel.

The fallback to _find_kernel is in case an array wants to return dynamic kernels (i.e. Arc::new)

// Check each of the known compute functions.

if any.is::<Filter>() {
return <Self as ArrayComputeImpl>::FILTER;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this fallback as well? The default might not be populated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean fall back? To what?

Copy link
Member

@robert3005 robert3005 Mar 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to find_kernel if it's none

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That happens on line 88

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but this returns if the constant is none

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh gotcha, yep good catch

use crate::arcref::ArcRef;
use crate::compute::{ComputeFn, InvocationArgs, Output};

pub trait ComputeFnImpl {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO(ngates): remove this

@gatesn gatesn merged commit 75799e9 into develop Mar 10, 2025
26 of 27 checks passed
@gatesn gatesn deleted the ngates/dyn-compute-fns branch March 10, 2025 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants