Про Nvidia

lexa - 19/Ноя/2012 12:39

Если кто вдруг не видел. На Supercomputers 2012 у Nvidia был свой уголок, NVidia Technology Theater. Где выступали всякие интересные люди со всякими интересными презентациями.

Если кто не видел, рекомендую пойти на архив записей и повтыкать. Там дурацкий интерфейс, надо в правом блоке (где "чат") ткнуть в закладку "видео" и пораскрывать ее. Скажем, про CARMA мне было весьма интересно.

Чтобы два раза не вставать: утро понедельника - время для общефилософских рассуждений

Мне ужасно не нравится, то что сейчас происходит в GPGPU-мире:

  • Есть Nvidia с CUDA и с аккуратно спрятанным под ковер OpenCL. То есть OpenCL 1.1 в драйверах есть, но компания делает вид, что никакого OpenCL в природе не существует. Где, к примеру, OpenCL 1.2? При этом, в HPC-области NVidia очевидный лидер, если кто-то делает HPC-софт, то делает он его в первую очередь под CUDA (ну, насколько я вижу).
  • Есть OpenCL, в который кинулся весь остальной мир. И на CPU и на GPU и на x86 и на ARM и на прочих архитектурах. Если писать что-то для более-менее массового юзера, то очевидно что на OpenCL, ибо рынок куда шире.
Душераздирающее зрелище.

Comments

kiryl (not verified) - 19/Ноя/2012 14:06

За Xeon Phi разговор был? Интересно как он изменит растановку сил на HPC рынке.

lexa - 19/Ноя/2012 14:31

У Nvidia - нет, не был, естественно. А вообще на SC12 - да был.

Вопрос открытый и интересный. По спекам - это терафлопсный (DP) чип, т.е. чуть похуже чем NVidia K20X (1.3 TF) по перформансу, чуть получше по гигафлопсам на ватт, т.е. примерно та же хрень.

При этом его позиционируют как "fully compatible with code written for multi-core Xeon" (прямо из рекламной листовки текст перебил) - что, по-моему, есть чистое вранье. Т.е. там векторные инструкции другие (AVX2-512 бит) и просто SSE4 (от предыдущих Xeon) код - очевидно не пойдет. Скалярный - вероятно пойдет, но смысла в этом никакого нет.
При этом перенос впрямую (перекомпиляцией) векторизуемого кода с SSE/AVX - возможен, но не всегда будет оптиммальным т.к. инструкции могут больше (gather, как минимум).

При этом, интел уже вложился туда неплохо. Т.е. вроде бы новые версии MKL умеют туда что-то оффлоадить (пока мало, будет больше).

Ну и на фоне MIC - будущее OpenCL в HPC становится интереснее. Потому что у AMD в этом месте, как мне кажется, руки уже опустились совсем (несмотря на выпусе свежих профессиональных акселераторов - никакой внятной жизни в районе APP я что-то давно не вижу). А Intel OpenCL для Phi уже раздает (для Linux only пока), и вполне возможно, что HPC-жизнь в этом месте оживится.

Что еще важно для Phi - это чтобы появились дешевые девелоперские варианты. NVidia, как мне кажется, очень сильно выиграла на том, что можно купить 100-200 баксовую карточку и на ней девелопить. Да, перформанс будет не такой, как на взрослых теслах, но отладить то можно.

blacklion - 20/Ноя/2012 12:40

При этом перенос впрямую (перекомпиляцией) векторизуемого кода с SSE/AVX - возможен, но не всегда будет оптиммальным т.к. инструкции могут больше (gather, как минимум).
Ну а так компилятор не справится понять, что можно векторизовать больше?

Вообще, я тут слушаю курсеровскую Comuer Arhitecture, довольно бестолковый курс, но вот в разделе про векторные компьютеры утверждалось, что у того же Крея компиляторы такие умные, что никаких спец-языков не надо -- всё само векторизуется если это вообще возможно. Не то что в нашем gcc. Врут? По описанию-то этот AVX уже вполне себе векторный процессор, ну длина вектора пока не супер-длинная, но уже тоже (512) ничего. Может пора достать из пыльного угла старые компиляторы наоборот? Которые, в отличие от gcc, с нуля проектировались под такие процессоры?

lexa - 20/Ноя/2012 12:52

Я ничего не знаю о креевских компиляторах и векторных процессорах. Но подозреваю что
а) там именно "векторные типы", может быть переменной длины, но исходно векторные т.е. можно написать A=B+C и это развернется в цикл внутри
б) и это фортран, где нет указателей, а значит нет и алиасинга т.е. компилятор не должен предполагать что в A=B+C на самом деле попытаются запихать A=&(A[1])+&[A[2]) (смысл понятен, я надеюсь).

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

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

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

blacklion - 20/Ноя/2012 13:49

Там в примерах C и циклы показывали (но, да, у векторных процессоров есть понятие длины вектора, которое можно выставить от 1 до максимальной архитектурной длины). Ну а альясинг -- это же вопрос опции командной строки. Сделать опцию ``я клянусь мамой и папой, что нет там альясинга'' и всё. Плюс -- ключевое слово restrict уже давно есть.

lexa - 20/Ноя/2012 13:56

Aliasing бывает и на this и вообще с плюсами тяжело в этом смысле.

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

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

blacklion - 20/Ноя/2012 14:04

(ссылка побилась)
Писать ядра на plain C, делов-то ;-)

Это же даже не альясинг, это что-то другое. Это какой-то неявный волатайл. Я не уверен, что стандарт обязывает тут вставлять волатайл компилятором. С глобальными-то переменными такой проблемы не было (точнее -- типична обратная проблема, по крайней мере у микроконтроллерщиков, которые электронщики, а не программисты -- не написали волатайл и удивляются, что цикл ожидания события стал мёртвым. 100500 раз видел такие посты).

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

lexa - 20/Ноя/2012 14:46

Это не многопоточность, это векторность. То есть тоже конечно параллелизм (instruction level), но мы ведь хотим от компилятора, чтобы он нам эту параллельность сам привнес, не привнеся при этом ошибок.

Но никто же не может ему обещать, что мы таки не сделали оного алиасинга где-то еще в коде:

class foo {
int array[10],*ptr;
};
foo::alias() { ptr = array; }

И, если я правильно понимаю, стандартного способа описать ptr как restrict - в C++ нету. Есть restrict функции в gcc, которые снимают aliasing с this, ну и все. Т.е. для

class baz {
int *foo,*bar;
}

нет способа сказать, что foo и bar - никогда не алиасятся.
Т.е. это не современный C++ конечно, в плюсах надо std::vector писать, ну так внутри оного vector все едино указатель, т.е. ничего не меняется.

P.S. ссылку поправил, спасибо.

blacklion - 20/Ноя/2012 15:31

Это не многопоточность, это векторность.

В случае инкремента счётчика нет там никакой векторности.

Но никто же не может ему обещать

Может. Программист. Опцией командной строки.

стандартного способа описать ptr как restrict - в C++ нету.

А ключевое слово restrict -- оно только к аргументам функции применимо? Вообще пришут про просто pointer declaration.
Ну да, оно C99, но оно вовсю используется, например, в stdlib (во всяких memmove и прочих) уже, а stdlib и в С++ должен же работать.

lexa - 20/Ноя/2012 16:03

1) В случае инкремента счетчика вообще должны быть атомики.
Но это - другая история, мы же о векторизующих компиляторах, а не о многопоточности.

2) "Опции командной строки" - отказать. Это управление а) на уровне файла с исходниками б) не средствами языка. в) несовместимое

3) stdlib весь объявлен как extern "C" - и это аргументы функций. Только вот memmove - уж точно не restrict, хотя вот в некоторых реализациях вроде memcpy бывает c restrict.
Впрочем, объявление __restrict для члена класса - 2012-я студия съела. Надо исследовать, что оно там наслесарит.

blacklion - 20/Ноя/2012 16:17

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

2) Ну а нет переносимого способа в рамках языка. И командная строка мне нравится как непереносимый способ куда больше, чем __attribute__(()). Нету ключика -- код будет корректный, но тормозной. Никакой опасности. То, что уровень оптимизации через командную строку задаётся, тебя же не смущает, правда? А это вот такая _опасная_ оптимизация, которую надо включать отдельно. Нормальный подход, нет? Кстати, не про это ли -fno-strict-aliasing в gcc? ;-)

3) Я не читал стандарта C99 (где бы его взять бесплатно), но в мурзилках сказано про pointer declaration, без уточнения в аргументности. Я там не помню, кому всё это прописали. И, да, опять же, расширение, которое пришло из C99, мне кажется меньшим злом, чем любые кастомные расширения.

lexa - 20/Ноя/2012 16:46

Rомандная строка - это ж вообще жесть.
В реальной жизни же бывают aliased-указатели. Причем, вот прямо в той же функции, где и non-aliased. И что?

blacklion - 20/Ноя/2012 16:54

Ну тогда настаивать на restricted, благо чистых C++ компиляторов не бывает (или бывают?) и, по идее, поддержка restricted в C++ -- вопрос упёртости авторов компилятора в стандарт, т.е. политический, а не технический.

lexa - 20/Ноя/2012 16:59

Ну, да. Для указателей. Как насчет references?

blacklion - 20/Ноя/2012 17:05

(пожимает плечам) добавить. const же те может быть. Опять же, с точки зрения оптимизатора нет никакой разницы (я очень удивлюсь, если на том уровне есть разница). Она же вся съедается на этапе синтаксического анализа. Референсы -- это же чистый syntatic shugar, нет? Ну, ещё NULL не могут быть и должны быть инициализированы.

lexa - 20/Ноя/2012 17:25

Разница в том, что для references вообще никакого restrict нет. Потому что в C99 он не нужен, по причине отсутствия референсов.

А проблема - есть:

void vec_add(vector& a, b,c);
и вызов
vec_add(a,a,a);

Ну то есть стандартный ответ, что есть valarray и отвалите, но какой-то он неубедительный по мне.

blacklion - 20/Ноя/2012 17:31

Ну уж если разрешать restrict в C++, то, думается мне, разрешить его только для указателей или впихнуть ещё и к референсам -- вопрос, опять же, чисто политический, а технически решается одной локальной правкой грамматики или ручного парсера.

usovalx (not verified) - 20/Ноя/2012 04:50

Да когда уже этих ...... расстреливать начнут. Ну что за шиза у них всех выложить видео на сайте, и не давать скачать.

Вот вроде и хочется посмотреть, но времени сидеть перед компом нет. А по дороге в поезде с их сайта не посмотришь.

lexa - 20/Ноя/2012 09:12

У NVidia это новая шиза. Раньше они все видео делали как-то сами (трансляция шла с их сайта, а не с чужого) - и выкладывали архивы, правда не сразу. А сейчас вот внезапно перешли на чужой сервис.

А глобально - мне буквально вчера объясняли, что веб убил десктопные приложения, кому дескать оно надо, если всякие google docs в вебе. На что я резонно возразил, что такое гуглозомбирование лечится получасом отсутствия интернета.

usovalx (not verified) - 20/Ноя/2012 15:46

Ладно документы -- вот где эти люди берут мобильный трафик?

Если с моего контракта смотреть -- я его весь использую дня за 3-4. Data-only контракты побольше, но месяц смотрения видео по часу-полтора в день и они не выдержат.

lexa - 20/Ноя/2012 16:13

Ну вот если, к примеру, из Москвы не вылезать, то есть вот Yota. Типа, безлимитный мегабит за 600 рублей в месяц. Я, правда, не пользователь.

blacklion - 20/Ноя/2012 12:36

Это пост ненависти к nVidia, да? У меня тут с виндовс-апдейтом новые драйвера приползли.
+4 сервиса в памяти. Иконка в трее, 5 иконок про 3D Vision в старт-меню.
Не, я всё вычистил, но вопрос остался: они там ебанулись?! Зачем мне иконка от видеодрайвера в трее? Зачем мне шелл-экстеншен от видеодрайвера!? ЗАчем мне проверялка апдейтов от видеодрайвера, который и так приползает через виндовс-апдейт?! Зачем мне сервис 3D-картинки на обычном мониторе -- оно что, не может прочесть его характеристики!? Драйвер, блядь.

И всё это, сука, запрятано в запуск сервиса (!) а не в логичный %USER%\Start Menu\StartUp, и не отключается штатными средствами! Нет, надо брать сисинтерналовскую утилиту и вычтщать из тёмных углов. Казлы.

lexa - 20/Ноя/2012 12:54

Я никогда так не делал, ибо лень, но у нвидиевских драйверов есть custom-инсталляция, поди там можно 3Dvision запретить.

blacklion - 20/Ноя/2012 13:45

Дык у меня они же даже не отдельно стоят, у меня их винда ставит, я эти безумные 300 мегабайт с сайта никогда и не качал! И всё равно впихивают 100500 контрольных панель, пунктов контекстного меню и прочего мусора! А у меня и ни одной 3D-программы то на компьютере нет. Ну, кроме фотошопа :)

lexa - 20/Ноя/2012 13:52

Ну почему же 300, всего 168.

И если качать самому, а не виндой - то можно лишнее оторвать.