Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста

Сейбел:А C++ вы используете из-за его эффективности.

Фицпатрик:Скорее всего, да. В основном я пишу на нем в Google. Там все, что более или менее требует производительности, пишется на C++. Кроме того, в Google я много пишу на Java.

Сейбел:Насколько я понимаю, в компании Google сложилась “С++-центрическая культура”, поскольку они использовали этот язык с самого начала, построив на его основе обширную программную инфраструктуру. Хотя и нельзя просто так взять и забыть свою историю - пожалуй, на C++ в Google написана значительная часть кода, которая не требует такой эффективности.

Фицпатрик:Особенно учитывая, что со временем Java стал быстрее, a JVM - значительно умнее. В Java мне не нравится то, что у всех сложилось стойкое отвращение к JNI [22] JNI (Java Native Interface) - инфраструктура, позволяющая взаимодействовать коду внутри JVM с “неуправляемым” (native) кодом, таким как API операционной системы или любой код на Си или C++. - Прим. науч. ред. . Есть библиотеки на C++. Разработчикам, использующим Python, как внутри компании Google, так и за ее пределами, все равно. Их первая мысль: “Да мы просто обернем все это с помощью SWIG [23] SWIG (Simplified Wrapper and Interface Generator) - инструмент с открытым исходным кодом, предназначенный для взаимодействия языков программирования C/C++ с языками сценариев, такими как Tel, Perl, Python, Ruby и др. - Прим. науч.ред. ”. У них есть собственный путь, и они счастливы. Разработчики на Python могут сразу же использовать все, что написано на C++, потому что они не относятся так благоговейно к языку источника.

А сторонники Java говорят: “Надо писать только на чистом Java. Мы не можем использовать JNI, потому что если JVM рухнет, то мы не узнаем, почему”. Проблема в том, что все приходится писать дважды - один раз для C++, Python и прочих языков, а второй раз для Java. Так что если они найдут хороший способ взаимодействия или избавятся от страха перед JNI, то я не буду иметь ничего против Java.

Сейбел:А как насчет вопроса “ручное управление памятью против автоматического”? Об этом все еще спорят. У вас есть твердое мнение на этот счет?

Фицпатрик:По правде говоря, нет. Занятно смотреть, как люди высказывают твердое, ничем не подкрепленное мнение. Лично мне ручное управление памятью не кажется таким уж раздражающим, по крайней мере, в C++ с умными указателями. Я могу днями писать на C++, ни разу не применив явно оператор new или delete. Вот так.

Я переписал memcached, уже работая в Google, для работы с инфраструктурой Google и для добавления ее к Арр Engine [24] Google Арр Engine - сервис хостинга сайтов и веб-приложений на серверах Google с помощью различных служб Google. См. http://ru.wikipedia.org/wiki/Google_App_Engine . - Прим. науч. ред. . Она написана целиком на C++, потому что мне было нужно очень строгое управление памятью для уменьшения фрагментации. И я очень рад возможности ручного управления памятью в C++.

Сейбел:Изначально программа memcached была написана на Си. Вы переписали ее на C++, потому что этот язык предпочтительнее в Google или у него есть другие преимущества?

Фицпатрик:Сперва я хотел просто взять существующую реализацию и перенести ее на C++, но работы оказалось слишком много. Оказалось не так много кода, которым я мог бы воспользоваться, поэтому было гораздо быстрее просто переписать его на C++. Объем кода уменьшился вдвое.

Сейбел:Это из-за C++ или из-за того, что вы стали опытнее?

Фицпатрик:Может, и из-за опыта. Лет в 11-12 я путешествовал с родителями по стране и писал игру Mastermind для калькулятора TI-85 - пару сотен строк - на крошечном экранчике, пытаясь понять, что же я делаю. Я дважды стирал эту проклятую штуковину. Так что я написал ее три раза. Но с каждым разом становилось все легче. Верно подмечено: разрабатывать систему во второй раз намного проще.

Сейбел:Вы много писали на Perl, весьма симпатичном высокоуровневом языке программирования. Как по-вашему, насколько “низко” нужно спускаться программистам? Нужно ли им знать ассемблер и понимать, как работает процессор?

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

Занимаясь Живым Журналом, я думал о разных вещах, начиная от языка JavaScript и заканчивая вопросами взаимодействия с ядром операционной системы. Я читал код системных вызовов epoll [25] epoll - новый системный вызов, который появился в Linux 2.6. Призван заменить устаревший select (а также poll). В отличие от старых системных вызовов, длительность работы которых зависела от количества прослушиваемых дескрипторов, epoll использует алгоритм, который не зависит от количества дескрипторов, позволяя добиться хорошего масштабирования при увеличении количества прослушиваемых дескрипторов. - Прим. науч. ред. в ядре ОС Linux и думал: “А что если у нас будут все эти длительные соединения по протоколу TCP, и код на JavaScript будет опрашивать открытые TCP-соединения, ведущие к системе балансировки нагрузки?” Я попытался понять, сколько памяти нужно каждой структуре данных на одно подключение. Все это вопросы достаточно высокого уровня, но потом мы задумываемся, скажем, об огромном количестве прерываний от сетевой карты - не переключиться ли нам на использование NAPI ядра ОС вместо получения прерывания по каждому принятому пакету от сетевой карты, которые она будет соединять со скоростью, эквивалентной 100 мегабитам, даже для гигабитной сетевой карты? Мы собирали данные, чтобы определить, на каком уровне это будет иметь смысл и освободит процессор.