Свежие комментарии

Title	Comment
Попробуйте погонять вот этот код (компилировать Nasm'ом) <co	Попробуйте погонять вот этот код (компилировать Nasm'ом) `; Processing speed on Core i7 2630QM (2GHz, Signle-Channel DDR3-1333 (PC3-10700)) ; * Data in memory: 8400 MB/s (300 MPix/s) ; * Data in L3: 11300 MB/s (400 MPix/s) ; * Data in L2: 11500 MB/s (410 MPix/s)` SECTION .rdata align(32) c1c0 dd 0.88, 0.77, 0.66, 0.55, 0.44, 0.33, 0.22, 0.11 c2c1 dd 1.04, 1.03, 1.02, 1.01, 0.88, 0.77, 0.66, 0.55 c0c2 dd 0.44, 0.33, 0.22, 0.11, 1.04, 1.03, 1.02, 1.01 SECTION .text global convert_pixels ; extern "C" void convert_pixels(const float* source, float* destination, size_t length) convert_pixels: ; rcx - source ; rdx - destination ; r8 - length vzeroupper align 32 .main_processing_loop: prefetchnta [rcx + 1408] vmovaps ymm1, [rcx] vmovaps ymm12, [rcx + 32] vmovaps ymm13, [rcx + 64] vmovaps ymm11, [rcx + 96] vperm2f128 ymm2, ymm1, ymm12, 00100000b vperm2f128 ymm3, ymm1, ymm12, 00100001b vperm2f128 ymm4, ymm12, ymm13, 00100000b vperm2f128 ymm6, ymm12, ymm13, 00100001b vperm2f128 ymm7, ymm12, ymm13, 00110001b vperm2f128 ymm8, ymm13, ymm11, 00100001b vperm2f128 ymm9, ymm13, ymm11, 00110001b vmulps ymm0, ymm1, [c1c0] vmulps ymm1, ymm1, [c2c1] vmulps ymm2, ymm2, [c0c2] vmulps ymm3, ymm3, [c1c0] vmulps ymm4, ymm4, [c0c2] vmulps ymm5, ymm6, [c1c0] vmulps ymm6, ymm6, [c2c1] vmulps ymm7, ymm7, [c0c2] vmulps ymm8, ymm8, [c2c1] vmulps ymm9, ymm9, [c0c2] vmulps ymm10, ymm11, [c1c0] vmulps ymm11, ymm11, [c2c1] vhaddps ymm0, ymm0, ymm1 vhaddps ymm2, ymm2, ymm3 vhaddps ymm4, ymm4, ymm5 vhaddps ymm6, ymm6, ymm7 vhaddps ymm8, ymm8, ymm9 vhaddps ymm10, ymm10, ymm11 vhaddps ymm0, ymm0, ymm2 vhaddps ymm4, ymm4, ymm6 vhaddps ymm8, ymm8, ymm10 vmovntps [rdx], ymm0 vmovntps [rdx + 32], ymm4 vmovntps [rdx + 64], ymm8 sub rcx, -128 add rdx, 96 sub r8, 32 jnz .main_processing_loop vzeroupper ret
Трехкилограммовый-то зачем. У меня ноутбук с i5, 8Gb памяти,	Трехкилограммовый-то зачем. У меня ноутбук с i5, 8Gb памяти, рейдом из SSD и великолепным дисплеем 13" весит всего кило двести (или триста, не помню).
А AVX то не блещит	Да, прирост производительности на AVX меньше 15%. И это при том что там легко наступить на грабли и получить performance degradation если какая-нибудь либа вставить SSE инструкцию. Одно радует, что можно хоть получить заметный прирост производительности за счёт быстрой памяти и высокой частоты проца. Думаю на твоей задаче, которая O(n), скорость памяти важней всего. Интересно посмотреть действительно ли поднятие частоты памяти дает прирост. Так же в свое время я пытался понять, как писать код чтобы воспользоватся преимуществами Dual-channel и Triple-channel памяти, но прироста не наблюдал... В системнике то вставлял планки, то вытаскивал.
Хы :) Иронию понял.	Хы :) Иронию понял.
ага, и у всех будут тонкие клиенты и вычисления будут на маш	ага, и у всех будут тонкие клиенты и вычисления будут на маштабируемых облаках, на квантовых компьютерах с 50 тысяч миллионов кубитов и кучей йобигерцов и йобибактов памяти.
Это да. Я вспомнил наш недавний разговор, и теперь я вижу, ч	Это да. Я вспомнил наш недавний разговор, и теперь я вижу, что для Ваших задач APU действительно могут оказаться очень интересны.
Ну тогда да, еще долгое время самые мощные и распространенны	Ну тогда да, еще долгое время самые мощные и распространенные стационарные и мобильные компы будут на x86 архитектуре. Но вот что меня гложет: В том же AMD E-350, который 18 ватт ест, встроенный GPU - 80 гигафлопс. Это немало.
Ну так там, хочется надеяться, и память общая у CPU и OpenCL	Ну так там, хочется надеяться, и память общая у CPU и OpenCL, т.е. можно будет опять оптимизировать хот-споты.
On location (где нетбук или планшет) задачи другие. На нетбу	On location (где нетбук или планшет) задачи другие. На нетбуке-планшете просто нет места для финальной обработки съемки. То есть там достаточно "95% качества" при приоритете скорости. А при постпроцессинге нужно "100% качества", многие даже мирятся с непроизводительными ожиданиями в первые секунды - и эти то секунды я и хотел бы убить.
Уверен, эти инструкции и используются в OpenCL реализации.	Уверен, эти инструкции и используются в OpenCL реализации.
Ну т.е. не от хорошей жизни требование такое, да? И тот же ф	Ну т.е. не от хорошей жизни требование такое, да? И тот же фотограф с большим удовольствием возил бы с собой легкий тонкий нетбук или планшет, а не 3-килограмовый ноутбук?
На ARM есть WMMX и NEON	На ARM есть WMMX и NEON
В теории. А на практике там (в ойпаде) такой геморой с полу	В теории. А на практике там (в ойпаде) такой геморой с получением RAW-файлов с камеры..... Есть Camera Connection Kit, SDK к нему я летом не нашел и наплевал.
Ну грубо говоря оттуда, что у (профессионального) фотографа	Ну грубо говоря оттуда, что у (профессионального) фотографа это будет маленькая часть общего бюджета.
Но это все очень "пока".	Но это все очень "пока".
Так как там экранчик отсилы в мегапиксель, то больше оного м	Так как там экранчик отсилы в мегапиксель, то больше оного мегапикселя и обрабатывать не надо. А откуда он взялся, это зум куска кадра или уменьшение существующего - несущественно. Другой вопрос, что этот рынок я не чувствую. Вот PhaseOne выпустили нечто для управления задником с ойпада, пользователи в восторге и так далее, но можно ли туда как-то влезть (и надо ли бежать со всех ног, или рыночное окошко еще долго будет) - я просто не понимаю.
Ну, iPad/Galaxy Tab image processing мог бы быть привлекател	Ну, iPad/Galaxy Tab image processing мог бы быть привлекательным, например
А откуда это требование взялось, если не секрет? "Мощный PC	А откуда это требование взялось, если не секрет? "Мощный PC или ноут"?
ARM - это же (пока) телефоны и планшеты?	ARM - это же (пока) телефоны и планшеты?
Интересно, да. Но эта обработка (если мы говорим о носимом г	Интересно, да. Но эта обработка (если мы говорим о носимом гаджете) должна в такоем случае, по-хорошему, занимать не более 100-200 мс на кадр. То есть, для кадра в 20 Mpix должна быть производительность по крайней мере в 100-200 Mpix/s, что для арма с его контроллером памяти мне кажется (по крайней мере пока) труднодостижимым.
У меня целевая платформа для процессинга RAW - мощный дескто	У меня целевая платформа для процессинга RAW - мощный десктопный PC и/или мощный ноут. OpenCL - хорошо, но пока политика - оптимизировать хот-споты, а не переписывать весь код.
А, ну про это я в курсе. Изображения интересно было бы обраб	А, ну про это я в курсе. Изображения интересно было бы обрабатывать и на ARM-ах.
Дак Вы тред-то почитайте, даже ссылки дадены. Обработка (в	Дак Вы тред-то почитайте, даже ссылки дадены. Обработка (в том числе потоковая) многопиксельных тяжёлых изображений (условно говоря, 20+ Mpix при 3*16 bit/pixel) Лёха, я не очень твой таргет переврал? ;)
А что за задачи?	А что за задачи?
Для Алексовых задач ARM явно не приспособлен. Вот Cell мог б	Для Алексовых задач ARM явно не приспособлен. Вот Cell мог бы, но...
А у меня общий вопрос: Вы ведь в курсе, что Win8 будет работ	А у меня общий вопрос: Вы ведь в курсе, что Win8 будет работать и на ARM? А там нет SSE инструкций. Зато есть OpenCL. И на x86 есть OpenCL.
Мои измерения показывают другое: http://alextutubalin.livejo	Мои измерения показывают другое: http://alextutubalin.livejournal.com/253179.html
MOVNTPS нужно использовать только для тех участков памяти, к	MOVNTPS нужно использовать только для тех участков памяти, которые не читаются в кэш. Если данные в кэше, прироста в скорости он не даст
Ну если интересуют подробности, то там жизнь устроена так (н	Ну если интересуют подробности, то там жизнь устроена так (насколько я прочитал чужой исходник и дискуссию вокруг него): Как бы хотелось: - смэпили память GPU в адресное пространство - и оттуда читаем очередную порцию данных, которая там образуется. Но - эта память приходится размэпливать (по дурости ATI) при каждом вызове вычислителя. - когда ее мэпишь заново, каждую страничку там pagefault, что сильно мешает жить. И один thread не успевает с такой частотой PF. Существуют хаки (бинарные) для драйверов 10.9 и 10.10, которые позволяют не размэпливать каждый раз, но эти драйвера, к сожалению, не работают с HD6xxx. В теории, хак для 10.10 работает с драйверами 11.2, но оный 11.2 с 6990 работает плохо (а формально - и не поддерживает). Короче, все от дурости.
Два раза - это два раза. Для блочного gemm - это два раза по	Два раза - это два раза. Для блочного gemm - это два раза по flops/mem. А по второму вопросу: ну да, данные можно породить прямо там генератором случайных чисел или нулями/константой залить. Случай же, когда мы несколько kernels пускаем на одних данных - он неинтересный с точки зрения общей теории всего. Объедините эти ядра в одно, пусть в уме, и у вас опять будут три возможных случая - flops/bytes растут с увеличением размера данных. Ура, надо просто задачу побольше - flops/bytes константа. Караул, надо "усложнять алгоритм" (переносить больше стадий на GPU), чтобы появился смысл. - данных пренебрежимо мало (подбор паролей, например). Опять ура. Второй случай типичен для всякой мультимедии, чем и нехорош.

Свежие комментарии

Pages