тренды 2017

[АццкоМото]

int i=42; // то в этом случае создастся глобальная переменная, под неё отведется место в памяти даных и компилятору тут ничего оптимизировать

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

более того, если я напишу
char* a = "уд";
char* b = "уд";
то два указателя будут указывать на одну строку. не знаю, есть ли это в стандарте, но по факту это обычно так.

хотя мой компилятор С для микропроцессора даже этого не умеет.

ну, вот эти наколенные компиляторы для микропроцессоров - это песТня с припевами. у нас было подобное, типа
x=a+b;
и эта срань генерирует неправильный код. заменяешь на
x=a+b+1;
x--;
и все работает корректно. причем мы машинный код смотрели. реально компилятор глючит. только это было лет 16 назад на процессоре, если не изменяет маразм... ага, изменяет. хотел сказать НС10, но нет такого. гугл подсказал НС11, но это 8-битный, а тот вроде 16-битным был. короче, такая древность, что и не вспомнить

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

я согласен про нюанс
но этот нюанс прямо вытекает из семантики. ну смотрите, грубо говоря. если вы написали template List<T>. понятно же, что компилятор не будет генерить код под все типы, которые он знает. то, что вы привели в пример - туда-сюда то же самое

[АццкоМото]

Мозг мой, конечно, расплавится

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

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

[АццкоМото]

А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.

смотрите, я не специализд совсем и работаю в крайне другой области

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

[oshibka_residenta]

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

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

Ничего подобного. Мозг мой, конечно, расплавится, го библиотека никак не поможет. Я делаю research, значит то, что мне нужно, умные люди ещё не написали. Например, стандартные операции с матрицами есть в Armadillo, есть также BLAST, но иногда надо циклом прогнать каждый элемент матрицы, а матрица большааая.

Хотя если вы имеете в виду собирательный образ data scientist, и не в академии или там в гугле, то да согласна что даже вредно, мозг взорвется.

Но зато теперь понятно, почему тем data scientist, кто в состоянии все это освоить (плюс статистику), да с опытом research, платят нехило. Потому что они не просто знают что есть библиотека, они сами эти библиотеки пишут, оптимизируясь код руками.

Просто возьмите пример
http://gallery.rcpp.org/articles/parall ... transform/" onclick="window.open(this.href);return false;
и замените squareRoot на преобразование, которое вам нужно ( "то, что мне нужно, умные люди ещё не написали" ). Можете не благодарить.

[oshibka_residenta]

смотрите, я не специализд совсем и работаю в крайне другой области

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

Это все уже есть в AWS. Google: AWS GPU instance , Elastic GPU

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

Чего бы это она в хипе создавалась? Там обычно пасется то, что создается посредством оператора new или функцией malloc
Опять же, компилятор до конца может и не узнать будет ли эта переменная использоваться, если она ининициализируется в основном коде, а по факту используется, к примеру, во внешней библиотеке.

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

А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.

Золотой серединой, на мой взгляд, был бы xeon phi последнего поколения. В том смысле что код, отлаженный на обычной рабочей станции без переделок можно прогнать на железке в 60-70 нодов и более.
То есть как бы преимущество GPU при совместимости по бинарному коду с обычным Хеон.

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

но этот нюанс прямо вытекает из семантики. ну смотрите, грубо говоря. если вы написали template List<T>. понятно же, что компилятор не будет генерить код под все типы, которые он знает. то, что вы привели в пример - туда-сюда то же самое

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

[АццкоМото]

смотрите, я не специализд совсем и работаю в крайне другой области

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

Это все уже есть в AWS. Google: AWS GPU instance , Elastic GPU

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

[oshibka_residenta]

А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.

Слишком мало входных данных. Непонятно что у вас есть ( каккой код), и кто/что будет этот код распараллеливать. Это, ведь, самое сложное. Опять же код для GPU писать не тривиально. Менее тривиально, чем для CPU.

[АццкоМото]

Чего бы это она в хипе создавалась? Там обычно пасется то, что создается посредством оператора new или функцией malloc
Опять же, компилятор до конца может и не узнать будет ли эта переменная использоваться, если она ининициализируется в основном коде, а по факту используется, к примеру, во внешней библиотеке.

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

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

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

int i=42; // то в этом случае создастся глобальная переменная, под неё отведется место в памяти даных и компилятору тут ничего оптимизировать

более того, если я напишу
char* a = "уд";
char* b = "уд";
то два указателя будут указывать на одну строку. не знаю, есть ли это в стандарте, но по факту это обычно так.

Ну как бы понятно и не особо отличается от инициализации указателем на один и тот же строковый массив.

Но с инициализацией указателей литеральными константами из Вашего примера нюанс в другом:

char* a = "уд";
char* b = "Муд";

Стандарт не гарантирует что "Муд" и "уд" будут находиться в разных участках памяти, в отличие от:

char a[] = "уд";
char b[] = "Муд";

ну или:

char a[] = "уд";
char b[] = "уд";

где а и в будут указывать на различные участки памяти.

[oshibka_residenta]

Но с инициализацией указателей литеральными константами из Вашего примера нюанс в другом:

char* a = "уд";
char* b = "Муд";

Стандарт не гарантирует что "Муд" и "уд" будут находиться в разных участках памяти, в отличие от:

char a[] = "уд";
char b[] = "Муд";

ну или:

char a[] = "уд";
char b[] = "уд";

Так родилась Java

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

Так родилась Java

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

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

Просто возьмите пример
http://gallery.rcpp.org/articles/parall ... transform/" onclick="window.open(this.href);return false;
и замените squareRoot на преобразование, которое вам нужно ( "то, что мне нужно, умные люди ещё не написали" ). Можете не благодарить.

Давеча баловался со сравнением прохода по типовым контейнерам различными способами, включая пераллелизм.
Так у меня даже на банальном векторе Parallel_for раз в десять оказался медленнее чем стандартный for each.
Такой вот нежданчик на четырех ядрах.
То есть до определенного размера контейнера и сложности функции обработки его элемента накладные расходы на параллелизм существенно перевешивают в сравнении с традиционным проходом.

[oshibka_residenta]

Просто возьмите пример
http://gallery.rcpp.org/articles/parall ... transform/" onclick="window.open(this.href);return false;
и замените squareRoot на преобразование, которое вам нужно ( "то, что мне нужно, умные люди ещё не написали" ). Можете не благодарить.

Давеча баловался со сравнением прохода по типовым контейнерам различными способами, включая пераллелизм.
Так у меня даже на банальном векторе Parallel_for раз в десять оказался медленнее чем банальный for each.
такой вот нежданчик на четырех ядрах. То есть до определенного размера контейнера накладные расходы на параллелизм существенно перевешивают в сравнении с традиционным проходом.

Это довольно очевидно. Но если размер очень маленький, то и возиться не стоит. Предполагается, что задачи занимают часы, если не дни.

[АццкоМото]

int i=42; // то в этом случае создастся глобальная переменная, под неё отведется место в памяти даных и компилятору тут ничего оптимизировать

более того, если я напишу
char* a = "уд";
char* b = "уд";
то два указателя будут указывать на одну строку. не знаю, есть ли это в стандарте, но по факту это обычно так.

Ну как бы понятно и не особо отличается от инициализации указателем на один и тот же строковый массив.

Но с инициализацией указателей литеральными константами из Вашего примера нюанс в другом:

char* a = "уд";
char* b = "Муд";

Стандарт не гарантирует что "Муд" и "уд" будут находиться в разных участках памяти, в отличие от:

char a[] = "уд";
char b[] = "Муд";

ну или:

char a[] = "уд";
char b[] = "уд";

где а и в будут указывать на различные участки памяти.

Век живи, век учись. Вроде бы это довольно очевидно, не я никогда не задумывался о разнице a[] versus a*=
или просто забыл. про "уд" vs "муд", конечно, в курсе.

хотя... я запутался. вы точно уверены, что так и есть? а то я вроде "довольно очевидно", а с другой стороны не вполне уверен. сцуко стыдно

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

У меня немножко другая задача.
Есть некий линейный алгоритм полного прохода по контейнеру заданной длины, который справляется с ним за две миллисекунды.
При увеличении размера контейнера время увеличивается линейно, но верхняя граница не должна заходить за 10 мс
Что делать при увеличении размера в десять раз ?
Решил поглядеть как поможет распараллеливание прохода.
Если бы не это ограничение по времени, то выглядит обнадеживающе для увеличения массива хоть в сто раз, но в этом случае не прокатывает.

[oshibka_residenta]

У меня немножко другая задача.
Есть некий линейный алгоритм полного прохода по контейнеру заданной длины, который справляется с ним за две миллисекунды.
При увеличении размера контейнера время увеличивается линейно, но верхняя граница не должна заходить за 10 мс
Что делать при увеличении размера в десять раз ?
Решил поглядеть как поможет распараллеливание прохода.
Если бы не это ограничение по времени, то выглядит обнадеживающе для увеличения массива хоть в сто раз, но в этом случае не прокатывает.

Если мы говорим про миллисекунды, то все не просто. У меня в похожей ситуации даже самая позорная GPU била 4-core. Но там тоже overhead. Не уверен, что в 10 миллисекунд получится уложиться, но попробовать стоит. У меня был GPU чип от Интел, так что я использовал OpenCL

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

Если мы говорим про миллисекунды, то все не просто. У меня в похожей ситуации даже самая позорная GPU била 4-core. Но там тоже overhead. Не уверен, что в 10 миллисекунд получится уложиться, но попробовать стоит. У меня был GPU чип от Интел, так что я использовал OpenCL

Так примерно и предполагал, если бы не столь обескураживающие результаты на четырех ядрах. Гляну как на 8 и 16 себя поведет.
По результатам может и на прогон в многоядерной железяке сподоблюсь.

Может кто подскажет где прогнать код на кластере Xeon Phi подобно тому как это делает Амазон?

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

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

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

В нашем случае, если выжать хотя бы еше наполовину, то вообще Шуба-кот.
На пальцах - количество одновременно обрабатываемых за гарантированное время контейнеров соответствует количеству клиентов и массштабируется на ура. А вот увеличение размера контейнера, что позволяет претендовать на гораздо более вкусных клиентов идет со скрипом. Тут и лишние десять-двадцать процентов будут весьма нелишними просто как подушка безопасности.

[AndreyT]

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

В С вообще не существует строго определенного понятия "передать массив в функцию". Понятие "передать массив" - это понятие уровня пользователя, терминологического соглашения, сленга. Особенности такой передачи зависят от того, что имеет в виду говорящий. То, что вы сказали, подразумевает,что вы почему-то ограничиваете рассмотрение передачей указателя на элемент массива.

Но этом совсем не обязательно. Вы можете передавать указатель на весь массив (`void foo(int (*a)[20])`). Это тоже "передача массива в функцию". При этом размер массива будет частью типа указателя и никакой потери размерности не произойдет.

В С++ можно определить массив с заданными параметрами размерности как самостоятельный тип и передавать этот тип как параметр в функцию.

Не совсем понятно, о чем идет речь. О разнообразных библиотечных "массивных" типах?

Если речь идет об обычных встроенных массивах, то никакой разницы с С тут нет, кроме разве что возможности реализации вышеупомянутого варианта передачи через ссылки (`void foo(int (&a)[20])`). И нет, в С++ нельзя определить массив с заданными параметрами размерности как самостоятельный тип и при этом как-то заставить его сохранять свою "массивность" в контексте списка параметров функции.

[Kolbasoff]

А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.

Удивите контору, попробуйте на 900 нодах cc2.8xlarge за $2.30/node/hour

[Komissar]

А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.

Удивите контору, попробуйте на 900 нодах cc2.8xlarge за $2.30/node/hour

Не, у меня 900 nodes в универе бесплатно.

с налогоплательщиков сосете?

[flip_flop]

А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.

Золотой серединой, на мой взгляд, был бы xeon phi последнего поколения. В том смысле что код, отлаженный на обычной рабочей станции без переделок можно прогнать на железке в 60-70 нодов и более.
То есть как бы преимущество GPU при совместимости по бинарному коду с обычным Хеон.

Именно так

Для датологов есть много интересного в Intel Distribution of Python, MKL+DAAL: оптимизированные элементы ML/DL. Работает как на обычном Xeon, так и на Xeon Phi (KNL).

Завтра будут интересные пресс-релизы.