О семантике C++

lexa - 05/Окт/2011 09:37

В продолжение кулуарного разговора с Highload++, навеянного 26-м слайдом презентации Андрея Аксенова.

Вот такой вот код:

class someShit{
        char *m_sBuffer;
        size_t m_iLimit, m_iCounter;
};
void someShit::try1()
{
        m_iCounter = 0;
        while (m_iCounter< m_iLimit && m_sBuffer[m_iCounter])
                m_iCounter++;
}

void someShit::try2()
{
        size_t l_iCounter = 0;
        while (l_iCounter< m_iLimit && m_sBuffer[l_iCounter])
                l_iCounter++;
        m_iCounter = l_iCounter;
}
Компиляторы (смотрел gcc 4.6, Visual Studio 2010 и Intel 11.0, все с включенной стандартной оптимизацией -O3/O2 без тонких настроек) делают разное:
  • gcc и Visual Studio генерируют код с той семантикой, какой написано;
  • Intel C++ делает так же, если компилирует "библиотеку", но оптимизирует первый случай до второго, если все потроха (методы класса и вызывающий их main()) лежат в одном файле.

О девиртуализации

lexa - 03/Окт/2011 08:38

Желающим повидаться: у вас есть шанс сделать это сегодня-завтра на Highload++

Планирую оба дня быть с утра, но уходить часиков в семнадцать.

Win32-Git: про .netrc

lexa - 30/Сен/2011 09:13

Записка для памяти:

~/.netrc для Win32 Git (msysgit) называется ~/_netrc

Всех убью, один останусь: ~/.gitconfig называется, сюрприз, ~/.gitconfig

Update: но вообще, конечно, жесть. Без netrc спрашивает пароль, я его честно говорю и оно с этим паролем даже что-то вытаскивает и ломается с 401-й ошибкой не сразу.

Про AVX и ISPC

lexa - 29/Сен/2011 11:52

Разработчики Intel SPMD Program Compiler, который в этом блоге уже несколько раз поминался, выпустили версию 1.0.9 в которой

=== v1.0.9 === (26 September 2011)

The binary release of v1.0.9 is the first that supports AVX code generation. Two targets are provided: "avx", which runs with a programCount of 8, and "avx-x2" which runs 16 program instances simultaneously.

Честь им за это и хвала, мои попытки (не слишком настойчивые) самостоятельно собрать ISPC с LLVM3 так и не увенчались успехом, то какие-то ошибки в LLVM-овских H-файлах, то не линкуется, не больно то и хотелось.

Так как предыдущие тесты никуда не делись, я их переделал с новым ISPC, как с SSE4, так и с AVX.

Про AVX и OpenCL

lexa - 27/Сен/2011 15:04

Вчера вышел Intel OpenCL SDK 1.5 с соответствующим анонсом: Increase OpenCL application performance with the new Intel OpenCL SDK 1.5

Пытаюсь enlarge increase эту самую performance, сую в бензопилу лом туда AMD-шные примеры, которые на предыдущей версии работали очень бодренько (и временами почти догоняли AMD-шную видеокарту) и вижу замедление в 2-3 раза для половины примеров.

Начинаю читать код и не вижу там 256-битности. Ну, почти не вижу. Кое-где есть 256-битные load/store, нашел даже один vandps ymm1,ymm1,[memory], но в подавляющем большинстве код - 128-битный.

Он и в прошлой версии был 128-битный, но какой-то более человеческий.

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

Ну то есть понятно, производительность не переносится, но 2-3 раза просадки - это беспредел.

Единственный пример, который стал быстрее, называется Histogram. Но его и старая версия отказывалась векторизовать (немудрено) и новая тоже не хочет.

О Betterscanning

lexa - 23/Сен/2011 19:14

Так уж совпало, что сегодня все - вокруг темы сканирования.

Сегодня до меня доехали рамки для Epson V700/750 имени Betterscaning.com и я их немного потестировал.

Имею сказать:

  1. Они действительно нереально удобны. Всё предыдущее что я пробовал (родные от Epson разных моделей, родные от Nikon-9000) - не идет ни в какое сравнение. С перегородками (которые T-lock) совсем удобно: просто суешь пленку и прижимаешь этими T-locks в нужных местах. Никаких вылезающих краев и прочего безумия.

    Cо стеклом чуть менее удобно, вылезающие края бывают, но запихиваются легко.

    Короче, лучшие 150 баксов месяца.

  2. Три кадра 6x7 лезут в холдер, но, увы, не влезают в окно сканирования. Т.е. можно резать 6x7 по три (для сливера), а не по два. Но сканировать такое, увы, придется в два приема.
  3. Глубина резкости у сканера оказалась миллиметра полтора. То есть та точность подгонки, что у этих штук есть (~0.2мм, полный оборот ножки - 0.8) - избыточна.
  4. Чуда не случилось, 9000-й никон по проработке деталей не догнали и изрядно не догнали. Но A3 с 6x7 вполне можно печатать.
Если будете заказывать, учтите мой опыт:

О методологии

lexa - 23/Сен/2011 09:33

На сайте LL креативное сравнение 80Mpix IQ180 и форматки 8x10, которое меня просто порадовало.

8x10 Inch: ... Drum scanned (Dainippon screen SG 608) at 745 dpi which results in 8874 x 7229 pixels.
И это в то время, когда корифеи спорят, нужно ли сканировать форматный слайд на 8000dpi или хватит 3-4 тысяч (кроме foto.ru есть еще смысл на mformate поискать сломаных копий). А, да, и не надо ли выводить на струйник на 720 dpi вместо 360, это что, для 745dpi сканирования будем печатать 8x10 "контактом"?

Результат получился ожидаемый: Если отсканировать пленку с разрешением 64-Mpix (не вдавался, сколько пикселей в мегапикселе, считаю что 106), то по 100%-м кропам она сольет 80-Mpix заднику без AA-фильтра. Еще бы, вы самплите один цифровой сенсор (пленку) другим, не попадая в шаг (которого, собственно, у пленки и нет), понятно что будет размытие. Помимо размытия, будет еще aliasing ("наведенное зерно") с размером элемента порядка единиц пикселов.

Вместе с тем, интересно было бы переделать нормально: со сканированием в 4000-8000 и уменьшением в 6-12 раз. Я предвижу совершенно другую картинку....

Ждать или покупать, вот в чем вопрос

lexa - 22/Сен/2011 19:51

Сбылась вековая мечта человечества в виде ADSL+Wifi+GigabitEther в одном флаконе.

И даже в двух видах сбылась, Netgear DGND3700 (уже давно в продаже) и Linksys X3000.

Вопрос месяца: ждать Linksys в продаже или пойти и купить Netgear? Цель мероприятия - заменить две коробки одной. То есть не горит совершенно.

У Netgear несколько смущает надпись "не поддерживается IP-TV" (на русском сайте), но это ведь ерунда какая-то :)?

LibRaw 0.14.0 (Release)

lexa - 21/Сен/2011 20:53

После трех месяцев разработки и тестирования вышла LibRaw 0.14.

По уже сложившейся традиции, помещу тут несколько отредактированный Changelog.

В этой версии одно принципиальное изменение, влекущее за собой множество мелких:

Разрешены повторные вызовы постобработки (LibRaw::dcraw_process) без переоткрытия файла парой вызовов open()/unpack(). При этом, постобработку можно повторять меняя любые параметры обработки (за исключением выбора кадра через shot_select).

В сочетании с повышением скорости обработки, на (очень) приличной современной машине можно получить:

  • "Почти realtime" показ изменений изображения при смене параметров RAW-конвертации в режиме половинного разрешения. На 40-мегапиксельное изображение уходит примерно 250 мсек (т.к. half-mode, то выдается 10 мегапикселей, что сильно больше любого современного монитора).
  • "Совсем realtime" показ изменений небольшого окошка (например, вокруг курсора) в полном разрешениии с настоящей демозаикой (получается 30-50 кадров/сек для окошка 450x300)
Осталось дождаться, пока это подопрут разработчики конверторов. digiKam обещал, но пока еще не сделал...

О языке ++C

lexa - 16/Сен/2011 23:47

Нашелся тут чудесный баг в KDE-шном DNG-конвертере. Вдруг, внезапно, перестал конвертировать, получаются совершенно ЧОРНЫЕ DNG.

Понятно, пишут в багрепорты digiKam-у, а дальше стрелки переводятся по кругу, ко мне (но LibRaw не менялась, в KDE все еще 0.13), к автору DNG Converter, все отпираются т.к. test cases работают.

И наконец виновник найден

Было:

  *output = ...some value...;
  *output++;
стало
  *output = ... some value...;
  ++(*output);
И комментарий к коммиту: use prefix operator

А я подозреваю, что исходно там было и вовсе:

  *output++ = ... some value...;
Проверять не стал, но предсказываю это.

Потом один доброжелатель разбил операцию на две, как умел, а второй, из ненависти к суффиксным инкрементам (или из желания подавить compiler warning), поменял на префиксный. Тоже, как умел.

Всех люблю: опенсорс, коллаборативную разработку по схеме "у семи нянек....", язык C/C++ тоже люблю.

О продолжительности жизни SSD

lexa - 15/Сен/2011 15:22

Прислали ссылку, невозможно не поделиться (под картинкой). Таки слухи о преждевременной смертности SSD несколько преувеличены (если верить этим данным):

Полный текст (и там еще много картинок): SSD Write Endurance 25nm Vs 34nm .

Мораль такая: срок жизни SSD: несколько (3-9) тысяч объемов по записанным файлам, то есть без учета всех эффектов по write amplification и тому подобному. Файловый микс, использованный в тестах (как и вообще условия, вроде количества неиспользуемого места), кажется разумным.

Понятно, что если взять побольше дисков, то можно и статистику по разбросу получить, но пока я такой не видел.

Про винду и бэкапы (restore)

lexa - 15/Сен/2011 10:54

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

Вчера провел на себе более человечный эксперимент:

  • Накатил диск C: из бэкапа 3-дневной давности
  • Оставив Users и ProgramData - актуальными
Все продолжило работать, за единственным исключением: Антивирус Касперского (точнее, KIS-2012) очень обиделся, что базы какие-то более свежие, чем у него записано. Снесение-установка его - помогли.

А восстанавливал из бэкапа я по причине непонятного поведения: стало грузиться долго, Google Chrome несколько раз упал, CPU load местами рост, короче странности (хотя вот непонятного сетевого трафика, который разумно было бы подозревать при странностях - не было). Несмотря на молчание антивируса, решил "от греха", благо делов то на три минуты - накатить образ диска.

Я к тому, что разнесение Users/ProgramData и всего остального - похоже рулит. В сравнении с обычным

  • побэкапили актуальное;
  • накатили "хороший" образ всего
  • и дальше мучительно восстанавливаем состояние многих программ (Скайп, Аутлук, uTorrent и далее по списку)
стало гораздо удобнее и проще.

Pages

Subscribe to blog.lexa.ru: все статьи