boostorg / boostorg/compute

meta_kernel::compile is very slow, even for cached source

Open
#768 7 comments 1 reaction 0 assignees View on GitHub
design performance
Dominant language
C++
Stars
1.7k
Forks
340
PR merge metrics
No merged PRs in 30d

Description

Hi,

I am currently benchmarking the overhead of boost::compute. My test-program is computing nothing big and the equivalent cpu program finishes in no measurable runtime. The OpenCL version takes several seconds, so i decided to check with valgrind-callgrind where this time is lost. My program utilizes 11 different kernels and the runtime is the Intel OpenCL cpu implementation. I am using callgrind with O1 optimizations.

71% of total run-time is spent in 8149 calls to meta_kernel::compile.
Inside, we have over all 8149 calls:
total-runtime% function
43.21% clCreateKernel
14.5% compute::detail::sha1::sha1
8.7% program::build_with_source

As a sanity check:
1.6% meta_kernel::source
1.2% clEnqueueNDRangeKernel

so, roughly 58% of total running time is spent on figuring out whether the program is already build and creating the kernel afterwards. Compiling and caching works fine, we have exactly 11 calls to build_with_source.

The problem is that compute assumes that kernels are throw-away objects. This is unfortunately not the case. e.g. on NVIDIA, clCreateKernel is reported to have an overhead of roughly 1ms. My runtime seems to be in the same order. The programs built with meta_kernel have only one kernel function, so one easy workaround would be to cache the kernel together with the program.

Also, sha1 is terribly slow. The hash function should not take an order of magnitude longer than creating the source in the first place.

Contributor guide

Open the contributing guide

Research direction

Start by profiling meta_kernel::compile and its reported calls to clCreateKernel, sha1, and program::build_with_source; the issue names no source files or tests. Determine how cached programs still incur repeated kernel creation and hashing, then benchmark that cached path to confirm substantially lower overhead without losing the existing build caching.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
performance
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.