тренды 2017

[Мальчик-Одуванчик]

Ну вот, а когда я читаю советы на тему writing efficient code, часто говорят что надо access array elements in storage order. Оказывается, компилятору все равно?

Больше зависит от архитектуры процессора и особенностей организации, кэширования и выравнивания памяти.
Действительно очень полезный совет при работе с Интеловскими и аналогичыми им по архитектуре процессорами.
Но не уверен что этот совет будет актуален при распараллеливании работы с матрицей, закачанной в оперативную память графической карты.

[Мальчик-Одуванчик]

Что касается матриц, то в случае фиксированной размерности можно определить соотетствующих тип Т[N]..[M] который снимет вышеупомянутую неоднозначность.

Угу, это вы сейчас про C?

Нет именно про С++. В С кроме как указателя на область памяти и смещения относительно размера элемента массива, других способов оперирования с массивами нет. К примеру, если передать массив в функцию как параметр, то кроме указателя на него Вы ничего больше не получите. Функция уже ничего не будет знать о размерности.
В С++ можно определить массив с заданными параметрами размерности как самостоятельный тип и передавать этот тип как параметр в функцию.

[АццкоМото]

Вообще то говоря С++ как раз предусматривает средства оптимизации на уровне языка

но как? может, я пропустил что-то. но си++ это такая пятка мамонта, которая прекрасна своей близостью к железу и полным отрицанием оптимизаций на уровне языка. типа "если компилятор умный, он сделает". отсюда и происхождение OpenMP (хаха, как раз единственная область, где у мен были научные работы не про биологию )

[АццкоМото]

Ну вот, а когда я читаю советы на тему writing efficient code, часто говорят что надо access array elements in storage order. Оказывается, компилятору все равно?

ну Мальчик-Одуванчик лучше прочел ваши мысли. Но. Даже после этого: да, компилятору все равно. А дальше ап ту ю - что-то требуется стандартом языка, что-то - просто причуда конкретного компилятора. Вам оно надо влезать во все эти тонкости?

[Мальчик-Одуванчик]

Вообще то говоря С++ как раз предусматривает средства оптимизации на уровне языка

но как? может, я пропустил что-то. но си++ это такая пятка мамонта, которая прекрасна своей близостью к железу и полным отрицанием оптимизаций на уровне языка. типа "если компилятор умный, он сделает". отсюда и происхождение OpenMP (хаха, как раз единственная область, где у мен были научные работы не про биологию )

По сути это препроцессор, выведенный на уровень самостоятельного языка и зафиксированный в стандарте. То что в плюсах называется метапрорграммированием и что позволяет расширять языковые конструкции базового языка вплоть до создания новых доменных языков-надстроек. Как раз стандартизованные особенности инициализации специализациий шаблонных типов и функций позволяют оптимизировать код по обьему, исключая те куски, где объект/функция определяется, но в конкретной реализации не используется.
Статический полиморфизм так же эффективнее динамического.
У интела есть своя надстройка для распараллеливания и подозреваю что Rcpp тоже относится к подобному выверту.

[Мальчик-Одуванчик]

Наверное не надо, если быстрее не будет.

Наверняка будет существенно быстрее будет, поскольку остальные случаи относятся к редкой экзотике.
Но опять же это всего-лишь особенности наиболее распространённой архитектуры, учитываемой при повышении эффективности кода.
Если память не изменяет, то разбирается в этой книжке:
https://www.amazon.com/Structured-Paral ... 0124159931" onclick="window.open(this.href);return false;

[Kolbasoff]

[...] нетривиальные функции типа besselK [....] когда сижу на горшке.

С утра Бесселя отлично входят на горшке.

[АццкоМото]

Вообще то говоря С++ как раз предусматривает средства оптимизации на уровне языка

но как? может, я пропустил что-то. но си++ это такая пятка мамонта, которая прекрасна своей близостью к железу и полным отрицанием оптимизаций на уровне языка. типа "если компилятор умный, он сделает". отсюда и происхождение OpenMP (хаха, как раз единственная область, где у мен были научные работы не про биологию )

По сути это препроцессор, выведенный на уровень самостоятельного языка и зафиксированный в стандарте. То что в плюсах называется метапрорграммированием и что позволяет расширять языковые конструкции базового языка вплоть до создания новых доменных языков-надстроек. Как раз стандартизованные особенности инициализации специализациий шаблонных типов и функций позволяют оптимизировать код по обьему, исключая те куски, где объект/функция определяется, но в конкретной реализации не используется.
Статический полиморфизм так же эффективнее динамического.
У интела есть своя надстройка для распараллеливания и подозреваю что Rcpp тоже относится к подобному выверту.

Ну ладно же. Какая связь препроцессора и оптимизации на уровне языка? Мне кажется, мы сейчас говорим о разном.

[oshibka_residenta]

Не слушайте мальчика. Этот динозавр плохому научит. Гугл советует rcpp parallel
http://gallery.rcpp.org/articles/parallel-vector-sum/" onclick="window.open(this.href);return false;

https://blog.rstudio.org/2016/01/15/rcp ... -parallel/" onclick="window.open(this.href);return false;

Про темплейты и оптимизацию размера кода забудьте как страшный сон

[Мальчик-Одуванчик]

Не слушайте мальчика. Этот динозавр плохому научит. Гугл советует rcpp parallel

Про темплейты и оптимизацию размера кода забудьте как страшный сон

Если копнуть чуток поглубже то rcppparallel это всего лишь надстройка поверх интеловского tbb, которая, в свою очередь, является шаблонной библиотекой.

[Мальчик-Одуванчик]

Ну ладно же. Какая связь препроцессора и оптимизации на уровне языка? Мне кажется, мы сейчас говорим о разном.

Рассмотрим обобщенную функцию с несколькими специализациями для разных типов входных параметров.
Стандарт гарантирует что в памяти займет место лишь код инстанцированных конкретным типом, а остальные будут отброшены.

К примеру:
template<typename T> void f(T t) { ......}; // обобщенная функция
template<> void f<char>(char c) { ... } // специализация для типа char
template<> void f(double d) { ....} // специализация для типа double
int main()
{
f<int>(1); // вызов обобщенной функции
f('a'); // вызов специализированной
}

f(double d) - будет отброшена на этапе компиляции и ее код не будет занимать место в памяти

[oshibka_residenta]

Если копнуть чуток поглубже то rcppparallel это всего лишь надстройка поверх интеловского tbb, которая, в свою очередь, является шаблонной библиотекой.

Я не сомневаюсь, что вы прекрасный инженер, но , видимо, не совсем понимаете , что Снежной Королеве это знать не только не полезно, но и вредно. У нее мозг расплавится. Ей надо знать, что есть библиотека, которая выполняет операции с матрицами быстрее, чем тупой цикл. И все.

[Физик-Лирик]

[quote="Снежная Королева"] Только я параллельно ещё читаю чужой код, ковыряюсь в R пакетах, написанных на C, которые считают сложные мат.модели, производные и градиенты, нетривиальные функции /quote]
Мне кажется, считать производные и градиенты вещь не такая уж и сложная. Другое дело, если речь идёт о пространствах очень большой размерности, и сама задача состоит в чем то другом (например, оптимизация методом градиентного спуска). Тогда встанет вопрос о распараллеливании процессов или продвижении по отдельным направлениям.
Какие вопросы Вы изучаете? Просто интересно, куда сейчас можно приложиться.

[Boriskin]

Если память не изменяет, то разбирается в этой книжке:
https://www.amazon.com/Structured-Paral ... 0124159931" onclick="window.open(this.href);return false;

Спасибо за наводку.

[АццкоМото]

Ну ладно же. Какая связь препроцессора и оптимизации на уровне языка? Мне кажется, мы сейчас говорим о разном.

Рассмотрим обобщенную функцию с несколькими специализациями для разных типов входных параметров.
Стандарт гарантирует что в памяти займет место лишь код инстанцированных конкретным типом, а остальные будут отброшены.

К примеру:
template<typename T> void f(T t) { ......}; // обобщенная функция
template<> void f<char>(char c) { ... } // специализация для типа char
template<> void f(double d) { ....} // специализация для типа double
int main()
{
f<int>(1); // вызов обобщенной функции
f('a'); // вызов специализированной
}

f(double d) - будет отброшена на этапе компиляции и ее код не будет занимать место в памяти

дык это... не знаю, гарантирует ли это стандарт или нет, но де факто если я напишу int i=42; и нигде не использую, то тоже код сгенерирован не будет. но разве это имеет отношение к топику?

[Мальчик-Одуванчик]

Если копнуть чуток поглубже то rcppparallel это всего лишь надстройка поверх интеловского tbb, которая, в свою очередь, является шаблонной библиотекой.

Я не сомневаюсь, что вы прекрасный инженер, но , видимо, не совсем понимаете , что Снежной Королеве это знать не только не полезно, но и вредно. У нее мозг расплавится. Ей надо знать, что есть библиотека, которая выполняет операции с матрицами быстрее, чем тупой цикл. И все.

В целом все верно, однако книжки и документация по tbb даст возможность выжать из этх алгоритмов еще чуток или настроить на блок сопроцессоров (xeon phi).А главное - при каких условиях эта библиотека будет быстрее тупого цикла или применения std::алгоритма
Или применить паттерны параллельной обработки к к своим собственным структурам данных.

[Мальчик-Одуванчик]

но де факто если я напишу int i=42; и нигде не использую, то тоже код сгенерирован не будет. но разве это имеет отношение к топику?

Смотря где напишешь (область видимости) и смотря какой компилятор (мой что генерит для пика даже такую фигню не соптимизирует для локальных переменных)

[oshibka_residenta]

Если копнуть чуток поглубже то rcppparallel это всего лишь надстройка поверх интеловского tbb, которая, в свою очередь, является шаблонной библиотекой.

Я не сомневаюсь, что вы прекрасный инженер, но , видимо, не совсем понимаете , что Снежной Королеве это знать не только не полезно, но и вредно. У нее мозг расплавится. Ей надо знать, что есть библиотека, которая выполняет операции с матрицами быстрее, чем тупой цикл. И все.

В целом все верно, однако книжки и документация по tbb даст возможность выжать из этх алгоритмов еще чуток или настроить на блок сопроцессоров (xeon phi).А главное - при каких условиях эта библиотека будет быстрее тупого цикла или применения std::алгоритма
Или применить паттерны параллельной обработки к к своим собственным структурам данных.

Я не сомневаюсь, что нет предела совершенству. Но не так называемые Data Scientists должны етим заниматься.
Кстати, и для GPU есть. http://www.r-tutor.com/gpu-computing" onclick="window.open(this.href);return false;
Как и ожидалось, "все украдено до нас".

[АццкоМото]

но де факто если я напишу int i=42; и нигде не использую, то тоже код сгенерирован не будет. но разве это имеет отношение к топику?

Смотря где напишешь (область видимости) и смотря какой компилятор (мой что генерит для пика даже такую фигню не соптимизирует для локальных переменных)

кумон. я не могу поверить, что в 2017 году компилятор соптимизирует "смотря где".

и тут у меня разрыв мозга. с одной стороны, я знаю, что если вы что-то утверждаете, то к этому нужно как минимум прислушаться. с другой стороны - ну совершенно невероятно звучит

[АццкоМото]

выжать из этх алгоритмов еще чуток

а вот опять же, если говорить про тренды года. а разве сейчас кому-то интересно выжимать "еще чуток"? есть стойкое ощущение, что в тренде - находить решения для масштабирования, которые меняют расклад на порядки. а если я оптимизирую завтра реализацию условного quicksort() на 10%... ну типа - молодец, мальчик, это круто. возьми с полки пирожок, но nobody cares

[Boriskin]

Смотря где напишешь (область видимости) и смотря какой компилятор (мой что генерит для пика даже такую фигню не соптимизирует для локальных переменных)

Кстати да, насчет выделенного - на билде 2014 года на сессии посвященной низкоуровневой оптимизации лид команды МС компилятора плюсов рассказывал, как в его практике был случай, когда на свежевыпущенной Интелом архитектуре (в голове отложился Хасвелл, но могу и врать) результаты оптимизированного компилятором кода в некоторых бенчмарках оказались в разы ниже, чем от того же кода с тем же комилятором на предыдущей архитектуре. Оказалось Интел изменил систему предсказания next op в железе и некоторые оптимизации стали работать не в плюс, а в минус. Вообще очень толковый дядька, мы там с ним после сессии еще минут 30 в коридоре трындели...

[oshibka_residenta]

выжать из этх алгоритмов еще чуток

а вот опять же, если говорить про тренды года. а разве сейчас кому-то интересно выжимать "еще чуток"? есть стойкое ощущение, что в тренде - находить решения для масштабирования, которые меняют расклад на порядки. а если я оптимизирую завтра реализацию условного quicksort() на 10%... ну типа - молодец, мальчик, это круто. возьми с полки пирожок, но nobody cares

+100
К примеру, авторы R GPU утверждают, что их решение работает в 5-10 раз быстрее, чем CPU.

[Мальчик-Одуванчик]

но де факто если я напишу int i=42; и нигде не использую, то тоже код сгенерирован не будет. но разве это имеет отношение к топику?

Смотря где напишешь (область видимости) и смотря какой компилятор (мой что генерит для пика даже такую фигню не соптимизирует для локальных переменных)

кумон. я не могу поверить, что в 2017 году компилятор соптимизирует "смотря где".

и тут у меня разрыв мозга. с одной стороны, я знаю, что если вы что-то утверждаете, то к этому нужно как минимум прислушаться. с другой стороны - ну совершенно невероятно звучит

int i=42; // в этом случае создастся глобальная переменная, под неё отведется место в памяти даных и компилятору тут нечего оптимизировать
int main { int i=42; } // а вот здесь на стеке создастся локальная переменнаяи есть что оптимизировать, хотя мой компилятор С для микропроцессора даже этого не умеет. Опять же если выключить оптимизацию то и обычный скорее всего создаст.

Но есть нюанс: то о чем писал в отношении обобщенных функций определяется стандартом, а вот последнее отдано на откуп производителям компиляторов

[Мальчик-Одуванчик]

Я не сомневаюсь, что нет предела совершенству. Но не так называемые Data Scientists должны етим заниматься.
Кстати, и для GPU есть. http://www.r-tutor.com/gpu-computing" onclick="window.open(this.href);return false;

Но я вот что-то не нашел что rcpp-parallel будет поддерживать GPU от Nvidia.

[oshibka_residenta]

Я не сомневаюсь, что нет предела совершенству. Но не так называемые Data Scientists должны етим заниматься.
Кстати, и для GPU есть. http://www.r-tutor.com/gpu-computing" onclick="window.open(this.href);return false;

Но я вот что-то не нашел что rcpp-parallel будет поддерживать GPU от Nvidia.

rcpp-parallel - нет, но если варианты
http://www.r-tutor.com/gpu-computing" onclick="window.open(this.href);return false;