Интересно — есть ли хоть какие-то подвижки в автоматическом распараллеливании и синхронизации многопоточного доступа к разделяемым переменным?

CM>Интересно — есть ли хоть какие-то подвижки в автоматическом распараллеливании и синхронизации многопоточного доступа к разделяемым переменным?
Например, если твоя задача делается по паттерну "Читатели-писатели", то такое можно заавтоматизировать,
описав неким образом инфраструктуру данных твоей задачи.
В общем виде задача не решаема — теорема есть (аналог останова), что невозможно определить, распараллеливается ли задача или нет.

Здравствуйте, LaptevVV, Вы писали:

CM>>Интересно — есть ли хоть какие-то подвижки в автоматическом распараллеливании и синхронизации многопоточного доступа к разделяемым переменным?
LVV>Например, если твоя задача делается по паттерну "Читатели-писатели", то такое можно заавтоматизировать,
LVV>описав неким образом инфраструктуру данных твоей задачи.
LVV>В общем виде задача не решаема — теорема есть (аналог останова), что невозможно определить, распараллеливается ли задача или нет.

Я мало разбираюсь в теме, и прошу помочь. Если я правильно понял, код, генерируемый на Delphi XE8, на многоядерных компьютерах загружает только одно ядро. Это вообще тоскливо и обидно.
Мне с моей дилетантской точки зрения кажется, что для решения этой задачи нужно в ЯП добавить специальные циклы, в которых соблюдаются определённые условия: в каждом исполнении тела цикла обращение к данным должно быть независимом от предыдущих исполнений. Т.е. может быть такой код:

for i:=0 to count-1 do
  values[i]:=sqr(values[i]);

Но нельзя такой код:

for i:=1 to count-1 do
  values[i]:=values[i-1]+values[i];

А как ты это докажешь в общем случае?

Здравствуйте, vsb, Вы писали:

vsb>А как ты это докажешь в общем случае?
Просто императивный язык для таких задач использовать не нужно.
http://halide-lang.org/

Здравствуйте, CodeMonkey, Вы писали:

CM>Интересно — есть ли хоть какие-то подвижки в автоматическом распараллеливании и синхронизации многопоточного доступа к разделяемым переменным?

Ставит ли критическую секцию на код обновления списка переменных компилятор, когда видит, что кто-то пытается это делать из разных потоков?

Здравствуйте, iZEN, Вы писали:

ZEN>Ставит ли критическую секцию на код обновления списка переменных компилятор, когда видит, что кто-то пытается это делать из разных потоков?

Нет, конечно.

Здравствуйте, LaptevVV, Вы писали:

LVV>В общем виде задача не решаема — теорема есть (аналог останова), что невозможно определить, распараллеливается ли задача или нет.

То же самое можно сказать про автоматическое управление памятью, в общем виде.

Здравствуйте, vsb, Вы писали:

vsb>А как ты это докажешь в общем случае?

А зачем тебе в общем случае?

Здравствуйте, CodeMonkey, Вы писали:

vsb>>А как ты это докажешь в общем случае?

CM>А зачем тебе в общем случае?

Потому, что в коде может быть написано что угодно. Если компилятор будет параллелить то, что приводит к ошибкам, значит это бесполезная фича.

Здравствуйте, vsb, Вы писали:

vsb>Потому, что в коде может быть написано что угодно. Если компилятор будет параллелить то, что приводит к ошибкам, значит это бесполезная фича.

Если есть сомнения, приводит к ошибкам или нет — значит, параллелить не надо. Для начала, неплохо бы обрабатывать только простые случаи, которые к ошибкам не приводят.

Здравствуйте, vsb, Вы писали:

vsb> vsb>>А как ты это докажешь в общем случае?

vsb> CM>А зачем тебе в общем случае?

vsb> Потому, что в коде может быть написано что угодно. Если компилятор будет параллелить то, что приводит к ошибкам, значит это бесполезная фича.
Хуже того. Распараллеливание кода даётся не бесплатно, и нередко приводит к падению производительности, если сделать неправильно.
Но некоторые простые и не очень циклы современные компиляторы умеют simd-ить.

Здравствуйте, ·, Вы писали:

·>Но некоторые простые и не очень циклы современные компиляторы умеют simd-ить.

Ну в моём понимании SIMD это не параллелить, это правильно использовать инструкции процессора. Параллелить это именно на потоки со всеми вытекающими проблемами синхронизации и способами их решения. Я даже не знаю, как SIMD-ить самому (не скатываясь на ассемблер). Это возможно? Написать такой код, который компилятор развернёт в AVX-512 инструкции или выплюнет ошибку компиляции, если это невозможно.

Здравствуйте, vsb, Вы писали:

vsb> Я даже не знаю, как SIMD-ить самому (не скатываясь на ассемблер). Это возможно? Написать такой код, который компилятор развернёт в AVX-512 инструкции или выплюнет ошибку компиляции, если это невозможно.

Есть интринсики, которые внешне выглядят как функции твоего языка, а транслируются напрямую в SIMD команды.
И есть, например, прагмы компилятору, интеловский компилятор их много имеет, можно ими циклы помечать.
При использовании нужных ключей, компилятор про каждый цикл расскажет, смог ли его векторизовать, а если не смог, что именно помешало.

Здравствуйте, WolfHound, Вы писали:

WH>Просто императивный язык для таких задач использовать не нужно.

Это да.

WH>http://halide-lang.org/

А тут сё больше вопросов.
Гугл пробовал использовать Halide для оптимизации в TensorFlow, потом удалил.
Разработчики OpenCV (это сотрудники Intel) начали его использовать для своего dnn модуля, но тоже получилось так, что для Intel CPU код на С++ работает быстрее в 1.5 раза, для Intel iGPU быстрее работает OpenCL. А если использовать OpenVINO в качестве бэкенда, то будет ещё быстрее.
Кажется, что самописный код сейчас всё ещё быстрее, чем этот DSL.

Здравствуйте, Nuzhny, Вы писали:

WH>>http://halide-lang.org/
N>А тут сё больше вопросов.
N>Гугл пробовал использовать Halide для оптимизации в TensorFlow, потом удалил.
N>Разработчики OpenCV (это сотрудники Intel) начали его использовать для своего dnn модуля, но тоже получилось так, что для Intel CPU код на С++ работает быстрее в 1.5 раза, для Intel iGPU быстрее работает OpenCL. А если использовать OpenVINO в качестве бэкенда, то будет ещё быстрее.
1)Откуда дрова?
2)Описываемые сценарии выглядят как оптимизация одной простой функции, на которую ни каких ресурсов не жалко.
Если же у тебя сотни сложных функций которые должны быстро работать на нескольких разных железках то ситуация резко меняется.
3)Если не halide то что? Возможно у него не самая лучшая реализация. Но я, честно говоря, не вижу вычислительную модель, которая лучше подходит для таких задач.

N>Кажется, что самописный код сейчас всё ещё быстрее, чем этот DSL.
Ни один ДСЛ не может ничего такого чего нельзя написать руками используя низкоуровневые примитивы. Так что руками всегда можно получить как минимум тот же результат. Вопрос в объёме работы.

Здравствуйте, WolfHound, Вы писали:

WH>1)Откуда дрова?

Дрова про OpenCV? Я сам тестировал и разработчики выкладывают тесты: здесь и здесь. После этого неудачного опыта был написан OpenVINO, потому что Интелу позарез нужен быстрый инференс сетей на своих CPU.

Про TensorFlow было в новостях, что Halide использовали для Pixel 2 в Pixel Visual Core. Дальше Halide не продвинулся.

WH>2)Описываемые сценарии выглядят как оптимизация одной простой функции, на которую ни каких ресурсов не жалко.
WH>Если же у тебя сотни сложных функций которые должны быстро работать на нескольких разных железках то ситуация резко меняется.

Меняется, да не меняется. Что используют прикладные программисты? Они используют оптимизированные библиотеки от производителей железа, занимаются не низкоуровневой оптимизацией, а оптимизируют алгоритмы. MKL, cuDNN, clDNN, ArrayFire и куча других, сейчас появляется на свет OpenVX — что ещё надо? Кажется, что универсальных программистов становится всё меньше: одни занимаются оптимизацией, а другие алгоритмами. Halide больше про то, чтобы всё смешать.

WH>3)Если не halide то что? Возможно у него не самая лучшая реализация. Но я, честно говоря, не вижу вычислительную модель, которая лучше подходит для таких задач.

Тут вопрос, нужна ли она вообще? Я вживую посмотрел, как пишутся оптимизированные алгоритмы в железных конторах: они знают, что для конкретно этой модели, скажем, видеокарты можно использовать конкретно эти операции. Знают они от ребят из соседнего отдела, которые занимаются компилятором или разработкой железки. И больше никто об этом не знает. Поэтому алгоритмы пишутся очень выборочно, нет одного универсального и оптимизированного даже для линейки устройств. Конкретно в OpenCL, иногда конструкция min(max( x, minval), maxval) может отработать быстрее, чем специализированная clamp. Почему? А хз, но на некоторых устройствах так бывает, до этого хрен додумаешься, если бы не инсайды. Или может помочь знание, что для видеокарт АМД есть расширенные функции типа amd_qsad, которые работают очень быстро и некоторые алгоритмы можно ускорить в 2-4 раза, если их использовать. При этом алгоритмы ещё и упрощаются. Как Halide может до такого додуматься — хз. Но разработчики от производителя железа знают и хрен ты обгонишь их специализированные библиотеки.

Здравствуйте, CodeMonkey, Вы писали:

CM>Интересно — есть ли хоть какие-то подвижки в автоматическом распараллеливании и синхронизации многопоточного доступа к разделяемым переменным?

А вот не надо в многопоточном доступе использовать разделяемые переменные. Надо использовать контейнеры токенов: семафоры, блокирующие очереди и прочие вариации на эту тему. В сетях Петри они назваются "места".

CM>Интересно — есть ли хоть какие-то подвижки в автоматическом распараллеливании и синхронизации многопоточного доступа к разделяемым переменным?
https://ru.wikipedia.org/wiki/OpenMP#C++