Онтология

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

Ричард Фейнман, Computers From The Inside Out

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

Давным-давно я помогал создавать сайт для продажи компьютерных комплектующих. Данные сгружались по ночам с основной базы данных, написанной на языке COBOL. Цены были умопомрачительными: самая дешевая мышка стоила 9990 долларов. Однажды наш суровый главный инженер мне сказал: «Смотри, мы сохраняем все наши цены в милях. Это одна тысячная доллара. Таким образом, мы избегаем ошибок, связанных с десятичными цифрами, когда просчитываем скидки и комиссии. Тебе стоит обратить на это внимание».

И он был прав. Мили – такая же единица измерения валют, как и другие. И даже если бы такой не было, это не сделало бы его идею хуже. То, что все будут использовать одни и те же единицы измерения, и эти единицы будут иметь большую разрядность, чем того требуется, позволяет обойти целый класс возможных ошибок в будущем. Иногда старики знают, что говорят.

В большинстве случаев во время измерения производительности нам приходится использовать всего несколько единиц измерения: времени, инструкций и байтов. Самая удобная единица измерения времени – миллисекунды, но иногда может потребоваться большая точность. С точки зрения экономии места, нет никакой разницы между 1 миллиардом микросекунд и 1 миллионом миллисекунд. В коне концов целые числа (integer) имеют фиксированную длину.

Тем не менее, нужно быть аккуратным и не исчерпать неожиданно те лимиты, что есть. К счастью, беззнаковые 64-битные переменные целочисленного типа (unsigned integer) могут представить полмиллиона лет в микросекундах (µsec). Я не хочу сказать, что 64 бит хватит абсолютно для всего. Но для большей части систем этого будет более чем достаточно.

Сокращение разрядности ваших значений, чтоб уместить их в 32-битное целое число, – это путь в никуда. Определите, какая степень разрядности вам может понадобиться, не жадничайте, используйте ее и потом оптимизируйте по необходимости. Конечно, вы можете поместить 71 минуту, выраженную в микросекундах и в 32-битное целое, а потом расширить его по мере надобности. Но лучше приберегите такой вариант действий на случай, когда вам действительно будет это нужно, и учтите, что для расширения понадобится больше места.

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

Байты должны быть представлены байтами. Килобайт будет слишком громоздким для некоторых исследований, тем более, все равно никто никогда не помнит, как их правильно делить (1 КБ = 1024 Б). Вероятность использовать весь резерв целого числа тут мал, но все же, есть разные мнения на счет использованной величины. Трафик принято измерять битами, восьмой частью байта. 125 гигабайт в секунду, измеряемый в битах, исчерпает резерв целого числа за семь месяцев. Еще пять лет назад терабит трафика был чем-то невероятным. Сегодня же это вполне нормальный показатель для системы. Еще через пять лет вы, без сомнения, сможете найти купон на бесплатный терабит в пачке овсянки.

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

Атака терминов

Проблема присваивания имен была в полушутку названа второй по величине проблемой компьютерной индустрии. Любой может назвать, что угодно, как угодно. Именно так все и поступают. В этом-то и проблема. Компьютеру наплевать на названия. Они придуманы для людей, так что с технической точки зрения не придерешься. Однако, избыток терминов – побочный материал новых технологий, который порождает неразбериху громадных масштабов. Тот, кто сможет решить эту проблему, окажет огромную услугу человечеству.

Вот взять, например, термин «физическое время» (walltime). Возможно, лучше было бы использовать слово «продолжительность» (duration). Время, использованное процессором, можно было бы назвать cpu_duration; время ожидания ответа от БД — db_duration и так далее. И почему бы туда еще не запихнуть единицы измерения, типа duration_cpu_usec? Если вам кажется, что так лучше, то я не имею права вам в этом отказать. В конце концов, это дело вкуса. Термин walltime (с англ. время, которое можно измерить по настенным часам) мне нравится больше, так как это термин, с которым я знаком давно. Но у кого на самом деле сейчас висят часы на стенах? Это такой же архаизм, как и «позвонить» по телефону.

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

Даже самых уродливый код, если он однородно уродлив, лучше, чем нужда запоминать, что в одной части кода продолжительность это walltime, а в другой — response_time_usec. Какую бы онтологию вы не создали, поместите ее на видном месте. Разъясните, что значат придуманные вами термины, единицы измерения, их описывающие, и будьте последовательны в их использовании.