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

Сенсоры в D3X и a99 - разные по обвязке.

http://www.bythom.com/nikond3xreview.htm

это есть в спецификациях матрицы сониной (для матриц 12мп кроп и 24мп ФФ)

По-моему про "доп считывание сигнала с матрицы" - это какая-то ересь.

тут становится интересно еще вот что: народ баянит (http://www.photoclubalpha.com/2012/12/27/sonys-alpha-99-mastery-wrapped-...),
что обещанные 14 бит работают также как в D3X - доп.считыванием сигнала с матрицы и соотв. растет лаг закрытия затвора (точнее открытия обратно)
и при серийной съемке обратно 12 бит (7 т.е.;-)

Не, просто принципы же другие. Кросс-корреляция и прочие 4:1:1 они как-то физиологичны.
А тут - все тупо и банально.

Глянул в википедии - вроде ничего похожего.
DXT вроде как основан на кросс-корреляции цветов, а тут, наоборот, каждый компонент жмется независимо.

Напоминает DXT сжатие

Fuji - нет, не прокомментирую.

А вот сравнение с Sony, точнее саму Sony, сейчас прокомментирую, давно собирался, руки не доходили написать пост. Сейчас еды поем - и напишу.

Комрады, 'zfs best practice' при создании массивов raidz[i] заключается в том, чтобы количество дисков массива, за минусом четности, равнялось степени двойки, тогда достигается оптимальное распределение блоков данных при чтении/записи по дискам массива. Т.е. для массива raidz1 оптимальными по быстродействию являются конфигурации:
2+1 = 3диска;
4+1 = 5 дисков;
8+1 = 9 дисков.
Для массива raidz2:
2+2 = 4 диска;
4+2 = 6 дисков;
8+2 = 10 дисков.
Для raidz3 - соответственно.
Создавать vdev raidz[i] из более чем 8+i физических дисков - не рекомендуется, для большего числа дисков рекомендуется создавать страйпы из vdev raidz[i].
Таковы официальные рекомендации от разработчиков, приведенные в документации Oracle (Sun).

я скорее о legacy коде.

Ну вот есть, к примеру, dcraw. В ней есть буквально 5-8 мест, которые тормозят, ну 10.
Все эти 10 мест - без насилия над остальным кодом (9500 строк) - ускоряются в 3-4 раза ручной векторизацией и еще в 3-4 раза распараллеливанием. Получается отлично.

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

Именно. Год назад Energizer на eBay стоили где-то $1.3 с доставкой, а сейчас - $55 за 20, т.е. те же 60 рублей.

Смысл остался только в синеньких.

Ну да.

Но чем вручную делать векторизуемый (конкретным) компилятором код - я вот лучше тупо нахреначу 5 команд _mm.

Да, это меня поимеет, когда я начну переносить на ARM. Но пусть лучше поимеет путем некомпилируемости, чем тем, что векторизуемый (одним компилятором) код окажется скалярным на другом компиляторе.

Потому что с точки зрения семантики C++ они не эквивалентны: после выполнения goto skip_block код никогда не загружает остальные пискелы/компоненты пикселов, и компилятор не может опеределить, что обращаться к остальным компонентам безопасно (т.е. не сгенерирует Access Violation).

Да, конечно, lexa@lexa.ru
Но обычно я даю ответы в духе "пробовать надо".