Исправление www_linux_org_ru, (текущая версия) :
Что-то я потерялся. В каком случае размер cache является неизвестным? Даже в случае, когда один и тут же CPU выпускается с разным размером cache, всегда есть способ определить размер. Да и компилятор обычно имеет опцию указания размера cache (для кросс-компиляции) или определяет размер сам для native кода.
я полагал, что там слово «известно» означает «статически известно», поскольку речь шла о компиляторе
ок, чуть более подробно: если в hpc, кмк, в определенных случаях можно считать размер кэша известным уже во время компиляции — если есть возможность пересобирать программу для разных размеров кэша), то для программы, поставляемой обычному пользователю, такой возможности нет
хотя и остается возможность иметь несколько разных dll/so или даже просто разных функций, вызываемых для разных размеров кэша и разных размеров массива, это не самый лучший вариант, т.к. нам придется иметь m*n вариантов для m разных размеров кэша и n разных размеров массива
далее мысль была в том, что вместо m*n вариантов можно было бы ограничиться небольшим числом вариантов, скажем 5-ю, для нескольких разных отношений «размер_массива разделить на размер_кэша», что уже намного лучше (хотя в данном случае m*n тоже реалистично, но в случае необходимости учитывать при оптимизации еще какие-либо варианты может произойти комбинаторный взрыв, что плохо — btw afaik именно комбинаторным взрывом и оправдывают применение jit)
наконец, компилятор мог бы под воздействием определенной прагмы сам генерить 5 вариантов цикла, каждый из которых оптимизирован под соответствующее отношение «размер_массива разделить на размер_кэша», и в этом я не вижу ничего суперсложного
Исходная версия www_linux_org_ru, :
Что-то я потерялся. В каком случае размер cache является неизвестным? Даже в случае, когда один и тут же CPU выпускается с разным размером cache, всегда есть способ определить размер. Да и компилятор обычно имеет опцию указания размера cache (для кросс-компиляции) или определяет размер сам для native кода.
я полагал, что там слово «известно» означается «статически известно», поскольку речь шла о компиляторе
ок, чуть более подробно: если в hpc, кмк, в определенных случаях можно считать размер кэша известным уже во время компиляции — если есть возможность пересобирать программу для разных размеров кэша), то для программы, поставляемой обычному пользователю, такой возможности нет
хотя и остается возможность иметь несколько разных dll/so или даже просто разных функций, вызываемых для разных размеров кэша и разных размеров массива, это не самый лучший вариант, т.к. нам придется иметь m*n вариантов для m разных размеров кэша и n разных размеров массива
далее мысль была в том, что вместо m*n вариантов можно было бы ограничиться небольшим числом вариантов, скажем 5-ю, для нескольких разных отношений «размер_массива разделить на размер_кэша», что уже намного лучше (хотя в данном случае m*n тоже реалистично, но в случае необходимости учитывать при оптимизации еще какие-либо варианты может произойти комбинаторный взрыв, что плохо — btw afaik именно комбинаторным взрывом и оправдывают применение jit)
наконец, компилятор мог бы под воздействием определенной прагмы сам генерить 5 вариантов цикла, каждый из которых оптимизирован под соответствующее отношение «размер_массива разделить на размер_кэша», и в этом я не вижу ничего суперсложного