2011

О языке ++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 и далее по списку)
стало гораздо удобнее и проще.

Об андроидах

lexa - 14/Сен/2011 16:34

Рискуя флеймом, таки задам вопрос:

Порекомендуйте телефон на Андроиде!

Требований нет, есть пожелания:

  • Частое использование как телефона - не предполагается, у меня две нокии есть. Иногда - возможно. То есть качество звука, динамика, звонка, будильника - несущественно.
  • Разумная цена - имеет значение. Девайс за килобакс я в любом случае покупать не буду.
  • Срок жизни от батарей имеет значение.
  • Вес - не имеет значения (в разумных пределах), жить будет в напузной сумке (6" лезет легко, 7" не пробовал), а не в кармане рубашки.
  • Предполагаемое использование:
    • Мобильные карты (Яндекс, Гугл), модуль GPS нужен.
    • Мобильный интернет, как с самого девайса, так и работая модемом для ноутбука.
    • Книжку почитать иногда (т.е. 4" экран - минимум).
  • Всякие программистские пищалки и перделки (вроде USB Host) были бы приятны. WiFi - тоже.

Ну то есть я задал какие знаю параметы на Яндекс-Маркете и получил штук 20 моделей, различить которые не могу. Поможите.

...почитав собственные требования, задумался о 5-7" планшете, но планшет я сам сумею выбрать, их мало.

P.S. История в тему: в метро недавно видел сильно пожилую бабушку с Galaxy Tab или чем-то в этом духе, дюймов на 7. Подумал, что реально удобно с плохим зрением: кнопки большие, все видно, не промахнешься.

О векторном умножении: нет гигапикселя в секунду

lexa - 13/Сен/2011 15:29

Тема матричного цветопреобразования не отпускает нас.

Наш читатель maratyszcza намекает нам, что haddps - тоже хорошая инструкция.

Его вариант вы найдете по вышеуказанной ссылке, а я потестировал вариант попроще, без unroll, без префетча, без одновременной обработки половинок данных. Исключительно для совместимости с прошлыми тестами:

О Терафлопсах

lexa - 12/Сен/2011 21:55

Для истинных ценителей: 

================================================================================
HPL-GPU 1.1.0  --  High-Performance Linpack benchmark  --   2010
Written by D. Rohr, M. Kretz and M. Bach,  Frankfurt Institute for Advanced Studies
Based on:
HPLinpack 2.0  --  High-Performance Linpack benchmark  --   September 10, 2008
Written by A. Petitet and R. Clint Whaley,  Innovative Computing Laboratory, UTK
Modified by Piotr Luszczek, Innovative Computing Laboratory, UTK
Modified by Julien Langou, University of Colorado Denver
================================================================================
...skip...
================================================================================
T/V                N    NB     P     Q               Time    CPU          Gflops
--------------------------------------------------------------------------------
WC06L2C64      122880  2048     1     1            1006.60 8742.71       1.229e+03
Avg. matri size per node: 112.50 GiB
--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0002429 ...... PASSED
Это один узел кластера, а не кластер; не Nvidia; прочие подробности я пока раскрывать не уполномочен. Через месяцок.

Но штука получается забавная. И хочется надеяться, что цифирка в правой колонке еще далека от окончательной.

P.S. Троллинг: в тред призывается поисковая команда Яндекса, получившая на 400 узлах в 600 раз меньше. Правда два года назад.

P.P.S. Это, естественно, двойная точность.

О нагреве видеокарт

lexa - 12/Сен/2011 09:07

Читаю доку (техрепорт) к CALDGEMM и внезапно вычитываю такое (по смыслу, не близко к тексту):

  • в readme: ключ -f заливает входные матрицы нулями, а не случайными данными, отчего инициализация проходит быстрее (ну да, попробуйте 60Gb random нагенерировать).
  • в техрепорте: если входные матрицы нулевые, то конструкция сильно меньше греется т.к. в результате вычислений не меняется ни одного бита памяти.

Ну, собственно, так и есть, проверено на себе: с минус -f все работает как из пушки, а без оного - уносит нафиг, если вентилятор заранее не раскрутить (время реакции системы термосенсор - думатель - вентилятор недостаточно, нагрев практически мгновенно происходит).

Остается понять - это нулевые биты меньше греются или достаточно того, что содержимое не меняется?

О векторном умножении - финал

lexa - 11/Сен/2011 20:55

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

Ассемблерные упражнения на тему векторных расширений.

Опять про movntps

lexa - 08/Сен/2011 16:22

Читал комментарии к прошлому посту про movntps, много думал. Вспоминал, что на i7-920 выигрыш от movntps был и значительный.

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

День бульдозериста

lexa - 08/Сен/2011 09:32

Читаю новость: AMD's Bulldozer processors now shipping; in servers by end of month, много думаю:

  • С одной стороны, 1 FPU на два ALU - это как-то обидно. Даже с учетом появления там FMA, не факт что производительность значительно вырастет в сравнении с текущими 12-ядерными оптеронами у которых 12 FPU на камень. Частота, правда, несколько повыше.

    Нет, понятно, не плавающей точкой единой, но мне интересна именно она.

  • А с другой стороны, в гибридных случаях (CPU+GPU) изрядное количество ядер занято именно тем, что нагребают в GPU данные и выгребают их оттуда. В моих последних экспериментах, двух core на GPU не хватает, нужно три (одно засовывает, два - высовывают). В этих ядрах, соответственно, FPU простаивает, а значит и не нужен там.

    Соответственно, три бульдозерных модуля (6 ALU, 3 FPU) на один GPU - будет прекрасная пропорция: трое выгребальщиков-нагребальщиков а еще три ядра тоже что-то считают. Скажем, 8 операций на такт (2 128-битных FMA), да на 3 гигагерца - получается заметная прибавка к скорости GPU (которая в районе 500GFLOP/s на double на сегодня).

Только вот программировать это место придется особо, с явным мэппингом вычислительных/IO threads к парам ядер, чем сложнее оборудование, тем больше гемороя...

Из той же новости:

... but where Intel currently outsells AMD by about 19 to 1. In 2006, the ratio was about 3 to 1 in Intel's favor.
5% рынка? Что, уже все так плохо? А по серверам как?

Pages