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

<em>> Возможно, наоборот, есть компенсация виньетирования в замере, а так как данная линза практически не виньетирует, то получается перекомпенсация.</em>

Тогда замер должен и от значения (электронной) диафрагмы нелинейно зависеть&nbsp;&mdash; при диафрагмировании виньетирование обычно спадает. Боюсь, слишком сложная система придумалась. Наверняка есть объяснение проще. Или в самом деле калибровочные константы чуть отличаются&hellip; непонятно только зачем.

Ну и у Nikon (D3/D700 как минимум) вычитается темновой ток, благо АЦП это сам умеет.

Но там вообще много разных гитик, чем дальше, тем страшнее.

у вас там какой онлайновый чат используется?
в аське я его нашел, но он её не поднимает
видимо что-то другое.

попробовали потестить Д700 - половинок не обнаружили
но мы не пересвечивали
надо будет опыт повторить с пересветом

>> но в общем когда отдельные куски соберут вместе, система получается жирнее, memory footprint гораздо больше, отчего в cache влезает меньше и в результате все равно получается плохо <<

А это отдельная "лебединая песТня".
Напр. два обстоятельства:
*: Garbage Collection (GC)
*: в упрочь не оптимизирующий javac ("Буратино был тупой.. тупой... тупой, как дрова" (с) Псой Короленко - )

во-первых, GC периодически ставит на уши весь "пейджинг"... ну работа у него такая - ходить и "всё трогать руками".
во-вторых, GC более менее эффективно работает до тех пор, пока "хип" приложения не превосходит половины физич. RAM (т.е. пока "хип" более менее не свопится)
в-третьих, больно смотреть на GC, когда он вынужден перейти со стратегии mark-sweep на mark-compact - производительность всей системы (апликухи) падает на _порядки_ (причём в "аналогичной" ситуации "прямолинейные аллокаторы" в стиле С/С++ продолжают работать без заметной деградации по производительности).

в-четвёртых, у GC обнаруживаются трудности с "распознаванием" и "деаллокацией" сложных развесистых структур (напр. достаточно глубокого и пЫшного графа), в результате "мусор" может жить _оч. долго_ и собираться только когда апликуха угодит в idle (и у GC, соотв., появляется время для более скрупулёзного анализа всех этих связей и путей "ричибилити")... справедливо для jdk up to 1.4 inclusive (для последнего jvm, i.e. jdk1.5+, не проверял).

в-пятых, с учётом тупости компилятора (что справедливо как минимум для javac вплоть до 1.6+), возможны протечки памяти по абсолютно примитивной схеме - чего-то нааллокировали на локальную переменную, поработали с этим и ушли "навечно" в какой-нибудь метод (не покинув, разумеется, текущий... характерный пример - рекурсия или обработка большого массива данных с "препроцессингом"). Т.е. "переменная" (жЫрный вспомогательный класс-"препроцессор") больше не используется, но сцЫлка на него держится, что не позволяет GC собрать объект как мусор.
Оптимизирующий компилятор мог бы понять (и С/С++ компиляторы умеют это делать), что "[здесь] переменная далее не используется" и, хотя бы, занулить ссылку. Однако - "фигвам" - такие вещи приходится делать руками, чего, разумеется, никто не делает.

...ну и, конечно, "underlying library" (jdk, например) тоже поражают воображение в самую пятку. Напр. реализацию какого-нить ByteArrayOutputStream эти уроды сделали через примитивный врапер вокруг byte[], который тупо реаллокируют "по мере надобности" (причём по-простецки - "вдвое")... и это для объекта с "последовательным доступом" без операций типа "insert"/"delete".

в общем, всё плохо в датском королевстве, и все эти "кэш-промахи" даже не верхушка айсберга, а так - "музЫкальная пауза" для "лохов с пейджером" :-(

Хммм... "какие нервные лица - быть беде" (с)

а почему такая реакция, как будто застали в общественном туалете типа "очко" за занятием постыдным и унизительным (типа выдавливания застарелого геморроя) ?

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

или, например, реплики в духе - <i>"Сегодня заменить спеллчекер в ворде - это можно, но непросто, а завтра будет неприлично - просто неприлично - выпускать софт, в котором выраженные функциональные компоненты незаменяемы. Не самый удачный, но иллюстративно приемлемый пример."</i> - это _действительно_ означает, что кроме винды и "полуоса" Дима Завалишин ничего не видел и не знает, или он просто так "утрирует", ориентируясь на определённый сегмент "аудитории" ?

.

Необходимость что-то делать с low latency может и специфический случай, но очень распространенный. На кажом компутере нынче чего только нет - и VPN, и VoIP и всякие файрволы

Случай уж очень специфический.
В большинстве задач нет многих тысяч параллельно живущих сессий и одновременного требования high system responsiveness.

<b>>> Когда я говорил, что плёночной фотографии пиздец, такие люди как ты, Лёша (а может и ты тоже, не помню), пренебрежительно объясняли мне (ибо очевидно же, что они велики в фотографии, а я - лох), что я тупой, и что вонючий мегапиксель цифровика никогда не сравнится. <<</b>

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

... но это всё "художественная лирика".
Интересней другое - наш дядя Дима с "более десяти лет экспириенса в индустрии" сумеет _внятно_ объяснить чем же "Фантом" (с педальным приводом ,-)) так _кардинально_ отличается от того же SmallTalk ? (и гугель ему, дяде Диме, в помощь... на склоне "десяти лет экспириенса в индустрии" ,-))

<b>>> А ещё есть другой параметр - стоимость производства кода. Который ты тоже, о свет моих очей, не видишь, потому что любишь задачи, в которых он не критичен. <<</b>
хм,
а дядя Дима что-нибудь слышал про "Objective-C" и ту жопу (да-да, не "задницу", а именно "жопу"), в которую его вогнали всё те же стивы джобсы вместе со "стоимостью производства кода" ?.. а это оч.поучительная притча, объясняющая почему "презренная джава" преуспела, а Obj-C оказался... эммм... "маргинальным" что твой asm в *nix.

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

-+-
<b>>> Ну - спокойнЕЕ надо. Есть вещи, которые и ты, о великий воин оптимального программирования, не видишь. <<</b>

Дядя Дима, а давай _спокойно_ обсудим implications, которые привносит с собой в "дот-нет"/"ждава" такой "прозрачный", с виду, GC... а _потом_ обсудим implications твоего "imaginary" "персистент вейвера"... не слабо-то, после "десяти лет в индустрии" ? ,-)

.

Это обещанный "фидонет с гиперссылками"? :-)

...эмммм...
Понятно, что к "завалишину" с его древней игрушкой (осподя! - "я помню, как всё начиналось" и остался чрезвычайно удивлён тем, что он до сих пор мусолит свой "фантом" :-))) это не имеет никакого отношения, но вообще-то упираться в мантру "дисковые I/O не параллелятся" просто опасно... "гугель учит нас" (просто самый "одиозный" пример), что сеть нынче _быстрее_ дисковых операций. Соотв. если уж задача упёрлась в диск, то её нужно "параллелить" на кластере (десяток/сотня "посредственных" машин с "потребительскими" винтами и "мощной" сеткой) + "мажоритарная система" (т.е. "избыточность")... заодно, кстати, позволяет бороться с "непредсказуемостью" БД.

для "локальных" приложений зачастую хорошо работают подходы а ля "кусочно-непрерывная сортировка". Т.е. "заглотили_кусок-обработали-выплюнули... повторить" с последующей "сшивкой" результатов. Если I/O неблокирующие, то это хорошо "параллелится" (главное - уравнять затраты "вычислительной" части и I/O).

<b>>> Делается почти также, как в Це - выделяется большой массив и в этом массиве всё живёт. <<</b>

Это не вполне так - в джаве нет понятия "массив объектов" (это будет массив _указателей_ с кучей объектов), но выигрыш (по производительности) будет - в джаве (за ким-то хреном) _безумно_ дорогой конструктор... т.е. выгодней завести пул объектов с полиси init/dispose. В ситуациях, когда порождается bunch кортокоживущих объектов (напр. DOM или всяческие "ивенты"), такая стратегия приносит ощутимый выигрыш по производительности (в том же xml-to-DOM иногда до 20% _кумулятивного_ времени).

>> задачу, которая упирается в диск, а вовсе не в CPU. И хрен ты ее распараллелишь "просто" <<

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

Ну и, в ряде случаев, такие операции могут параллелиться _буквально_ (почему, в частности, sys, temp/swap & app имеет смысл разнести не просто по разным "разделам", но по разным "спинам").

...ну и, конечно, дисковый кэш тоже никто не отменял (да, fault tolerance понижается... "но это уже совсем другая история" (с) АБС)

.

Вместе с тем, вы получили для 350ки 0.1ev разницы, для 40D - 0.04. При одном размере сенсора и одном объективе.
Где-то тут подвох

<p>
Провёл эксперимент с 350D и 40D (что под рукой есть). Методика отличается незначительно (люстра светит в потолок, свет достаточно ровный, проверено; было забавно менять не объективы на тушке, но наоборот&nbsp;&mdash; &laquo;задники&raquo; на линзе):
</p>

<center>
<a href="http://i057.radikal.ru/0902/32/582b79ea3ceb.jpg"><img src="http://i057.radikal.ru/0902/32/582b79ea3ceb.jpg" alt="Тестовый стенд" border="1" width="120" height="180" /></a>
</center>

<p>
Результаты:
</p>

<ul>
<li> 350D (ISO200):
<ol>
<li> partial&nbsp;&mdash; -3.38&thinsp;EV; </li>
<li> evalutive и center-weighted&nbsp;&mdash; -3.48&thinsp;EV; </li>
</ol>
</li>
<li> 40D (ISO200):
<ol>
<li> spot и partial&nbsp;&mdash; -3.33&thinsp;EV; </li>
<li> evalutive и center-weighted&nbsp;&mdash; -3.37&thinsp;EV. </li>
</ol>
</li>
</ul>

<p>
Полагаю, spot и partial не отличаются, так как виньетирование объектива при открытой диафрагме (а экспозамер так и производится) в центральном пятне не сказывается.
А center-weighted и evalutive измеряют экспозицию по всей площади кадра, по которой средний световой поток ослабляется объективом, что приводит к лёгкому пересвету (для &laquo;компенсировать виньетирование&raquo;).
</p>

<p>
Полагаю, использованная Вами линза (135mm f/2.0L USM) просто не виньетирует на кропе, что и объясняет одинаковые результаты при любом алгоритме замера для 450D.
</p>