По первым двум пунктам все ясно. Неясно, почему для stm предлагается отдельный синтаксис (расширение С++), а для обычной критической секции — нет. Мне кажется, что уж если делать, то целиком для всех. Тем более, что HLE все равно все скроет.
Вопросы от полного дилетанта в этой теме:
-а какой прирост производительности от этого чуда ожидается на каких-нибудь известных задачах?
-"Производители процессоров давно облизывались на поддержку Transactional Memory в железе. Это потенциально решило бы проблемы с производительностью" -это ведь только в случае сильно многопоточных приложений, да?
и еще более глупый вопрос: а чем синтаксис транзакций может\должен отличаться от синтаксиса критической секции? она тоже определяет область кода, внутри которой,… хотя там внутри и совсем другой механизм, но для программиста в чем разница?
Спасибо, Ты меня вдохновил на написание подобной истории про 3d графику :)
Но меня очень удивил прирост производительности от MMX в 3-4 раза. я могу поверить только в 2, для остального нужны пояснения :)
и еще — фильм такой есть «День Выборов». Там одного персонажа просят убрать последнюю (нецензурную) строчку предвыборного стихотворения. Но он отказывается, говоря, что все оно только ради последней строчки и писалось.
Так вот, можете считать, что весь пост и писался ради заключительного приглашения на вебинар :)
Это не хамство, а невозможность объяснить в паре предложений то, что объясняется вкратце за час. Я же сказала, braindamaged не прав во всем :) Внутри процессора нет ассемблера; отказаться от скалярных инструкций нельзя, так как не весь код можно сделать векторизуемым, а компиляторы, причем, не только Intel давно и успешно автоматически генерируют векторные инструкции в подавляющем большинстве случаев из тех, когда это теоретически возможно.
Открою секрет — приведенный здесь код был ориентирован на компилятор gcc, которому действительно надо помогать. Поэтому мерить надо семь раз — для разных систем :)
Давайте пойдем с другого конца. Можете привести пример кода, который НЕ будет свекторизован в SSE4.x, хотя, вроде-бы, должен? Будем разбираться.
А в общем случае, берем программу, скомпилированную с /QxSSE4.x, в которой точно НЕ используются интринсики и проверяем ее с помощью SIMD Check (про нее я упоминала здесь — habrahabr.ru/company/intel/blog/94381/ ). Программа показывает наличие векторных SSE4 инструкций, что и означает автовекторизацию.
Поддерживают. Но надо учесть, что для этих типов данных имеются не все операции, существующие для float. Плюс есть не все преобразованиям типов. Следовательно, будут векторизованы не все такие циклы.
К ссылкам на wiki добавлю ответ vikky :): совершение одной командой нескольких однотипных действий над данными. Типа сложить попарно четыре пары чисел и получить четыре суммы.
Первые два предложения комментария — истина. Остальное — никак нет. Объяснять подробнее здесь не буду.
Вам прямая дорога на мой вебинар. Если нет времени 27ого, то через несколько дней будет доступна его запись.
Ну кто-то же должен обернуть, например, каждую итерацию цикла в функцию, потом куда-то ее вынести и скомпилировать отдельной библиотекой, потом надо решить проблему передачи данных туда — выделить для этого память, потом… короче, В итоге мы придем к OpenCL :)
Если мы говорим про работу на CPU, то там все просто. В основе всех библиотек — нативный интерфейс работы с потоками ОС, так что в принципе все библиотеки распараллеливания на CPU «взаимозаменяемы» — то есть, теоретически возможно взять интерфес одной и звать внутри начинку от другой. Но интерфейс каждой из них заточен под внутреннюю структуру (или наоборот:) — то есть, вышеупомянутая штука будет немного медленнее или сильно медленнее, чем это возможно (при вызове быстрейшей библиотеки).
Если же включить сюда и GPU, то нам нужны: код для CPU, специально скомпилированный особым компилятором код для конкретного GPU плюс блок, загружающий этот код на GPU и обрабатывающий потом результаты. Как это можно сделать автоматически, да еще и в рантайме из одного исходного кода, не зная, что куда — я не представляю.
спасибо, это не по злому умыслу, а по недосмотру.
Сейчас поправлю.
Но отдельным пунктом недостатки тут выносить не хочется — они уместны в тексте, прсто выделю жирным и добавлю.
Вы вот тоже опечатались clock вместо cilk написали :)
-а какой прирост производительности от этого чуда ожидается на каких-нибудь известных задачах?
-"Производители процессоров давно облизывались на поддержку Transactional Memory в железе. Это потенциально решило бы проблемы с производительностью" -это ведь только в случае сильно многопоточных приложений, да?
и еще более глупый вопрос: а чем синтаксис транзакций может\должен отличаться от синтаксиса критической секции? она тоже определяет область кода, внутри которой,… хотя там внутри и совсем другой механизм, но для программиста в чем разница?
Но меня очень удивил прирост производительности от MMX в 3-4 раза. я могу поверить только в 2, для остального нужны пояснения :)
Так вот, можете считать, что весь пост и писался ради заключительного приглашения на вебинар :)
А в общем случае, берем программу, скомпилированную с /QxSSE4.x, в которой точно НЕ используются интринсики и проверяем ее с помощью SIMD Check (про нее я упоминала здесь — habrahabr.ru/company/intel/blog/94381/ ). Программа показывает наличие векторных SSE4 инструкций, что и означает автовекторизацию.
Вам прямая дорога на мой вебинар. Если нет времени 27ого, то через несколько дней будет доступна его запись.
А это вы в теории им восхищаетесь или на практике? От этого много чего зависит :)
Если же включить сюда и GPU, то нам нужны: код для CPU, специально скомпилированный особым компилятором код для конкретного GPU плюс блок, загружающий этот код на GPU и обрабатывающий потом результаты. Как это можно сделать автоматически, да еще и в рантайме из одного исходного кода, не зная, что куда — я не представляю.
Сейчас поправлю.
Но отдельным пунктом недостатки тут выносить не хочется — они уместны в тексте, прсто выделю жирным и добавлю.
Вы вот тоже опечатались clock вместо cilk написали :)
ArBB — это монстр :), соответственно, ему нужны тяжелые монстровые задачи.
Вот это я и имела в виду. Не факт, что стоит возиться. Я совсем не против OpenCL, но надо быть объективным.
Спасибо за отличный комментарий.
я знала, что кто-нибудь это обязательно попросит :) Но это проще попросить, чем сделать. Буду думать.