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

Title	Comment
<i>делаете свой клон</i> В терминах GitHub это называется fo	делаете свой клон В терминах GitHub это называется fork
А касаемо сути замечания: меня тоже временами удивляет, что	А касаемо сути замечания: меня тоже временами удивляет, что делают в опенсорсных графических приложениях. Но я один раз уже высказался на эту тему публично и на меня обиделись. Непублично (и по другим моментам) - тоже бывает неудобно....
Да можно, конечно. Лучше, конечно, в основной пакет, а не в	Да можно, конечно. Лучше, конечно, в основной пакет, а не в demosaic packs. Т.е. под тройной лицензией (LGPL/CDDL/LibRaw) Наилучший способо: делаете свой клон на GitHub (https://github.com/LibRaw/LibRaw) правите как вам нравится, а потом свистите в свисток чтобы я помержил в основное дерево. Но и просто измененные исходные тексты я тоже приму, хотя технологически это неудобнее для меня.
<i>As for what the algorithm does, it performs a Discrete Co	As for what the algorithm does, it performs a Discrete Cosine Transform in 8x8 blocks (separately within each RGGB subarray of the bayer mosaic raw data) and then damps those Fourier coefficients that are related to vertical and horizontal lines, if the contrast is low enough (high contrast vertical and horizontal lines are treated as detail). The slider sets the contrast threshold below which the debanding is allowed to operate. Long story short -- yes it does blend neighboring pixels. (вздыхая) ну что сказать. Они, конечно, тупые уроды, слов нет. Я начинаю подумывать, чтобы внести в LibRaw свой код, а это вообще можно?
Ну раз обратные посты не работают, чтобы Алексею почтальоном	Ну раз обратные посты не работают, чтобы Алексею почтальоном не работать. Если вы про ключ -aline - вот ссылка на аторское объяснение (второй пост) http://www.rawtherapee.com/forum/viewtopic.php?t=2240 Если про то о чем Алексей написал (-agreen) - то это другая история. И мне показалось оно (оригинал) работает не намного лучше (на том, что мне попадалось). Может просто показалось? Чтобы не голословно туда же пошлю: http://www.rawtherapee.com/forum/viewtopic.php?t=2650
Честно хотите? Да я понятия не имею :) Контрибуторы <s>спи<	Честно хотите? Да я понятия не имею :) Контрибуторы ~~спи~~ перенесли код из RawTherappe, я посмотрел на результат, изображение он не убивает (бывает и иначе: http://blog.lexa.ru/2010/06/06/beda_kol_sapogi_nachnet_pechi.html ) - и оставил. Разбираться в деталях этого добра считаю нужным только если фича уже заявлена, а contributed код работает из рук вон (как случилось с экспокоррекцией).
У меня теперь такой вопрос - а подавление banding там как сд	У меня теперь такой вопрос - а подавление banding там как сделано? В принципе, я пробовал, и если честно - мне показалось, что оно всё-таки слишком много деталей убирает. Вот, скажем, в topaz denoize debanding работает на удивление хорошо. Причём на больших ISO у 5dmk2 - это must have, я бы сказал...
Если задача пилится на крупные (десятки-сотни тысяч инструкц	Если задача пилится на крупные (десятки-сотни тысяч инструкций) куски, независимые по write-данным, то в распараллеливании никакой особой науки нет, берешь и параллелишь. Если куски более мелкие, то надо смотреть, не сожрет ли оверхед на синхронизацию это самое распараллеливание. Вот, кстати, и возможный ответ на загадку intel/MS: на спинлоке быстрее синхронизироваться, чем на чем-то еще (каком-то засыпании-просыпании). А давать какие-то более конкретные советы, не зная специфики задачи - это газифицировать лужи.
спасибо за мысли, всё так... Сейчас просто надо хоть как-то	спасибо за мысли, всё так... Сейчас просто надо хоть как-то сделать, чтобы оно задышало и показало достижение целей, а уж потом "есичо" - оптимизировать буду... А не то я до того счастливого дня могу просто не дожить;) Грамотное распараллеливание потребует изменения алгоритма, а мне сейчас как воздух его понимаемость и изменяемость нужна. В линейном виде оно уж куда понятнее выглядит... Хотя, вы конечно, правы, лучше это сразу закладывать, но я пока не уверен, что смогу, опыта в распараллеливании маловато и сейчас не самый подходящий момент, чтобы инвестировать время в это... В любом случае, спасибо за диалог, чертовски приятно в кои-то веки поговорить со знающим своё дело человеком) Надеюсь, и вам какая-нибудь информация оказалась полезна.
Я не знаю что у вас за задача, но если данных много, а досту	Я не знаю что у вас за задача, но если данных много, а доступ к ним (в пределах треда) локален, то зачем вы вообще фигачите близкие куски данных в разных тредах? Если можно линейно читать (ну грубо, считаем сумму или там гистограмму), то лично я бы пилил на большие куски, может быть с хитро выставленным смещением, чтобы кэш L3 по возможности не размывался (т.е. ассоциативность в разных потоках кажет в разные места). Ну и фигачить, фигатором. Оно или упрется в memory bandwidth (обсчет быстрее памяти) и тогда кэш не спасает и практически не нужен (для префетча только), или определяющим является именно скорость расчета, тогда значит в CPU упрется (и тогда рулит SSE).
да, забыл ещё сказать, что делается обсчёт довольно большого	да, забыл ещё сказать, что делается обсчёт довольно большого объёма данных, который скорее всего полностью в кеш не влазит. Соответственно, если потоки стартуют обсчёт практически одновременно, то неисключено, что они по данным идут примерно рядом друг с другом и соответственно, это вызывает более эффективное использование процессорного кеша и меньше фетчей из памяти. А когда работает через конкарренси, оно может стартовать потоки в соответствии со своими какими-то условиями, а за это время уже работающие потоки уйдут по данным далеко и возвращение к ним вызовет переобращение к памяти... Ну, где-то так в качестве гипотезы объяснения... Ну и плюс эти спин-локи вообще не понятные... Я ещё могу понять, когда они в ядре используются и везде при этом в DDK аршинными буквами пишется: "выпускайте спин-локи как можно скорее!!!", а тут вот вдруг в юзермоде и такая хрень... ну как-то совсем не понятно... Будем надеятся, что они таки увидят этот юзкейс и поправят..
блин, промахнулся. Итак, на рабочую функцию приходится около	блин, промахнулся. Итак, на рабочую функцию приходится около 85% всех семплов, соответственно - остальное - шум. Но от всего времени взять 85% - получается всё равно больше, чем время threadpool))) Видимо ещё генерируется разный код, хотя рабочая функция вызывается всюду из одинаковой лямбды (впрочем, тут могут быть тонкости, связанные с передачей параметров в эту лямбду, которые могут по разному учитываться в профилировке и давать остальное смещение). В общем, по моему дело пахнет киросином... Я канешна с этим добром по сути только сегодня познакомился, но пока у меня идей нет, куда дальше копать, чтобы это ускорить до приемлемых значений... А хотелось бы, ибо иначе придёццо самому возиться с синхронизацией доступа к результатам обсчёта, а это чот не хочется) Ща ещё попробую profile guided optimization, может у неё там какая своя магия есть...
ну да, на рабочую функцию получается приходится что-то около	ну да, на рабочую функцию получается приходится что-то около 85% всейнагрузки
Ну вот если VCшный профилер не врёт, то получается около 13%	Ну вот если VCшный профилер не врёт, то получается около 13% прожирается только на следующих 6-ти функциях Function Name Inclusive Samples Exclusive Samples Inclusive Samples % Exclusive Samples % Concurrency::details::_SpinWait<1>::_SpinOnce(void) 18 332 17 699 7,83 7,56 Concurrency::_Parallel_chunk_helper,0>::operator()(void)const 233 698 10 170 99,88 4,35 Concurrency::details::InternalContextBase::IsSynchronouslyBlocked(void)const 3 578 3 577 1,53 1,53 Concurrency::details::ExternalContextBase::IsSynchronouslyBlocked(void)const 1 372 1 372 0,59 0,59 Concurrency::details::_HyperNonReentrantLock::_Acquire(void) 209 186 0,09 0,08 Concurrency::details::SchedulingRing::GetNextScheduleGroup(int *,int) 175 175 0,07 0,07 Особенно SpinWait нам как бе намекает... Вот накуа оно там???
Хорошая мысль, кстати, спасибо. Ща погляжу...	Хорошая мысль, кстати, спасибо. Ща погляжу...
А пошто оно так тормозит - не видно? 25% должны бы быть видн	А пошто оно так тормозит - не видно? 25% должны бы быть видны профайлером...
Хе-хее, грабельки они такие грабельки... Короче, возможно в	Хе-хее, грабельки они такие грабельки... Короче, возможно вам будет таки интересно, я сделал простенький бенчмарк на расчёте своих алгоритмов: Concurrency Runtime::parallel_for() vs. boost::threadpool 0.2.5 (с патчем утечки памяти и падения из их багтрекера и моими мелкими правками совместимости с VC2010). Результаты на 6 ядрах такие: Linear = 28237 Thread Pool 1 = 5460 Thread Pool 2 = 5428 Thread Pool 3 = 5523 Thread Pool 4 = 5476 Thread Pool 5 = 5413 Thread Pool 6 = 5444 ConcRT Pool 1 = 6911 ConcRT Pool 2 = 6708 ConcRT Pool 3 = 6771 ConcRT Pool 4 = 6832 ConcRT Pool 5 = 6771 ConcRT Pool 6 = 6614 Linear = 29187 Thread Pool 1 = 5367 Thread Pool 2 = 5398 Thread Pool 3 = 5428 Thread Pool 4 = 5398 Thread Pool 5 = 5382 Thread Pool 6 = 5398 ConcRT Pool 1 = 6692 ConcRT Pool 2 = 6771 ConcRT Pool 3 = 6630 ConcRT Pool 4 = 6708 ConcRT Pool 5 = 6849 ConcRT Pool 6 = 6723 Linear - это линейный алго, 1 прогон за тест, и по 6 прогонов на каждый из распараллеливающих алгоритмов. Числа после равенства - время в миллисекундах. Релизный билд. Разница в 25% видна невооруженным глазом. Плюс бОльшая дисперсия времени в Concurrency Runtime. Плюс там же ещё не пофиксенные утечки памяти... В общем, Concurrency Runtime юзать, конечно, можно, там побольше всяких вкусняшек, а утечку рано или позно исправят, но когда надо молотить данные без компромиссов - 25% это совсем не айс.
Ну да... Вот и приходится прыгать... Ну мне-то ещё положим л	Ну да... Вот и приходится прыгать... Ну мне-то ещё положим ладно, я для себя прожект делаю и что мне удобно, то и выбираю (щаз вот тока бенчмарк наваю ибо ни одна ~~сво..~~ живая душа ещё не публиковала и сразу выберу)... А вот когда ты завязан кроссплатформенностью... Ой и грустное это дело...
Не, ну OpenMP - тот еще уродец, особенно в сочетании с C++ (	Не, ну OpenMP - тот еще уродец, особенно в сочетании с C++ (исключения, невозможность в #pragma omp описать член класса). Зато "дешево, надежно и практично". Было. До этих фокусов со спинлоками. И столь же понятно, что нужен какой-то более другой механизм, которого (общепринятого) нет. Проблема в том, только, что массовый механизм будет рассчитан на идиотов, что печально.
Да, не, что там есть какая-то идея - понятно, но я про то, ч	Да, не, что там есть какая-то идея - понятно, но я про то, что МС сделали эту хрень ненастраиваемой. Вот где фейл... Да, я тоже сути проблемы не понимаю, но претензия у меня только к отсутствию настройки) Кстати, вот тут, чувак просто кипятком писает от счастья: Earlier I was thinking that only your and other Microsoft people Demos fit perfectly for parallel solutions ! But indeed with some effort it is possible to make an application make the most of the processing power. Most of the work is already being done for us. Так шта чую что пора уже заканчивать безуспешно гуглить и пора писать бенчмарк для обычного трид-пула и их Concurrency Runtime...
Судя по тому, что интел принял то же решение - там есть кака	Судя по тому, что интел принял то же решение - там есть какая-то идея. Хотя мне эта идея непонятна совсем, но может быть какая-то типичная ошибка, вроде пропуска синхронизации (а так - оно в подавляющем случае синхронизируется само). Чудеса какие-то.
ага, спасибо, видел. В том то и дело, что регулируемая... Я	ага, спасибо, видел. В том то и дело, что регулируемая... Я вот всё пытаюсь понять, какими мыслями надо руководствоваться, чтобы принимать такие решения, как вот здесь они приняли с этой херью? Я б такого человека выгнал бы с работы с совершенно волчьей характеристикой, позорище какое-то просто... МС можно и есть за что ругать, но они всё равно одни из лучших производителей софта в мире. Но такие вот решения просто убивают...
git pull Значит это у меня	git pull Значит это у меня косяк где-то. Мозилла - понимает mc, lynx - нет. В общем то не критично. mc-4.6.2-8mdv2009.1 lynx-2.8.6-4mdv2009.1 `env\|grep -i lang LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8:en_US:en` env\|grep LC LC_PAPER=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_SOURCED=1 LC_NUMERIC=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_NAME=en_US.UTF-8
По первой ссылке (stackoverflow) пишут, впрочем, что у интел	По первой ссылке (stackoverflow) пишут, впрочем, что у интела та же херь. Но регулируемая
BOM-а нет в API-notes-rus,	BOM-а нет в API-notes-rus, добавил. В остальных русских - есть и все клиенты обязаны фишку сечь (без этого с UTF вообще жизни нет)
Я поправил. У меня для	Я поправил. У меня для счастья надо <code> ставить
После добавишь - еще были	После добавишь - еще были слова про мету, чарсет, utf8. Скушались кем то по дороге.
Значит у меня совсем	Значит у меня совсем тупой. Добавишь - ляпота. Не добавишь - понять сложно. Ну и фиг с ним с тупым. Может со временем поумнеет.
Да, явно придётся как-то изгаляться...	Да, явно придётся как-то изгаляться...
Может проще интеловский компилятор взять? Он не такой дорого	Может проще интеловский компилятор взять? Он не такой дорогой, окупится на экономии времени. У интела в этом месте, с виду, ума побольше.

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

Pages