Показаны сообщения с ярлыком perfomance. Показать все сообщения
Показаны сообщения с ярлыком perfomance. Показать все сообщения

19 июля, 2009

Энди и Билл

Вчера моя девушка купила себе Sims 3. Ну вы знаете... Маленькие человечки, которые постоянно требуют спать и есть. Эдакие тамагочи, которым хватает вычислительной мощности чтобы обсчитывать нравятся ли им их соседи, босс и прическа того волосатого парня, который косится на них в течении всей вечеринки. Полторы тысячи за лицензионную копию. И на обороте бокса вы можете прочитать:

Системные требования CPU: (XP) процессор P4 с частотой 2,0 ГГц или аналогичный: (Visa) процессор с частотой 2,4 ГГц или аналогичный. RAM: (XP) 1 Гб оперативной памяти: (Vista) 1,5 Гб оперативной памяти.

Кто-нибудь задумывался над смыслом таких требований? Почему Vista требует на 20% более мощный процессор и на 50% больше оперативной памяти?

Существует шуточный закон "Что Энди дал, то Билл забрал" (“Andy giveth, and Bill taketh away"). Это означает, что прирост производительности даваемый каждым новым чипом компании Intel (Andy Grove) уравновешивается performance penalty нового продукта Microsoft (Bill Gates).

Конечно, это шутка, но в кажой шутке есть доля правды. Дайте программисту в два раза более мощный процессор и он найдет причину делать в два раза больше работы или не будет чувствовать особой вины в том, чтобы делать работу в два раза менее эффективно. Зачем тратить время на оптимизацию ПО, если можно просто купить более мощный процессор? Это называется вертикальным масштабированием. И иногда, это чертовски хороший подход, потому что время программиста стоит дороже, чем время процессорное. Возьмие для примера Amazon'овский Elastic Cloud. 1 час работы на восьми EC2 Unit (каждый unit это Opteron/Xeon c частотой примерно 2.5 ГГц) стоит... 80 центов. Это примерно 18500 рублей в месяц. За такие деньги квалифицированного программиста вы себе не наймете. Но вертикальное масштабирование не панацея. И рано или поздно оно перестает работать. Учитывая, что тот экспоненциальный рост частоты процессоров (читай производительности) о котором говорят на каждом углу перестал быть экспоненциальным еще в 2003 году, оно пересает работать скорее рано чем поздно. Да да, у нас появилось много ядер. Новая линейка чипов Intel для настольных систем содержит 4 физических/8 логических процессоров (кто бы мог подумать, HyperThreading по прежнему жив). Но значит ли это что приложения стали выполнятся в 4 раза быстрее? Нет.

Тому есть несколько причин. Во-первых, есть задачи, которые не параллелятся в принципе. Разбор XML хороший пример. Это чистого вида sequential задача. Во-вторых, есть так называемые точки сериализации, о которых я писал раньше. Из-за них процессоры должны тратить некоторое время на обеспечение когерентности кеша, чтобы иметь корректное отображение оперативной памяти в кешах. Эти точки сериализации есть всегда (многие процессы, такие как выделения памяти, требуют координации на уровне операционной системы). Безусловно, то что я сказал, это некоторое упрощение реальной ситуации. Но смысл в том, что 2 * 2 ГГц не равно 4 ГГц.

Наша проблема в том, что долгое время мы ставили знак равенства между частотой и производительностью. Что может быть проще, чем просто дождаться "следующего шага" Intel? Своего рода free lunch, о котором писал Herb Sutter еще в 2005 году.

Справедливости ради хочу сказать, что я не виню Microsoft. Наоборот Windows 7, по моему мнению, делает успехи, и не только в плане производительности. Но мы должны отказаться от той мысли, что инженеры Intel и AMD смогут легко увеличить производительность наших приложений путем наращивания частоты. Теперь эти самые инженеры делают все для того, чтобы экспоненциальная гонка не останавливалась, даже если для этого придется заставить программистов сменить парадигмы программирования.

Что мы и наблюдаем. Функциональные языки набирают обороты. Microsoft Research занимается разработкой Maestro. Java получает fork/join framework и обзаводится реализацией software transactional memory. И это только верхушка айсберга.

По словам того же Herb'а Sutter'а, существующие реалии развития микропроцессоров должны совершить революцию во взглядах на то, как мы должны писать программы. Последнюю такую революцию, по его мнению, совершило объектно-ориентированное программирование. Я более спокоен во взглядах на то, какую роль в нашей жизни играют параллельные вычисления. Но в чем-то Herb прав. Если хотите быть хорошим специалистом, самое время начать получать опыт работы с конкурентыми задачами.

Пока же Intel выжимает из своих процессоров все для того чтобы повысить sequential execution speed. И пока это так, я могу смело запустить Sims 3, продать старую раковину, купить новые обои в гостиную и пригласить кого-нибудь на сегодняшнюю вечеринку. Чертовски забавная игра, все таки.

28 июня, 2009

Perfomance vs. scalability

Иногда встречаюсь c непониманием того, что такое производительность, а что такое масштабируемость. Почему-то некоторые люди считают, что это одно и то же.

С производительностью все более менее понятно. Это мера скорости работы системы. Запрос поступает в систему и через некоторое время система генерирует ответ. Это время (которое иногда называют latency) и является мерой производительности системы. Для интернет-приложений время получения ответа клиентом может быть значительно больше, чем время генерации ответа на стороне сервера (потери в канале, необходимость загрузки дополнительных статических ресурсов и т.д). Обычно эти издержки не учитываются при оценке производительности, хотя надо признать, они могут очень сильно влиять на user experience работы с приложением.

С масштабируемостью все немного сложнее . Если производительность это ответ на вопрос "как быстро?", то масштабирумость — на вопрос "как много?". Как много пользователей одновременно могут пользоваться ресурсом? Как много данных может быть в базе данных прежде чем она перестанет справляется с нагрузкой?

Иначе говоря, оптимизация под производительность подразумевает делать ту же работу используя меньше ресурсов. Под масштабируемость — используя больше ресурсов, делать пропорционально больший объем работы.

Это может показаться странным, но оптимизация под масштабируемость нередко приводит к худшей производительности. С точки зрения производительности наверное нет ничего лучше чем sql-вызовы прямо в шаблоне (зачем тратить лишнее время на вызовы полиморфных методов, да?). Но для того чтобы хорошо масштабироваться по объему данных в БД, необходимо уметь "пилить" нагрузку между серверами. А для этого требуется гибкий механизм диспетчеризации обращений к базе данных (ORM, ActiveRecord, DataMapper, DAO или что там у вас). Нам нужен некий промежуточный слой, который бы абстрагировал клиента от знания где именно (на каком сервере) лежат данные, которые он запрашивает. В зависимости от специфики реализации такие слои могут добавлять существенный overhead к latency ответа. И все это делается только ради того чтобы быть больше, а не быстрее (на самом деле делается гораздо больше, это всего лишь частный пример), потому что в большинстве случаев быть большим выгоднее, чем быть быстрым.

Только не поймите меня неправильно, я не хочу сказать, что быть быстрым не надо. Пользователи не будут ходить на ваш ресурс если страницы будут открываться по 10 секунд. Что я хочу сказать, так это то, что ваши пользователи не будут платить вам больше, если страницы вашего ресурса будут открываться не 0.2 секунды, а 0.1. Но если у вас будет в два раза больше пользователей...