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

Правильно, но если взять SSEчто-то там версию, и упремся в память, то там уже все эти законы перестанут действовать, то есть дальше оптимизировать бессмысленно. Осталось только в память упереться, впрочем ты как раз и изучаешь, как это сделать.

Мне-то интересно, насколько реален такой сценарий в ближайшем будущем.

http://www.newegg.com/Product/Product.aspx?Item=N82E16813157273

Я что про это хочу сказать (пройдя в отладчике и поняв)
1) Идея отличная, работать должно быстро.
Но
2) То что мы 16 входных значений упаковали в 12 выходных - это для каких-то применений хорошо, а для последующей обработки в FP - категорически неудобно. Поэтому в моих реализациях 4-й компонент выхода обнулялся и это было спецально.

3) Конкретно в этом коде кажется есть ошибка (проверил дважды, вроде в _mm я все правильно перенес) от которой в ymm4 на выходе неправильно.

Оно не все так радужно, то есть 4 потока не дают учетверения. Где-то двухсполовинивание, причем я именно о С-шном коде, который в память не уперт.

Ну а дальше правило Амдала тоже серьезно начинает мешать.

http://www.newegg.com/Product/Product.aspx?Item=N82E16813186212

Ну это в ойпаде. Рынок вот только что начал заваливаться уже более-менее сносными 10" планшетами на honeycomb. У некоторых есть usb-host. Я вот уже думаю о том, чтобы в отпуск брать что-то типа asus transformer, у которого есит нормальный клавиатурный док с батарейкой, несколько нормальных usb-портов и usb-host. Софт для первичной сортировки RAW'ов на более-менее сносном экране тут бы вполне сгодился. Не то, чтобы очень-очень надо, но бывают моменты когда делать всё равно нечего - почему бы и не?

Насколько я помню схемотехнику, как раз нули должны греться сильнее. По идее.

Так это, а у твоей целевой аудитории разве не по 4+ ядра в тачке стоит? То есть достаточно, чтобы один поток мог использовать где-то четверть псп памяти и дальше в общем-то все равно. А задача вроде как параллелится только в путь.

PS: Ты на C-blocks смотрел?

содержимое. легко проверяется вливанием потока 0xff

Тьфу. Micro-ATX поставить некуда, а mini-ITX не вижу в продаже.

Не надо гнать в ЖЖ в 7 утра спросонья.

Не говоря о том, что не у всех юзеров Core i7 @4.5Ghz, а если целиться еще и в машину 4-летней давности, как мой ноут (Core2 T7500), то там еще чуть не на порядок все медленнее.

Попробую, но пока не понимаю что он делает, тем паче что передача параметров через регистр с инфраструктурой C++ как-то плохо совместима, ну да придумаю что-нибудь.

Я так для себя понял, что AVX - это тот же dual issue SSE, только поставленный в ряд.

Вместе с тем, если генерировать SSE-код из тех же макросов (а не AVX), то скорость получается заметно ниже и начинает зависеть от компилятора. Скажем, для _load1 без префетча и компилятора intel - 316Mpix вместо 527 (c префетчем - возвращается).

Т.е. граблей тут густо разложено.

А оно реально надо? Ну то есть 500 vs 600 vs 700? Все одно, через года через полтора-три оно удвоится/учетверится, в кэш влезет вообще вся картинка и оно достигнет статуса "да пофиг, все достаточно быстро".

PS: Вспоминая mp3/mpeg1 на 486, где декодер оного действительно в проц упирался, но с появлением P/PII проблема рассосалась сама собой.