Skip to content

AVX2 ggml_vec_dot_q4_0 performance improvement ~5% #768

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

AVX2 ggml_vec_dot_q4_0 performance improvement ~5% #768

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions ggml.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1975,6 +1975,10 @@ static void ggml_vec_dot_q4_0(const int n, float * restrict s, const void * rest

// This loop will be unrolled by the compiler
for (int u=0;u<UNROLL_COUNT;u++) {
// Prefetch data used later in the loop
// TODO these numbers are device dependent shouldn't be hard coded derive
_mm_prefetch ( x[i+u].qs + 32*20, 1); // to-do: document what 32*20 even is
Copy link
Contributor

@sw sw Apr 6, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Yes what even is it? ;-) Is 20 intended to be == sizeof(block_q4_0)?

Or could you use CACHE_LINE_SIZE here somehow?

An interesting experiment would be to pad block_q4_0 by e.g. 4 bytes and see if the optimum prefetch offset moves. That would give a clue that the offset should be a certain multiple of sizeof(block_q4_0), or rather independent of it.


/* Compute combined scale for the block */
const __m256 scale = _mm256_mul_ps(
_mm256_broadcast_ss( &x[i+u].d ),
Expand Down