тренды 2017

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

Re: тренды 2017

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

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

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

Re: тренды 2017

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

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

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

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

Re: тренды 2017

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

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

User avatar
АццкоМото
Уже с Приветом
Posts: 13651
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 года
В соответствии с новым законопроектом сборщики мусора в работающих на территории РФ Java-машинах обязаны хранить данные в течение полугода.

oshibka_residenta
Уже с Приветом
Posts: 4000
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: 4000
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: 7314
Joined: 27 Sep 2007 22:53

Re: тренды 2017

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

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

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7314
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: 7314
Joined: 27 Sep 2007 22:53

Re: тренды 2017

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

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

User avatar
АццкоМото
Уже с Приветом
Posts: 13651
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
конечно уже есть. я и не претендую, на то, что это я только что придумал и типа первый в мире :)
ведь если бы я сказал, что тренд года это бигдата - вы бы не стали мне давать ссылки на бигдата решения? :) тем не менее, я считаю, что там поле непаханное работы
В соответствии с новым законопроектом сборщики мусора в работающих на территории РФ Java-машинах обязаны хранить данные в течение полугода.

oshibka_residenta
Уже с Приветом
Posts: 4000
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: 13651
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
Опять же, компилятор до конца может и не узнать будет ли эта переменная использоваться, если она ининициализируется в основном коде, а по факту используется, к примеру, во внешней библиотеке.
ок-ок
неаккуратно выразился. семантически это эквивалентно созданию в хипе. типа не в стеке. кусок памяти, на который есть пойнтер и он не протухнет из-за изменения стек пойнтера. сути не меняет

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

User avatar
Мальчик-Одуванчик
Уже с Приветом
Posts: 7314
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: 4000
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: 7314
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: 7314
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: 4000
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: 13651
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 "муд", конечно, в курсе.

хотя... я запутался. вы точно уверены, что так и есть? а то я вроде "довольно очевидно", а с другой стороны не вполне уверен. сцуко стыдно
В соответствии с новым законопроектом сборщики мусора в работающих на территории РФ Java-машинах обязаны хранить данные в течение полугода.

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

Re: тренды 2017

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

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

oshibka_residenta
Уже с Приветом
Posts: 4000
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: 2115
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: 7314
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: 7314
Joined: 27 Sep 2007 22:53

Re: тренды 2017

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

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

User avatar
AndreyT
Уже с Приветом
Posts: 2897
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: 3043
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: city_girl, совков, hey_google, Unknown bot, Yahoo [Bot] and 2 guests