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

Интересная статья.
#pragma unroll понимает Visual C++? Сомневаюсь.

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

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

Т.е. дело тут совсем не в float, а в битах для хранения.

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

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

В 2.9-чего-то тоже все было вроде бы нормально, хотя я уже не помню.

Не может ли быть дело в том, что прошивка у меня 2.92? Я как-то не нашел пропатченной более новой прошивки (возможно, я дурак и нужно брать любую прошивку и патчить, но я так понял, что к каждой прошивке свой патчер)...
Спасибо!

Я ставлю и разные ProductID (-p) и разные ProductName (-m). Прошивка - 3.0, если правильно помню (прибор в шкафу и без батарей, включать лень, тем более что и карт в нем сейчас нет).

Карты в меню выбора "что показывать" группируются по ProductName (ключ -m у map2jnx)

Соответственно, задавая разные значения -m ... для разных карт - вы делаете их выключаемыми отдельно.

Не, ну матрица дана нам снаружи, конечно же можно домножить ее на константу так, чтобы и лишнего переполнения в 32 битах не было и точность не терялась.

Ну и может быть обратная сторона: в матрице уже очень большие значения, но с разным знаком. И результат умножения в float влезает (а после сложения - остается в 16-битном диапазоне), а в int - не хватает пары десятков порядков. В этом случае, наоборот, надо бы поделить на константу....

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

Собственно, если взять и "тупо поменять на int" матрицу из примера, то получится матрица:
{0,0,0,0},{1,1,1,1,1},{1,1,1,1}
Поверьте - результат расчетов с такой матрицей будет совсем иной :)

мда зарапортовался )
мои жалобы были против "экономии на памяти" и гигабайтов в памяти в виде float[] картинок. sorry.

поскольку сейчас на работе простой :) попробовал ваш сниппет и на 2008й если тупо заменить матрицу и out на int и вставить clamp(0, ushort_max, out[cc]) то оно в пару раз быстрее. Разумеется надо мерять оптимизированный против оптимизированного :) так как и там и там оно не векторизировало ничего. Мое впечатление что если возня с переводом матрицы в целые себя оправдает то на пре-avx машинках целочисленка выиграет с малым отрывом.

с выводом что вычисления сейчас очень дешевы по сравнению с хранением я не спорю просто это никак не связано с ценой гигабайта RAM. Как в шутку сказал в одной из недавних презенташек Meyer "RAM is new disk".

ну так я и объясняю что потому и 16бит что нельзя весь bandwidth выжирать в одно горло. А будете вы там конвертить прочитанные шорты во флоаты или нет это практически не повлияет на поведение системы под нагрузкой на все cpu. Кстати будете смеяться, но на gpu специально есть float16.

А компиляторы и вся эта "модель черного ящика" в стиле plug'n'pray мне уже в печени сидят.

простите мой френч но читать из памяти по 2 байта в 2011 это диагноз. Зачитать в вектор из 8ми шортов и сделать пару shuffle и все полетит как птица. Ваши 10G моментально начнут упираться в bandwidth как только вы запустите на всех ядрах что-то такое же.