?

Log in

Previous 10

Apr. 14th, 2011

Народы и на половину заполненный водой стакан


  • Американец: стакан на половину полон.

  • Немец: стакан на половину пуст.

  • Поляк: стакан на половину пуст и нам хорошо известно, кто отпил эту половину.

  • Русский: стакан полон. Неправильная гравитация и неправильный коэффициент сжатия воды не позволяют увидеть этого.

  • Китаец: при этой влажности, стакан наполняется.

Feb. 15th, 2011

Фильтрация интернета? WTF?

С моего российского компа недоступен www.aolnews.com - нельзя ни определить IP для этого адреса, ни войти на него используя уже известный IP. В частности, нельзя открыть вот этот линк (который я могу открыть у себя на компе за пределами России):

http://www.aolnews.com/2011/02/11/32-percent-of-russians-think-the-sun-revolves-around-earth/

WTF? В жизни не думал, что буду свидетелем такого явления. Буду писать в службу поддержки и выяснять.

UPDATE: Использование вместо DNS провайдера гугловского 8.8.8.8 позволило войти на сайт (вход через IP был скорее всего невозможен из-за виртуального хостинга).

UPDATE: После опросов друзей, установил, что это проблема только одного провайдера из нескольких в городе. Тем не менее, отныне буду пользоваться 8.8.8.8 всегда.

Dec. 5th, 2010

Гениальность ARMа

Второй пост подряд, но не удержался. Я просто в восторге от некоторых решений, которые приняли разработчики ARMа - того самого, что сейчас у каждого в телефоне.

Например, возьмём такой момент: ARM, как и все RISC'овые процессоры, имеет фиксированный размер инструкции. Т.е. каждая инструкция занимает только 4 байта. Из этого следует простая, но не всегда очевидная вещь: в общем случае, нельзя загрузить 32-битный регистр одной командой (не говоря уже о использовании 32-битных операндов в инструкция типа add).

С этим столкнулись в том числе разработчики PowerPC и MIPSа. Как они решили вопрос? Очень неизобретательно и прямолинейно: заставляя программиста грузить регистр 16-битными половинками (со сдвигом). Например, так выглядит код PPC для такой программы:
int main( int argc, const char * argv[] )
{
        return argc > 0x000A5000 ? 1 : 0;
}

main:
        lis 0,0xa
        ori 0,0,20480
        cmpw 7,3,0
        mfcr 3
        rlwinm 3,3,30,1
        blr

Первые две инструкции загружают в регистр 0 число 0x000A5000, по 16 бит этого числа каждая.

У разработчиков ARMа, в силу особенностей архитектуры, было только 12 свободных бит в поле инструкции. Они решили, что использовать числа 0-4095 было бы слишком большим ограничением, а грузить 32-битный регистр 12-битными кусочками - утомительно. И они пошли другим путём!

Разбивая поле в 12 бит на два: 4 бита смещения + 8 бит на сам операнд, они дали возможность программисту загружать одной командой 4096 чисел, в которых число установленных (или сброшенных) подряд битов не превышает 8. Т.е. они дали возможность загрузить один байт в 16 возможных мест 32-битного реестра: начиная с 0-го бита, или со 2-го, или с 4-го и так далее до 30-го.

Частным случаем таких констант являются все степени двойки, которые на ARMе, в отличие от PPC, можно использовать в качестве непосредственных операндов!

Число 0xA5000 тоже подходит под такое правило :) Вот как предыдущая программа выглядит на ARM'е:
main:
        cmp     r0, #675840
        movle   r0, #0
        movgt   r0, #1
        bx      lr

Казалось бы, PowerPC - RISC, и ARM - RISC, но первый - неуклюжий и громоздкий (чего стоит "рисковая" инструкция rlwinm, Rotate Left Word Immediate then AND with Mask), а второй - элегантный и компактный.

Если Sony и Microsoft ещё не планируют использовать ARM вместо PPC для следующего поколения своих консолей, то очень советую им начать :) Тем более, что ARMы растут в силе - если 1.5 Ghz для телефонов (которые, нотабене, не имеют вентиляторов и мощных блоков питания) это уже стандарт, то трудно себе представить, на что был бы способен мега-ARM, реализованный в качестве полноценного процессора для настольного компьютера или консоли!
Tags: ,

Безопасные статические переменные в gcc

По умолчанию, инициализация статических переменных в gcc блокирует доступ к ним всех остальных потоков. Наткнулся на это достаточно случайно и был неимоверно удивлён на такое вмешательство компилятора в вопросы синхронизации. На примере:
КодCollapse )
Это не выглядит сверхоптимально, учитывая, что даже в наилучшем случае (когда переменная уже инициализирована), мы почему-то лезем в память (пиша/читая со стека).

К счастью, эту заботу со стороны компилятора можно отключить (-fno-threadsafe-statics), и код становится нормальным:
Ешё кодCollapse )
Tags:

Nov. 19th, 2010

Разруха в головах и пропускная способность

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

Почувствовал себя виновным, ибо в 1992-1995-х годах сам частенько ездил "зайцем". Впрочем, в те шальные года в салонах ещё не было обязательных кондукторов, а из билетов остались, насколько помню, только проездные - которые мы покупали нерегулярно, и в основном на автобусы.

А ведь ещё в 1991 году, когда билеты подорожали с трёх копеек (в трамвае) до десяти, мы охали, но покупали. И игра в билетики (на щелбаны) держалась ещё несколько лет...

Потом была разруха. И сейчас, мне кажется, что больше в головах, чем "в клозетах". Конечно, зарплата в 9 тысяч (неденоминированных) в месяц на двоих в 1993 году - это мизер. С трудом сейчас представляется, как можно было прокормить семью за 10-20 долларов - и при этом я совсем не считал нас нищими (очевидно, не с чем было сравнивать)! Цену на билет не помню, но мне кажется, что была она в пределах 5-20 рублей... Теоретически, платить можно. Можно ли было практически? Особенно когда никто вокруг не платил, а кондукторов можно было встретить только специально их ища?

Хоть я и не думаю, чтобы у нас была лишняя тысяча рублей на разъезды, мне всё равно кажется, что разруха была в головах... Этакое всеобщее "да ну всё нах", длящееся изо дня в день и заражающее все сферы жизни. Оно начиналось ещё в 1980-х, когда подростки били первые стёкла в поездах, но только после "смерти" государственого организма у людей сорвались тормоза.

А возвращаясь к трамваям, страшно неприятно читать позитивные отклики "автомобилистов", что дескать, теперь расширим улицы, будет всем лучше. Не учитывают ни практический опыт других стран, ни теоретические рассуждения. Пределы расширения улиц малы, а росту автомобилизации естественных пределов нет. Воронеж - не Лос Анжделес, где на каждые 100 м^2 зданий приходится 120 м^2 проезжей части на разные паркинги и подъездные пути, да и там транспортной поток плохо "масштабируется".

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

Или, говоря проще, никакая разумная ширина улиц (кроме сноса зданий вообще) не даст автомобилям пропускной способности (измеряемой в тысячах людей на секунду в заданном направлении) хорошо работающей линии метро. В случае (отделённой от проезжей части) трамвайной линии ситуация похожая, но баланс находится в немного другом месте (возможно, какая-то ширина улиц будет сравнима по пропускной способности).

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

P.S. Сайт горстки людей, которые по разным поводам борятся с "оттрамваиванием" Воронежа.

P.P.S. Польский (современный) трамвай, которые постепенно эволюционирует во внутригородскую электричку.

Nov. 1st, 2010

Индустриализация мыслительного процесса

Есть большая разница между созданием чего-то раз, и массовым производством. Речь не идёт о том, что надо "набить руку" - в случае коллективного творчества эта разница - качественная, и она в корне меняет подход и процессы.

Когда я был подростком, я очень гордился, что наши (российские и вообще ex-USSR) кодеры выжимали из железа возможности по максимуму. Например, делая fake Phong на Спектруме или создавая игры, которые шустро бегали на старых писюках. Отсталость российской индустрии софта казалось, была вызвана советским "застоем" и прочими проблемами предыдущей системы, которые в 1990-х годах выглядели быстро преодолимыми. Рисовалась перспектива, в которой воспитанные на спектрумовской сцене крутые кодеры вырываются вперёд и показывают ленивым западным программистам, как можно писать крутой софт.

Что ж, частично показали, и новаторское выступление AND'а на SIGGRAPHе в этом году - мощное доказательство, что некоторые кодеры действительно имели большой потенциал - и успешно реализовали его, сделав головокружительную карьеру. Но в западных фирмах.

А в целом, российский геймдев оказался совсем не седьмым чудом света. Большинство продуктов делается на внутренний рынок, и даже на нём они - "бюджетные". Пишутся они долго, а получается лажа.

Почему так? Ведь умного народа хватает.


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

Применительно к команде, занимающейся умственном трудом, "действовать как единое целое" означает возможность как можно более полно передавать мысли между людьми. На таком уровне проблема ясна всем, но решение неочевидно. Документирование каждого своего шага - слишком утомительно. Сажать двух людей перед одним компом - слишком затратно.

Что же делать? Необходимо "размазать" документацию, сделав её (незначительной) частью нормальной работы.

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

    Как это выглядит на практике? Лучше всего - организовать внутрифирменную рассылку по почте (одну или несколько - -dev, -mgmt, -all). Почта является самым стандартным способом коммуникации, доступном на сегодняшний день на каждом устройстве, и прикрутить к нему архив - не проблема (можно создать группу Google). Ключевой момент: c помощью этих рассылок решать все вопросы, начиная от того, когда сегодня будет обед и заканчивая вопросами новых программистов к ведущим. Со временем, архив такой рассылки естественным образом станет базой знаний, которую можно пытаться упорядочить, делая из неё статьи (a la wiki).

    Начинать же с wiki я категорически не советую - утомительно и терпения не хватит.


  2. Хранить в одном месте всю историю работы над проектом. Конечно, я имею в виду систему контроли версии, в которой должно быть

    • код (это само собой)

    • все данные. как в формате, используемым программой, так и в "исходном формате" (например, файлы .psd). Это менее очевидно, но это критически важно.

    • скомпилированные бинарники под все поддерживаемые платформы (ещё менее очевидно, но тоже важно - не всегда есть время компилировать предыдущие версии, чтобы посмотреть, как что-то работало 20 ноября 2008 года).

    • документы (спецификации, планы, графики выполнения, и т.п.)



    Причём при внесении (commit/check-in) данных в базу они должны быть снабжены как можно более полным комментарием, за отсутствие которого (или его упрощение) нужно очень больно бить по рукам (а лучше - настроить триггеры на сервере и не позволять автоматически). Зачастую эти комментарии являются единственным источником, из которого можно узнать, почему человек заменил в коде цифру 5 на цифру 3.

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

    Кстати, при огромном размере данных в играх (особенно выходящих на BluRay) размер исходных файлов может достигать сотен гигабайтов (а история их изменений исчисляется в терабайтах). На данный момент только p4 (Perforce) в состоянии справиться с такой лавиной данных, git/svn/bzr/hg имеют, к сожалению, один общий недостаток - они сами считают hash'и файлов, обнаруживая изменения - что в случае репозиториев размером в 100+ гигабайт абсолютно неприемлемо.


  3. Все ошибки учитывать в специальной системе учёта ошибок. История учёта ошибок не менее важна, чем история работы над проектом и по крайней мере частично должна быть с ней связана (например, номер ревизии в поле "поправлено в").





Эти три вещи - основополагающие при "передаче мыслей" друг другу. Очень важно объять регистрацией все процессы, происходящие при разработке, чтобы позже кто-то (или сам автор) мог проследить шаг за шагом эволюцию каждой строки кода (time-lapse, svn blame, etc) или каждой "фичи".

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

Что ещё можно сделать, чтобы синхронизировать людей?

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


  2. Проводить "мастер-классы". Если кто-то придумал новую классную вещь, которую будут использовать другие, пусть он о ней расскажет и покажет. Можно и нужно записать это на видео, хотя организация внутрифирменного youtube это отдельный вопрос.



Это всё только чисто организационные вопросы. Имеется гораздо более трудная в реализации проблема в приучивании людей к "инкрементальному" мышлению, которое характеризуется тем, что вместо натуральной реакции "что это за х..ня, с этим нельзя работать, я сейчас сяду и перепишу заново" человек начинает думать "какое самое маленькое изменение я могу сделать, чтобы заставить это работать как надо"? Инкрементальное мышление - это попытка "додумать" за предыдущих авторов, а не "выдумать заново". Вышеперечисленные пункты - это только инструментарий, который необходим для человека, пробующего реконструировать процессы, которые породили монстра, лежащего сейчас перед ним. Если нет желания "додумывать за других" - они не помогут.

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

Oct. 30th, 2010

Славянские корни

Слова, которые остались в "нормальном" значении в польском языке, но в русском уже стали бранными.

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

Падло
То же самое, что "стерва" и "падаль". "Падшее", т.е. погибшее, животное. Также - "разложившийся" (в переносном значении) человек.

Быдло
Крупный рогатый скот или "скотина" в широком смысле.

Жид
То же, что "иудей" (jehudi). Интересно, что в польском "еврей" - бранное слово, "жид" - нормальное.

Oct. 17th, 2010

Юбилей

10 лет назад я начал работать программистом :) В понедельник принёс сделанное в течение уикэнда тестовое задание, во вторник приступил. Думал, что это будет part-time во время учёбы, но подхватило и понесло так, что образование заканчивал уже по инерции. И сейчас, вспоминая все эти дельфи и иные предметы в дипломе, которые стыдно показывать коллегам и даже поверенным переводчикам, думаю, что и правильно.

Зарплата тогда была на два порядка меньше, но напряжения от этого меньше не было :) До декабря 2000 был ещё плавный разгон (с окончанием работы в 16:00 31 декабря), но в январе-апреле 2001 года мы уже работали с 9 до 21 без выходных - зато мы не поддались и всё-таки сделали намеченное (а я, признаться, сильно в этом сомневался). Во многом это заслуга одного человека, которого я позже не раз ставил в пример как "руководителя, которому не пофиг".

Потом были иные milestone'ы, иные переживания. Но атмосфера начала 2000-х, когда всё начиналось получаться - и в профессиональном, и даже в каком-то общем, "всероссийском" плане - незабываема =)

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

Oct. 10th, 2010

Программирование в ассемблере

Каждый раз, когда я читаю доки в стиле этих (или особенно этих (PDF)) я вспоминаю дискуссии в 2275.LOCAL с Олегом "B-tree" (и, возможно, artolом) насчёт необходимости использования асма...

Конечно, по большому счёту, при типичном (a.k.a. скучном, a.k.a. не выжимающим с железа все соки) программировании асм давно забыт (ещё лет тридцать назад). Но тем не менее, существуют отрасли (и говорю совсем не об embedded), где его использование даёт преимущества.

Наши старые дискуссии (начало 1999, если мне не изменяет память) не учитывали следующих факторов, которые теперь более ясны:

1) Массового использования SIMD инструкций и абсолютной негодности не только компиляторов, но и самих ЯВУ для их эффективного использования (без введения "низкоуровневых" элементов в язык - типа интринсиков или использования DSL по типу HLSL/GLSL).

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

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

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

Oct. 9th, 2010

Компьютерная промышленность в СССР

Нашёл очень интересные записи разговоров с одним из работников завода "Ангстрем", проведённых в 1985 и 1987 годах. Ангстрем был флагманом советской индустрии, крупнейшим производителем интегральных схем. Между прочим, на этом заводе делались (позже, ближе к рыночной экономике) советские и российские клоны Z80.

Несмотря на то, что на первый взгляд записи трудны для прочтения, читать их интересно. Политики в них нет или почти нет, "диссидент" рассматривает вопросы с прагматической точки зрения (поэтому "диссидентство" его в кавычках, и поэтому, наверное, администрация к нему прислушивалась).

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

Под катом разбор текста с цитатамиCollapse )

В общем, очень интересный кусок информации из прошлого. Кстати, узнал, что советский аналог слова crunch - это штурмовщина ;-)

Previous 10