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

Спасибо за информацию, тоже хотел подобную штуку покупать, теперь не буду

Я, собственно, клоню к тому, что во втором десятилетии 21-го века, когда гигабайт RAM стоит примерно $6, вся эта экономия на памяти и на математическом сопроцессоре - устарела до черезвычайности.

надо начать с того, что оптимизация для десктопных процессоров в большинстве случаев не нужна ;)
(а для недесктопных код из dcraw может иметь смысл)

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

Вещественные описываются точно так же. На той же странице: "The vector_size attribute is only applicable to integral and float scalars". Только, как и в случае с ручным кодингом на intrinsics (по сути, на ассемблере), надо помнить о выравнивании на размер всего вектора при ручном выделении памяти. Запаковывать/распаковывать вектора можно как обычно, через union, например. Документация, к сожалению, крайне скудная, но примеры нагуглить можно, типа такого http://stackoverflow.com/questions/4596912/sse-simd-extensions-support-i...

Я по ссылке вижу только целые вектора.

Где поподробнее почитать.

Да, согласен, кривовато.

Насколько я понимаю, это и есть скорость мысли, т.е. пропускная способность подсистемы памяти. Скорость записи из процессора в ОЗУ.

Я не знаю про RPP, а обычно проблема в том, что подобных хот-спотов не один, а пара десятков, причем треть из них - в чужих компонентах (например, в color management engine), еще треть - в подготовке/приеме данных для/от этих чужих компонент и только треть - своя.

И получается, что не сделав свою *быструю* CMS - ничего и не получится. А это - тот еще геморой.

А промежуточные результаты как хранить? Вопрос, собственно, в этом.

Ну вот, к примеру, фотошоп. Сделали "действие". На старте было 16 бит, на выходе - 16 бит. Промежуточная математика - допустим в 32, но проблема то не в ней.

Да, естественно, если мы боремся за влезает/не влезает в кэш (или "влезает в L1/влезает в L2"), то жизнь другая совершенно. Или если мы боремся за bandwidth памяти/диска, что тоже часто встречается.

А вот конкретно с (единичными) картинками - не так. В кэш в любом случае не влезет (а что влезет - то обрабатывается с "достаточной скоростью"), а ситуация, когда ограничены bandwidth диска - неинтересная на практике т.к. в память то влезет.

Про кино - не знаю, мало опыта.

если применять основную мысль (legacy data types) к обработке изображений, то она верная, т.к. в основном это stream processing и задача легко влезает в память.

вообще говоря, конечно же нет. скажем, используя char и short вместо int и long можно добиться более высокой плотности хранения данных, соответственно больше данных можно впихнуть в кэш для тех алгоритмов, где есть смысл кэшировать.

ну и конечно есть море задач, где лучший тип данных это вообще vector(bool) или bitset, куда запакован массив int, обрезанный по макс. битовой ширине. опять же, из соображений кэша или нехватки памяти.

не, они комуницируют сообщениями через сокет (локальный или tcp).
авторы шлимыла хоть и пидорасы, но мозги у них какие-то есть

Несмотря на мое уважение к современным кодогенераторам, совершенства нет.

Из личного опыта:
* dot product не распознают, соответственно инструкцию такую не ставит.
* я не понимаю, что такое я должен написать на С, чтобы транспонировать матрицу 4x4 столь же эффективно, как _MM_TRANSPOSE4_PS (а это оказалось ключевым местом в деле "наложения поканальной кривой")

Из чужого опыта: умножают матрицы таки kernel-ом на ассемблере (SSE и т.п.), а не доверяют кодогенератору. Потому что добиться ровно блока 8x2 (к примеру) прагмами разворотов цикла сильно сложнее, чем руками это место закодировать.

Ну и всякая fast math (синус-косинус-экспонента-логарифм), в лучшем случае тебе сделают обращение к SVML, а всякие узкоспециальные случаи (вроде того, что заранее известен входной диапазон) - никак не поддержаны.

Я думаю (опираясь на свои старые опыты с цветокоррекцией на HLSL/GLSL) что настоящий ништяк наступит когда можно будет гнать на видимокарту слегка может быть причесанный RAW, а обратно получать уже RGB и максимум разве что профиль прикладывать. А так эти ваши туда-сюда совершенно не прикалывают.

вот конкретно в протоколе милтера проблемы нет.
но из-за кривых рук можно сказать не работает

я, если что, практические наблюдения имею