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

Feature: profiler for equivalent blocks, automatically use fastest #230

Open
ncorgan opened this issue Mar 20, 2021 · 0 comments
Open

Feature: profiler for equivalent blocks, automatically use fastest #230

ncorgan opened this issue Mar 20, 2021 · 0 comments

Comments

@ncorgan
Copy link
Member

ncorgan commented Mar 20, 2021

Either by design or coincidence, there are certain blocks between modules that are meant to be equivalent. Most intentionally, many PothosGPU blocks are specifically designed to be drop-in substitutes for PothosBlocks or PothosComms blocks. There are some cases where, somehow for some ArrayFire functions with very subpar optimizations, the new SIMD implementation somehow ends up being faster, especially if ArrayFire only has the fallback CPU implementation. When gr-pothos blocks come into the picture, who knows? The block_executor overhead isn't as bad as I thought.

My initial thought is, for a given desired functionality, a JSON config with the block registry paths and parameters needed for each block and a tool to run each block one-by-one into a Probe Rate block to determine the most efficient. Once that has been determined, a block is auto-generated (the conf loader would likely come in somewhere) that will automatically use this fastest. This would transparently result in a single block that, per-DType, uses the fastest registered implementation.

@ncorgan ncorgan changed the title Profiler for equivalent blocks, automatically use fastest Feature: profiler for equivalent blocks, automatically use fastest Mar 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant