тренды 2017

User avatar
Снежная Королева
Уже с Приветом
Posts: 2197
Joined: 13 May 2004 07:28

Re: тренды 2017

Post by Снежная Королева » 11 Jan 2017 22:19

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

User avatar
АццкоМото
Уже с Приветом
Posts: 14125
Joined: 01 Mar 2007 05:18
Location: VVO->ORD->DFW->SFO->DFW->PDX

Re: тренды 2017

Post by АццкоМото » 11 Jan 2017 22:19

Снежная Королева wrote:Мозг мой, конечно, расплавится
он прав в том, что язык глубоко вам знать не надо. не потому, что вы глупая, умом не вышли и так далее.

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

User avatar
Снежная Королева
Уже с Приветом
Posts: 2197
Joined: 13 May 2004 07:28

Re: тренды 2017

Post by Снежная Королева » 11 Jan 2017 22:21

Хорошо, поверю вам, не буду терять время.

User avatar
АццкоМото
Уже с Приветом
Posts: 14125
Joined: 01 Mar 2007 05:18
Location: VVO->ORD->DFW->SFO->DFW->PDX

Re: тренды 2017

Post by АццкоМото » 11 Jan 2017 22:23

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

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

oshibka_residenta
Уже с Приветом
Posts: 4234
Joined: 13 Feb 2002 10:01
Location: Bay Area

Re: тренды 2017

Post by oshibka_residenta » 11 Jan 2017 22:24

Снежная Королева wrote:
oshibka_residenta wrote:
Мальчик-Одуванчик wrote:
Если копнуть чуток поглубже то 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
Уже с Приветом
Posts: 4234
Joined: 13 Feb 2002 10:01
Location: Bay Area

Re: тренды 2017

Post by oshibka_residenta » 11 Jan 2017 22:28

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

но чуйка говорит: GPU это интереснее. как минимум, потому что потом может быть кластер из N*GPU на сотни нод. и это уже качественный скачок. т.е. масштабирование в двух направлениях - много-премного вычислительных блоков с быстрой связью, помножено на много нодов с медленной связью. по-моему, это и есть один из трендов 2017 года
Это все уже есть в AWS. Google: AWS GPU instance , Elastic GPU
Last edited by oshibka_residenta on 11 Jan 2017 22:28, edited 1 time in total.

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 22:28

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

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 22:33

Снежная Королева wrote:А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.
Золотой серединой, на мой взгляд, был бы xeon phi последнего поколения. В том смысле что код, отлаженный на обычной рабочей станции без переделок можно прогнать на железке в 60-70 нодов и более.
То есть как бы преимущество GPU при совместимости по бинарному коду с обычным Хеон.
Last edited by Мальчик-Одуванчик on 11 Jan 2017 23:24, edited 1 time in total.

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 22:39

АццкоМото wrote: но этот нюанс прямо вытекает из семантики. ну смотрите, грубо говоря. если вы написали template List<T>. понятно же, что компилятор не будет генерить код под все типы, которые он знает. то, что вы привели в пример - туда-сюда то же самое
Кроме того что он не будет генерить код, он отбросит уже написанный для неиспользуемых специализаций.
С набором обычных перегруженных функций такого не произойдет.

User avatar
АццкоМото
Уже с Приветом
Posts: 14125
Joined: 01 Mar 2007 05:18
Location: VVO->ORD->DFW->SFO->DFW->PDX

Re: тренды 2017

Post by АццкоМото » 11 Jan 2017 22:43

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

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

oshibka_residenta
Уже с Приветом
Posts: 4234
Joined: 13 Feb 2002 10:01
Location: Bay Area

Re: тренды 2017

Post by oshibka_residenta » 11 Jan 2017 22:44

Снежная Королева wrote:А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.
Слишком мало входных данных. Непонятно что у вас есть ( каккой код), и кто/что будет этот код распараллеливать. Это, ведь, самое сложное. Опять же код для GPU писать не тривиально. Менее тривиально, чем для CPU.

User avatar
АццкоМото
Уже с Приветом
Posts: 14125
Joined: 01 Mar 2007 05:18
Location: VVO->ORD->DFW->SFO->DFW->PDX

Re: тренды 2017

Post by АццкоМото » 11 Jan 2017 22:48

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

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

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 22:57

АццкоМото wrote:
Мальчик-Одуванчик wrote: int i=42; // то в этом случае создастся глобальная переменная, под неё отведется место в памяти даных и компилятору тут ничего оптимизировать
более того, если я напишу
char* a = "уд";
char* b = "уд";
то два указателя будут указывать на одну строку. не знаю, есть ли это в стандарте, но по факту это обычно так.
Ну как бы понятно и не особо отличается от инициализации указателем на один и тот же строковый массив.

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

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

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

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

ну или:

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

где а и в будут указывать на различные участки памяти.
Last edited by Мальчик-Одуванчик on 11 Jan 2017 23:08, edited 2 times in total.

oshibka_residenta
Уже с Приветом
Posts: 4234
Joined: 13 Feb 2002 10:01
Location: Bay Area

Re: тренды 2017

Post by oshibka_residenta » 11 Jan 2017 23:04

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

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

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

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

ну или:

char a[] = "уд";
char b[] = "уд";
Так родилась Java

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 23:10

oshibka_residenta wrote: Так родилась Java
Согласен, это могло послужить катализатором индоцепной реакции, на выходе которой и случился подобный высер.
Last edited by Мальчик-Одуванчик on 11 Jan 2017 23:22, edited 1 time in total.

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 23:21

oshibka_residenta wrote: Просто возьмите пример
http://gallery.rcpp.org/articles/parall ... transform/" onclick="window.open(this.href);return false;
и замените squareRoot на преобразование, которое вам нужно ( "то, что мне нужно, умные люди ещё не написали" ). Можете не благодарить.
Давеча баловался со сравнением прохода по типовым контейнерам различными способами, включая пераллелизм.
Так у меня даже на банальном векторе Parallel_for раз в десять оказался медленнее чем стандартный for each.
Такой вот нежданчик на четырех ядрах.
То есть до определенного размера контейнера и сложности функции обработки его элемента накладные расходы на параллелизм существенно перевешивают в сравнении с традиционным проходом.
Last edited by Мальчик-Одуванчик on 11 Jan 2017 23:39, edited 1 time in total.

oshibka_residenta
Уже с Приветом
Posts: 4234
Joined: 13 Feb 2002 10:01
Location: Bay Area

Re: тренды 2017

Post by oshibka_residenta » 11 Jan 2017 23:26

Мальчик-Одуванчик wrote:
oshibka_residenta wrote: Просто возьмите пример
http://gallery.rcpp.org/articles/parall ... transform/" onclick="window.open(this.href);return false;
и замените squareRoot на преобразование, которое вам нужно ( "то, что мне нужно, умные люди ещё не написали" ). Можете не благодарить.
Давеча баловался со сравнением прохода по типовым контейнерам различными способами, включая пераллелизм.
Так у меня даже на банальном векторе Parallel_for раз в десять оказался медленнее чем банальный for each.
такой вот нежданчик на четырех ядрах. То есть до определенного размера контейнера накладные расходы на параллелизм существенно перевешивают в сравнении с традиционным проходом.
Это довольно очевидно. Но если размер очень маленький, то и возиться не стоит. Предполагается, что задачи занимают часы, если не дни.

User avatar
АццкоМото
Уже с Приветом
Posts: 14125
Joined: 01 Mar 2007 05:18
Location: VVO->ORD->DFW->SFO->DFW->PDX

Re: тренды 2017

Post by АццкоМото » 11 Jan 2017 23:48

Мальчик-Одуванчик wrote:
АццкоМото wrote:
Мальчик-Одуванчик wrote: int i=42; // то в этом случае создастся глобальная переменная, под неё отведется место в памяти даных и компилятору тут ничего оптимизировать
более того, если я напишу
char* a = "уд";
char* b = "уд";
то два указателя будут указывать на одну строку. не знаю, есть ли это в стандарте, но по факту это обычно так.
Ну как бы понятно и не особо отличается от инициализации указателем на один и тот же строковый массив.

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

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

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

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

ну или:

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

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

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

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 11 Jan 2017 23:56

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

oshibka_residenta
Уже с Приветом
Posts: 4234
Joined: 13 Feb 2002 10:01
Location: Bay Area

Re: тренды 2017

Post by oshibka_residenta » 12 Jan 2017 00:02

Мальчик-Одуванчик wrote:У меня немножко другая задача.
Есть некий линейный алгоритм полного прохода по контейнеру заданной длины, который справляется с ним за две миллисекунды.
При увеличении размера контейнера время увеличивается линейно, но верхняя граница не должна заходить за 10 мс
Что делать при увеличении размера в десять раз ?
Решил поглядеть как поможет распараллеливание прохода.
Если бы не это ограничение по времени, то выглядит обнадеживающе для увеличения массива хоть в сто раз, но в этом случае не прокатывает.
Если мы говорим про миллисекунды, то все не просто. У меня в похожей ситуации даже самая позорная GPU била 4-core. Но там тоже overhead. Не уверен, что в 10 миллисекунд получится уложиться, но попробовать стоит. У меня был GPU чип от Интел, так что я использовал OpenCL

User avatar
Снежная Королева
Уже с Приветом
Posts: 2197
Joined: 13 May 2004 07:28

Re: тренды 2017

Post by Снежная Королева » 12 Jan 2017 00:26

oshibka_residenta wrote:
Снежная Королева wrote:А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.
Слишком мало входных данных. Непонятно что у вас есть ( каккой код), и кто/что будет этот код распараллеливать. Это, ведь, самое сложное. Опять же код для GPU писать не тривиально. Менее тривиально, чем для CPU.
Я попробую сделать по тому примеру что вы ранее указали, с RcppParallel. Большое спасибо. Если быстрее не будет, приду опять.

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 12 Jan 2017 00:41

oshibka_residenta wrote: Если мы говорим про миллисекунды, то все не просто. У меня в похожей ситуации даже самая позорная GPU била 4-core. Но там тоже overhead. Не уверен, что в 10 миллисекунд получится уложиться, но попробовать стоит. У меня был GPU чип от Интел, так что я использовал OpenCL
Так примерно и предполагал, если бы не столь обескураживающие результаты на четырех ядрах. Гляну как на 8 и 16 себя поведет.
По результатам может и на прогон в многоядерной железяке сподоблюсь.

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

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7574
Joined: 27 Sep 2007 22:53

Re: тренды 2017

Post by Мальчик-Одуванчик » 12 Jan 2017 00:55

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

User avatar
AndreyT
Уже с Приветом
Posts: 2924
Joined: 14 Apr 2004 01:11
Location: SFBA (было: Минск, Беларусь)

Re: тренды 2017

Post by AndreyT » 12 Jan 2017 03:49

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

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

Если речь идет об обычных встроенных массивах, то никакой разницы с С тут нет, кроме разве что возможности реализации вышеупомянутого варианта передачи через ссылки (`void foo(int (&a)[20])`). И нет, в С++ нельзя определить массив с заданными параметрами размерности как самостоятельный тип и при этом как-то заставить его сохранять свою "массивность" в контексте списка параметров функции.
Last edited by AndreyT on 12 Jan 2017 05:56, edited 1 time in total.
Best regards,
Андрей

User avatar
Kolbasoff
Уже с Приветом
Posts: 3343
Joined: 02 Jan 2005 22:10

Re: тренды 2017

Post by Kolbasoff » 12 Jan 2017 04:44

Снежная Королева wrote:А что уважаемые посоветуют: пробовать параллелизм на кластере 100-900 nodes, или пробовать GPU computing? Времени мало как всегда.
Удивите контору, попробуйте на 900 нодах cc2.8xlarge за $2.30/node/hour

Return to “Работа и Карьера в IT”

Who is online

Users browsing this forum: _Lenchik, rtogan, SUPER, Unknown bot and 2 guests