цвет и материалы (ektar)

п.20

Alex Tutubalin, я робею вступать с вами в разговор, но быть может вы объясните всем нам, в каких попугаях мерили отклик ЦФК?
Почему ваши графики не похожи на графики других озабоченных и попытавшихся такие графики нарисовать? У одних график похож визуально на нижнюю половинку типичной ХК плёнки. У других на верхнюю половинку. У вас просто прямая.

Цитата:

от: nebrit
Alex Tutubalin, я робею вступать с вами в разговор, но быть может вы объясните всем нам, в каких попугаях мерили отклик ЦФК?

В цифирках, записанных в RAW-файлы. Со всеми их тараканами (вроде неотключаемого шумопонижения в некоторых камерах).

Если эти RAW были записаны со сжатием светов (как это делает Sony в последних камерах, Nikon в младших камерах, делал Kodak в некоторых камерах) - то после их разжатия обратно. Т.е. в линейной ("энергетически линейной") шкале.

Собственно, фотосенсоры, пока не переполнился пиксель (и если забыть про шумы) - они весьма линейны. Есть "квантовая эффективность", она же вероятность из фотона определенной энергии (длины волны) получить электрон. От величины накопленного в ячейке (пикселе) заряда эта эффективность не зависит. А дальше нужно просто донести эти электроны до АЦП (или усилителя перед АЦП) не расплескав.

Цитата:

от:nebrit

Почему ваши графики не похожи на графики других озабоченных и попытавшихся такие графики нарисовать? У одних график похож визуально на нижнюю половинку типичной ХК плёнки. У других на верхнюю половинку. У вас просто прямая.

Подробнее

У "других озабоченных" бывают просто феноменальные графики. Например, просто цифирки из TIFF/JPEG, даже без осознания того простого факта, что в TIFF-JPEG данные обычно гамма-корректированные, а не линейные.

Ну а в массе своей - это просто графики после Adobe Camera Raw, после применения тоновых кривых и "скрытых экспокоррекций", которые там есть даже если все движки выведены в 0.

Цитата:

от:Alex Tutubalin
Собственно, фотосенсоры, пока не переполнился пиксель (и если забыть про шумы) - они весьма линейны. Есть "квантовая эффективность", она же вероятность из фотона определенной энергии (длины волны) получить электрон. От величины накопленного в ячейке (пикселе) заряда эта эффективность не зависит. А дальше нужно просто донести эти электроны до АЦП (или усилителя перед АЦП) не расплескав.

Подробнее

Это теория. Так должно быть. Полагаю, из этого вы исходили, когда программу писали?
Или же это установлено вами в ходе опыта?
Побаиваюсь дискутировать, потому что не качал вашу программу, ни бельмеса не понимаю, только мельком взглянул на ваш сайт и давай выводы делать и каверзные вопросы задавать. Нехорошо как-то.
Например, ISO 50 и ISO 100 в камере Canon 5D Mark II оказываются одной и той же чувствительностью - написано на вашем сайте. На моих глазах товарищ в ручном режиме, накрутил полярик на свою цифрУ, не меняя диафрагмы (забыл, а это почти минус полтора стопа), чпокнул меня - всё нормально. Добавил полтора стопа - опять нормально. Камера всё равно вмешивается в процесс. Как же можно что-то там мерить?

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

Цитата:

от: nebrit
Это теория. Так должно быть. Полагаю, из этого вы исходили, когда программу писали?
Или же это установлено вами в ходе опыта?

Да, для Canon 5D mk2 я мерял линейность. И для Nikon D800. Линейно - в тех рамках, в которых написано выше.

А программа - не исходит из каких-то подобных предположений, а, напротив, показывает данные "как есть" (как извлечено из RAW)

Цитата:

от: carik
и в таком пояснении мы всё равно упираемся в примерно следующее?:
широкий входной дд не даёт нам большей фш (чистые тени и детализированные света) чем у негатива например?

У хороших современных ЦФК, на низких ISO фотоширота "достаточная" для большинства применений, кроме поминавшегося мной страниц 30 назад "жесткого контровика".

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

Если учитывать этот факт (резкое и полное пропадание деталей в светах) при экспонировании - со светами становится все хорошо. В рамках возможностей (динамического диапазона) камеры.

Цитата:

от:carik

физическая способность матрицы фиксировать информацию теряется в самой же камере при обработке шимодовами и сжатием светов, а что же происходит с цветом? почему "большая линейность" матрицы не способна выдать нормальный цвет? про качество цвета вообще молчу...

Подробнее

"Качество цвета" определяется
а) способностью сенсора "разделять цвета" т.е. давать разный сигнал для разных (с точки зрения человека) цветов.
б) качеством описания этого самого цвета т.е. "цветовыми профилями камеры"
в) наличием шума (который, особенно в тенях, может дать "невозможные" цвета т.е. такие сигналы, которые никакому разумному цвету не соответствуют)
г) интерполяцией значений пикселов (каждый пиксел же - одноцветный), что тоже может дать на выходе "невозможные" цвета.
д) округлениями/обрезанием диапазона значений на промежуточных стадиях при обработке RAW.
е) Поведением конвертора в ситуациях, когда в одном из каналов значения "легли на полку" (их обрезали в камере или при обработке). Это, конечно, только про света.

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

Цитата:

от: Alex Tutubalin
Для понимания используемого инструмента - в первую очередь.

Что понять-то хотим? Вот я, предположим, понимаю, как пользоваться телевизором, но не понимаю, как он устроен. Это считается как: я понимаю этот инструмент (телевизор) или нет?

Цитата:

от: Alex Tutubalin
Я в предыдущем сообщении дописал: критически-важным это понимание становится, когда у вас несколько разных камер и хочется получать предсказуемые результаты.

Ага, я услышал хорошее слово - предсказуемые. Можете описать процедуру предсказания, отличную от "взяли камеру, отсняли тесты, сравнили результаты"? Ну, то есть, как-то там по цифрам из raw предсказать и т.д. И какая процедура будет проще?

Цитата:

от:Alex Tutubalin
Я тут ввязался очередной раз в эту дискуссию увидев обсуждение линейности ЦФК. И - для тех кому интересно, какая же там на самом деле линейность - рассказал, как оно на практике устроено. И как - если интересно "как оно на самом деле" - эту линейность посмотреть, какой есть удобный втч. для этого инструмент.

Соответственно, либо мы обсуждаем вопрос линейности (не слишком интересный, ибо там действительно все линейно в достаточно широком диапазоне, особенно если не вдаваться совсем уж в детали, вроде сенсоров Aptina или тоновых кривых у Sony), либо обсуждаем "а зачем фотографу про это знать".

Подробнее

Второй вопрос на мой взгляд куда более интересный. И больше того, в свете второго вопроса и первый может иметь хоть какой-то практический смысл помимо чистого незамутненного любопытства.

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

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

Цитата:

от:Alex Tutubalin
По второму вопросу: я тут недавно (с месяц назад) читал статью какого-то журналиста о дефектах современного образования. Дескать, детишек заставляют заучивать всякие гадости, которые в реальной взрослой жизни вообще никогда не понадобятся. И все бы ничего (я с самим посылом тоже не согласен, но это не имеет значения), но в качестве примера "ненужной гадости" была использована таблица умножения. Тут я просто потерял дар речи и даже в комментариях под статьей не смог ничего написать. С человеком, который не понимает зачем таблица умножения ("если есть калькуляторы") - я просто не найду общего языка, мы ортогональны.

Подробнее

Я очень удивлен, что вы не видите разницу между фундаментальным знанием и специальным. Таблица умножения и многие другие вещи, которым учат (или должны учить) в школе - фундаментальные. Какие-то из них, может быть, непосредственно на практике никогда в жизни не понядобятся, но они необходимы для дальнейшего познания и делают знание системным, связанным, а не обрывочным набором сведений. А вот специальное знание нужно соответствующим специалистам. Возьмем близкую вам область. Вот, например, прикладному программисту совершенно не нужно знать микрокод процессорных команд. И даже машинный-ассемблерный код ему знать не нужно, все необходимое сделает компилятор. Абстрактного представления о том, что есть процессор и т.п., вполне достаточно. Даже детали, вроде разницы между кэшем и основной паматью многим знать не нужно, а тем, кому нужно, достаточно, опять-таки, знать, что она есть и потому лучше не писать низкоуровневый код самому, а поискать готовую оптимизированную библиотеку.

И ладно бы это специальное знание было просто бесполезным. Так оно действительно бывает вредным. Мало того, что на его приобретение затрачивается время, которое лучше бы пустить на что-то другое. Хуже всего, что оно (наверное, потому, что у неспециалиста оно редко бывает по-настоящему полным и связным) формирует ложное представление и ложные цели.

Цитата:

от:Alex Tutubalin
Если эти RAW были записаны со сжатием светов (как это делает Sony в последних камерах, Nikon в младших камерах, делал Kodak в некоторых камерах) - то после их разжатия обратно. Т.е. в линейной ("энергетически линейной") шкале.

Подробнее

В "энергетически линейной" или все же после логарифмирования? Т.е., линейна связь экспозиция-цифра или логарифм экспозиции - логарифм цифры? Одновременно они будут линейными только если коэффициент усиления ("виртуальный" - т.е., из сигнала в цифру) равен единице.

А, тут сообразил, что так и будет - раз нелогарифмированные величины пропорциональны, то и логарифмы будут линейны с коэффициентом 1.
Цитата:

от:Alex Tutubalin
Собственно, фотосенсоры, пока не переполнился пиксель (и если забыть про шумы) - они весьма линейны. Есть "квантовая эффективность", она же вероятность из фотона определенной энергии (длины волны) получить электрон. От величины накопленного в ячейке (пикселе) заряда эта эффективность не зависит. А дальше нужно просто донести эти электроны до АЦП (или усилителя перед АЦП) не расплескав.

Подробнее

Ну вот да, я в предыдущем сообщение написал, что линейность там просто потому, что так получается, а не потому, что кто-то к ней специально стремится. Правильно, стало быть, написал?

Цитата:

от:Сергей Катковский

Ага, я услышал хорошее слово - предсказуемые. Можете описать процедуру предсказания, отличную от "взяли камеру, отсняли тесты, сравнили результаты"? Ну, то есть, как-то там по цифрам из raw предсказать и т.д. И какая процедура будет проще?

Подробнее

С цифровыми камерами - в силу их внутренней линейности - гораздо проще изучить исходные данные.

Очень важная процедура предсказания, к примеру, это калибровка экспонометра (или чувствительности) камеры. В силу "линейности с резким изломом" ЦФК, действительно важный вопрос ровно один - где находится "среднесерый" в RAW-данных. Или, то же самое, но другими словами, "сколько стопов у нас между среднесерым экспонометра и точкой насыщения/обрезания сенсора".
Предлагаемая мной/нами (командой LibRaw LLC) методика описана тут: http://www.rawdigger.ru/houtouse/lightmeter-calibration
Она простая и для каждого освещения дает одно(три) числа - headroom камеры (по каналам).

Если делать то же самое, но с конвертором - вас приятно порадуют скрытые экспокоррекции в конверторах.


Цитата:

от:Сергей Катковский

Теперь хорошо это или плохо, линейность. Не то, чтобы очень плохо, но и не совсем хорошо. Вот, например, поскольку у нас целочисленное представление, на стоп в светах у нас приходится 2 в большой степени цифровых градаций, а на стоп в тенях - ну, скажем, четыре. А вот мне бы, как фотографу, было бы лучше, если бы в тенях градаций было побольше, чего можно добиться только нелинейностью, подняв контраст в тенях и, соответственно, понизив его в остальной области

Подробнее

Да, на мой взгляд линейность - это не слишком хорошо. Это и лишние, абсолютно не нужные, градации в светах и недостаток их в тенях.
И, естественно, эта линейность получается в силу конструкции сенсора.

Другой вопрос, что сильно лучше не сделать. Вот скажем 5DMkII, который я лучше всего знаю. На 400ISO там уже считаются единичные электроны, один электрон - одна единичка из АЦП. То есть если мы хотим больше градаций в тенях - нужно дольше экспонировать (т.е. "понижать чувствительность").
Ну или повышать квантовую эффективность, но она и так довольно высокая (что-нибудь 0.6 после цветоделительных фильтров). Или увеличивать размер пикселя т.е. при сохранении размера кадра - снижать разрешение. Или повышать пропускную способность фильтров (что и делают/делали) - теряя в "качестве цвета".

Везде клин.


Цитата:

от:Сергей Катковский

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

Подробнее

Да-да. Именно. Именно поэтому FastPictureViewer (и многие другие, я их в последние пару месяцев пересмотрел много) процессит 21-Mpix файл за ~4секунды /речь именно о RAW, по кнопке R он его показывает/ (и я знаю что у них у всех там за код). Сильно оптимизированная LibRaw - 800ms (+300 на декодирование, всего 1.2s). А еще "немножко" оптимизированный варез, который мы сейчас тестируем - укладывается в 80ms (и время на декодирование - спрятано). На одном и том же оборудовании, заметим.

80ms - это 'instant', а 4 секунды - это час потеряного впустую (отойти - нельзя) времени на каждые 900 просмотренных кадров (а свадебные, к примеру, съемки бывают и больше)

И это тот самый эффект - прикладной программист играет как умеет, а оптимизированных библиотек в данной конкретной предметной области не оказалось, негде взять.

Цитата:

от:Alex Tutubalin
С цифровыми камерами - в силу их внутренней линейности - гораздо проще изучить исходные данные.

Очень важная процедура предсказания, к примеру, это калибровка экспонометра (или чувствительности) камеры. В силу "линейности с резким изломом" ЦФК, действительно важный вопрос ровно один - где находится "среднесерый" в RAW-данных. Или, то же самое, но другими словами, "сколько стопов у нас между среднесерым экспонометра и точкой насыщения/обрезания сенсора".
Предлагаемая мной/нами (командой LibRaw LLC) методика описана тут: http://www.rawdigger.ru/houtouse/lightmeter-calibrat...
Она простая и для каждого освещения дает одно(три) числа - headroom камеры (по каналам).

Подробнее

Да-да, хороший инструмент. Для исследователя. Но вот здесь присутствует фотограф с ником nebrit - ему надо "красиво" (более четкого критерия я от него не добился). Вот он получил по вашей методике три числа. Ему с ними что делать?

Цитата:

от: Alex Tutubalin
Если делать то же самое, но с конвертором - вас приятно порадуют скрытые экспокоррекции в конверторах.

Скажите, а как меня порадуют скрытые экспокоррекции в конверторах, если я калибрую одним софтом, а для картинок пользуюсь другим? Я это смогу предсказать?

Цитата:

от:Alex Tutubalin
Да, на мой взгляд линейность - это не слишком хорошо. Это и лишние, абсолютно не нужные, градации в светах и недостаток их в тенях.
И, естественно, эта линейность получается в силу конструкции сенсора.

Другой вопрос, что сильно лучше не сделать. Вот скажем 5DMkII, который я лучше всего знаю. На 400ISO там уже считаются единичные электроны, один электрон - одна единичка из АЦП. То есть если мы хотим больше градаций в тенях - нужно дольше экспонировать (т.е. "понижать чувствительность").
Ну или повышать квантовую эффективность, но она и так довольно высокая (что-нибудь 0.6 после цветоделительных фильтров). Или увеличивать размер пикселя т.е. при сохранении размера кадра - снижать разрешение. Или повышать пропускную способность фильтров (что и делают/делали) - теряя в "качестве цвета".

Подробнее

Вот видите, как получается - линейность сама по себе - это ничего особо хорошего. Поменять ее мы тоже не можем. Чего же мы тогда к ней привязались-то?


Цитата:

от:Alex Tutubalin
Да-да. Именно. Именно поэтому FastPictureViewer (и многие другие, я их в последние пару месяцев пересмотрел много) процессит 21-Mpix файл за ~4секунды /речь именно о RAW, по кнопке R он его показывает/ (и я знаю что у них у всех там за код). Сильно оптимизированная LibRaw - 800ms (+300 на декодирование, всего 1.2s). А еще "немножко" оптимизированный варез, который мы сейчас тестируем - укладывается в 80ms (и время на декодирование - спрятано). На одном и том же оборудовании, заметим.

80ms - это 'instant', а 4 секунды - это час потеряного впустую (отойти - нельзя) времени на каждые 900 кадров.

Подробнее

И что вы хотите этим примером сказать? Авторам FastPictureViewer как-то помогло бы знание деталей процессора? Или им все-таки стоило получше разобраться с алгоритмами в своей предметной области?

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

Мой приятель пытался своей не самой плохой камерой снять какой-то мраморный бюстик - помучился и плюнул. Такая фигня получается... Вот ему бы пригодились кое какие знания о ХК его камеры и как её обуздать.

Цитата:

от: nebrit
Странное дело: я по диагонали пробежался по сайту Алексея - оказывается шум бывает не только в тенях, но и в светах. И соответственно давится всякими шумодавами. Или я сейчас пургу гоню?

Шум бывает везде, просто где-то он заметен больше, где-то меньше.

Цитата:

от: Сергей Катковский
Вот видите, как получается - линейность сама по себе - это ничего особо хорошего. Поменять ее мы тоже не можем. Чего же мы тогда к ней привязались-то?

+100

Цитата:

от:nebrit
Мой приятель пытался своей не самой плохой камерой снять какой-то мраморный бюстик - помучился и плюнул. Такая фигня получается... Вот ему бы пригодились кое какие знания о ХК его камеры и как её обуздать.

Подробнее

И как бы они ему помогли?

Ваш приятель не пробовал снимать с эксповилкой этот бюстик? Если пробовал, и все равно не получилось - дело не в камере (ибо сдвиг на пару стопов уж точно перебросит вас из проблемной области в любимую линейную), а в чем-то другом. В освещении этого бюстика, например. Что наиболее вероятно.

Цитата:

от: Сергей Катковский

Но вот здесь присутствует фотограф с ником nebrit - ему надо "красиво" (более четкого критерия я от него не добился). Вот он получил по вашей методике три числа. Ему с ними что делать?

Надо красиво - так снимайте красиво.

Понятно что все эти упражнения с ХК - помогут только и исключительно внятному управлению экспозицией. А управлять ей надо - только если знаешь чего конкретно (ну, к примеру, по Адамсу) хочется добиться.
Цитата:

от: Сергей Катковский

Скажите, а как меня порадуют скрытые экспокоррекции в конверторах, если я калибрую одним софтом, а для картинок пользуюсь другим? Я это смогу предсказать?

Вы это сможете увидеть (увидев к конверторе совершенно неожиданные цифирки/гистограммы/картинки). А увидев - использовать или обратно скомпенсировать, благо ручка то есть.

Цитата:

от: Сергей Катковский

Вот видите, как получается - линейность сама по себе - это ничего особо хорошего. Поменять ее мы тоже не можем. Чего же мы тогда к ней привязались-то?

А я не знаю, что вы к ней привязались. Я тут в очередной раз появился клюнув на дискуссию о линейном участке ХК цифровой камеры.

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

Цитата:

от:Сергей Катковский

И что вы хотите этим примером сказать? Авторам FastPictureViewer как-то помогло бы знание деталей процессора? Или им все-таки стоило получше разобраться с алгоритмами в своей предметной области?

Подробнее

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

Цитата:

от:Alex Tutubalin
Цитата:

от:Сергей Катковский
Но вот здесь присутствует фотограф с ником nebrit - ему надо "красиво" (более четкого критерия я от него не добился). Вот он получил по вашей методике три числа. Ему с ними что делать?

Подробнее

Надо красиво - так снимайте красиво.

Подробнее

О, хороший ответ. Я тоже так ответил.

Цитата:

от:Alex Tutubalin
Понятно что все эти упражнения с ХК - помогут только и исключительно внятному управлению экспозицией. А управлять ей надо - только если знаешь чего конкретно (ну, к примеру, по Адамсу) хочется добиться.

Подробнее

Э-э, погодите. По Адамсу - это, например, как? Скажем, "по Адамсу" - это "экспонируй по теням, проявляй по светам", но это с ЦФК и его линейной и неизменной характеристикой и не нужно, и невозможно. Или под управлением понимается лишь "как снять, чтобы не выбило света"?

Цитата:

от: Alex Tutubalin
Цитата:

от:Сергей Катковский
Скажите, а как меня порадуют скрытые экспокоррекции в конверторах, если я калибрую одним софтом, а для картинок пользуюсь другим? Я это смогу предсказать?

Вы это сможете увидеть (увидев к конверторе совершенно неожиданные цифирки/гистограммы/картинки). А увидев - использовать или обратно скомпенсировать, благо ручка то есть.

Подробнее

Вообще-то, предсказать - это не увидеть постфактум, а предсказать заранее. Но даже постфактум - а что, я не увижу неожиданное на картинке, без гистограммы?

Цитата:

от: Alex Tutubalin
А я не знаю, что вы к ней привязались. Я тут в очередной раз появился клюнув на дискуссию о линейном участке ХК цифровой камеры.

Я, вообще-то, хотел как раз отвязаться.

Цитата:

от:Alex Tutubalin
Сама по себе линейность - очень удобна в процессе дальнейшей обработки. Вот, к примеру, экспокоррекцию очень удобно делать (втч. скрытую). Но линеаризовать любую известную ХК - не является проблемой.

Подробнее

Кому удобно-то? Программисту? Наверное. Фотографу? Да ему все равно, по-моему, он для экспокоррекции двигает ползунок и цифр в raw даже не видит.

Цитата:

от:Alex Tutubalin
Этим примером я хочу сказать, что программисту ("если интересует результат") таки надо разбираться, где у процессора голова, а где хвост кэш, а где - векторный сопроцессор.

Подробнее

ОК, вот он разобрался, где кэш и узнал, что у разных процессоров разный. Что делать дальше бедняге? Для примера - есть такие граждане, много лет они пишут одну и ту же библиотечку - ATLAS. Для одной, в сущности, операции (и принципиально очень несложной) - перемножения матриц. Она типа должна сама оптимизироваться под разные размеры кэша. Ну и как-то делает. Но с переменным успехом (я пробовал пользоваться). И все им приходится новые и новые версии выпускать. Для реализации всего одной операции, напомню.

Цитата:

от: Alex Tutubalin
Алгоритмы в своей предметной области - если я правильно угадал источник их кода - у нас строго одинаковы. Различается реализация.

Алгоритм перемножения матриц тоже у всех одинаковый (алгоритм Штрассена и другие из той же оперы реально мало где применяют), различаются реализации. Только они различаются не ручным написанием машинного кода, а именно организацей алгоритма.

Цитата:

от:Сергей Катковский

Э-э, погодите. По Адамсу - это, например, как? Скажем, "по Адамсу" - это "экспонируй по теням, проявляй по светам", но это с ЦФК и его линейной и неизменной характеристикой и не нужно, и невозможно. Или под управлением понимается лишь "как снять, чтобы не выбило света"?

Подробнее

Под управлением "по Адамсу" понимается попадание нужного объекта в нужную зону. Сначала на (цифровом) негативе, потом на отпечатке.
"не выбило света", т.е. попадание светами в 9-ю зону или ниже, тоже относится к.

Дальше пошел оффтопик.
Цитата:

от: Сергей Катковский

ОК, вот он разобрался, где кэш и узнал, что у разных процессоров разный. Что делать дальше бедняге?

Применять свои умения на практике. Послушать мою лекцию про эффективное использование процессоров (не обязательно мою, только для примера) и постепенно начать использовать.
Цитата:

от:Сергей Катковский

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

Подробнее

ATLAS - это же не "одна операция", это же BLAS3, там довольно много разнообразных вызовов, не только *GEMM. Сама по себе идея с auto-tuning - хорошая, но если вы пишете, что получается не очень, значит таки руками грамотного программиста (Goto BLAS, Intel MKL) получается лучше, чем автомат подберет из десятка вариантов.

И то, что нужны новые версии под новое аппаратное обеспечение - это опять иллюстрация того факта, что компилятор сам чудес не сделает (хотя с начала 2000-х, если не раньше, было принято считать наоборот) и эффективный код за программиста не напишет. Понятно, BLASn - особый случай, на него вообще все завязано и 10% разницы в эффективности - играют роль.

Впрочем, Донгарра, мнению которого я доверяю, считает что за авто-адаптивыми методами будущее, уж слишком сейчас разнообразные и причудливые архитектуры бывают.

Цитата:

от: Сергей Катковский

алгоритм Штрассена и другие из той же оперы реально мало где применяют

Судя по всему, вы заблуждаетесь. Во всяком случае, судя по статье "Adaptive Strassen and ATLAS’s DGEMM: A Fast Square-Matrix Multiply for Modern High-Performance Systems" (первое что нагуглилось по теме): в ней как раз рассказывается, как на основе ATLAS они (авторы) здорово (или не очень) имплементировали алгоритм Штрассена. С чего бы они стали это делать, если бы оный алгоритм был бы уже у ATLASа в пузе?
Судя по их обзору в начале статьи, из сколько-нибудь известных библиотек, алгоритм Штрассена используется только в PHiPAC.

Эх, вот почему при цитировании остается только последний абцац и приходится руками копировать остальные?..

Цитата:

от:Alex Tutubalin
Цитата:

от:Сергей Катковский
Э-э, погодите. По Адамсу - это, например, как? Скажем, "по Адамсу" - это "экспонируй по теням, проявляй по светам", но это с ЦФК и его линейной и неизменной характеристикой и не нужно, и невозможно. Или под управлением понимается лишь "как снять, чтобы не выбило света"?

Подробнее

Под управлением "по Адамсу" понимается попадание нужного объекта в нужную зону. Сначала на (цифровом) негативе, потом на отпечатке.
"не выбило света", т.е. попадание светами в 9-ю зону или ниже, тоже относится к.

Подробнее

В какую такую нужную, если на линейной кривой (прямой то бишь) все зоны одинаковы (отвлечемся от разрядности)? Если нет выбивания светов или теней, то на прямой неважно, куда попала картинка, она смещается куда надо одним движением ползунка. И опять-таки, чтобы этот ползунок сдвинуть, ничего вообще о ХК знать не надо.

Цитата:

от: Alex Tutubalin
Цитата:

от:Сергей Катковский
ОК, вот он разобрался, где кэш и узнал, что у разных процессоров разный. Что делать дальше бедняге?

Применять свои умения на практике. Послушать мою лекцию про эффективное использование процессоров (не обязательно мою, только для примера) и постепенно начать использовать.

Подробнее

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

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

Цитата:

от: Alex Tutubalin
ATLAS - это же не "одна операция", это же BLAS3, там довольно много разнообразных вызовов, не только *GEMM.

Реально там оптимизируется одна эта операция (ну, в четырех ее вариантах). Остальные к ней сводятся. По крайней мере, раньше вроде было так, давно не смотрел.
Цитата:

от:Alex Tutubalin
Сама по себе идея с auto-tuning - хорошая, но если вы пишете, что получается не очень, значит таки руками грамотного программиста (Goto BLAS, Intel MKL) получается лучше, чем автомат подберет из десятка вариантов.

Подробнее

Я не знаю, как сделано в MKL, но господин Goto ускорил за счет оптимизации обращений к TLB, вместо возни с кэшем. На архитектурах того периода это было более важно (о чем другие почему-то не догадывались, что и дало ему выигрыш), как сейчас - не знаю. Но опять-таки, для него это и есть предметная область. Наивно пытаться проделывать эту оптимизацию вручную в каждой программе. И опять-таки, это было глобальное решение, а не файн-тюнинг.
Цитата:

от:Alex Tutubalin
И то, что нужны новые версии под новое аппаратное обеспечение - это опять иллюстрация того факта, что компилятор сам чудес не сделает (хотя с начала 2000-х, если не раньше, было принято считать наоборот) и эффективный код за программиста не напишет. Понятно, BLASn - особый случай, на него вообще все завязано и 10% разницы в эффективности - играют роль.

Подробнее

Эффективный код не напишет. Вот только и ручная доводка кода чудес, если код написан эффективно, тем более не сотворит.

Ну и в целом еще раз - чем более высокого уровня (применительно к вашей области) оптимизацию вы применяете, тем более эффективны будут ваши усилия. Если вы вычисляете определитель по определению, сортируете случайный массив пузырьком или интегрируете жесткое ОДУ явным методом Рунге-Кутты, ни ручная векторизация, ни оптимизиция обращений к TLB, ни, действительно, самый-самый лучший компилятор не сделают вашу программу быстрой.

Цитата:

от: Alex Tutubalin
Впрочем, Донгарра, мнению которого я доверяю, считает что за авто-адаптивыми методами будущее, уж слишком сейчас разнообразные и причудливые архитектуры бывают.

Он делал много предсказаний, и не все из них оправдались (по крайней мере, на текущий момент).

Цитата:

от:Alex Tutubalin
Судя по всему, вы заблуждаетесь. Во всяком случае, судя по статье "Adaptive Strassen and ATLAS’s DGEMM: A Fast Square-Matrix Multiply for Modern High-Performance Systems" (первое что нагуглилось по теме): в ней как раз рассказывается, как на основе ATLAS они (авторы) здорово (или не очень) имплементировали алгоритм Штрассена. С чего бы они стали это делать, если бы оный алгоритм был бы уже у ATLASа в пузе?
Судя по их обзору в начале статьи, из сколько-нибудь известных библиотек, алгоритм Штрассена используется только в PHiPAC.

Подробнее

Вы меня не поняли - Штрассен не применяется в ATLAS. Он нигде почти не применяется, а все реально используемые реализации BLAS 3 (включая ATLAS) используют классическое "строка на столбец". Именно это я и сказал в скобках.

Цитата:

от:Сергей Катковский

В какую такую нужную, если на линейной кривой (прямой то бишь) все зоны одинаковы (отвлечемся от разрядности)? Если нет выбивания светов или теней, то на прямой неважно, куда попала картинка, она смещается куда надо одним движением ползунка. И опять-таки, чтобы этот ползунок сдвинуть, ничего вообще о ХК знать не надо.

Подробнее

Если отвлечься от существенных деталей (разрядность, шумы), то действительно - все едино.

Цитата:

от:Сергей Катковский

Вы меня не поняли - Штрассен не применяется в ATLAS.
Он нигде почти не применяется, а все реально используемые реализации BLAS 3 (включая ATLAS) используют классическое "строка на столбец". Именно это я и сказал в скобках.

Подробнее

Да, действительно не понял.