[prog.flame] И снова gandjustas! :) На это раз про оптимизацию программ и кластеры

Впервые за довольно долгое время заглянул в RSDN-овский форум "Философия программирования". Оказывается, народ еще активно срется на тему C++ vs Managed (JVM, .NET + все остальное). Надо же, ничего не меняется :) Попробовал почитать. Вначале было забавно, немного поностальгировал. Но быстро надоело, появилась досада на бессмысленно убиваемое время. Но тут в списке авторов ответов промелькнуло имя gandjustas... С надеждой щелкнул на первое сообщение начатой им ветки обсуждения и не разочаровался, gandjustas все еще торт!

Кластер нужен как минимум для отказоустойчивости. Надежность в серверных приложениях нужна гораздо больше оптимальности. Дешевле добавить память, диск, процессор, чем оптимизировать программу. Для примера представь что серверу для работы на всю компанию нужно 16гб оперативки. Есть всего восемь. Вариант — оптимизировать приложение, два месяца работы, два месяца исправления багов, при ЗП в 100к — 400к + упущенная выгода + административные расходы. Добавить 8гб памяти — 5к + день работы.

Когда-то, давным-давно, меня просветили, что есть два типа масштабирования приложений:

• вертикальное, когда повышение производительности приложения достигается путем обновления железа: добавление памяти, установка более мощного процессора, более быстрых жестких дисков и т.д.;
• горизонтальное, когда повышение производительности приложение достигается путем добавления новых машин в кластер, на котором развернуто приложение *.

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

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

Прошу простить мне мой сарказм, но я себе слабо представляю, как можно решать проблемы масштабирования, не занимаясь на этапе проектирования приложения вопросами разделения работы между вычислительными ресурсами и контролем их загруженности. Да и вопросы отказоустойчивости, в зависимости от предметной области, могут требовать выбора тех или иных подходов на самых ранних этапах проектирования, как, например, обеспечение отказоустойчивости платежного приложения, выполняющего списание финансовых средств. И тут уже расчеты будут совсем другие, нежели "5k RUR + день работы" **.

BTW, high performance cluster вовсе не обязательно дает хоть какую-то отказоустойчивость (см. HPC хотя бы в Wikipedia). А high availability cluster вовсе не обязан обеспечивать высокую производительность (см. HA cluster там же). Но это уже совсем-совсем другая тема для разговора, в которой и я сам не чувствую себя достаточно компетентным.

---

* В принципе, для некластерных (например, десктопных) приложений так же может быть возможно горизонтальное масштабирование посредством замены процессора, если новый процессор имеет больше вычислительных ядер и приложение умеет эти ядра загружать, разделяя свою работу между ними. Это относится не только процессору, но и к другим типам ресурсов: жестким дискам, сетевым картам, подключенным к машине внешним устройствам (вроде GSM-модемов, PC/SC-ридеров, HSM-модулей и пр.) Т.е. в более широком смысле горизонтальное масштабирование для приложения -- это умение приложения разделять свою работу между всеми поступающими в его распоряжение ресурсами и, за счет этого, возможность увеличения производительности приложения за счет предоставления ему дополнительных ресурсов.

** Хотя эффективные менеджеры могут все.

[prog] Не могу не выдернуть из контекста пассаж про верификацию программ

Персонаж с ником gandjustas у меня уже мелькал – цитировал я его высказывания с RSDN. С удовольствием сделаю это еще раз.

Итак, замечательная фраза:

Главное преимущество managed кода знаешь?
Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.

На что его вполне резонно спросили:

А что именно значит "ничего криминального"? Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль? Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы? Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?

И тут последовал совершенно феноменальный ответ:

Я с теорией верифцирования не сильно знаком, но верификация и сейчас производится.

И там же:

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

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

Verification and Validation (software)
Formal methods

PS. Кстати говоря, то, о чем говорит gandjustas – проверка отсутствия обращения по неверным указателям, проверка отсутствия выхода за пределы массивов, перезапись переменных на стеке и пр. – вовсе не являются свойствами управляемого кода. Компилирующиеся в нативный код языки со сборкой мусора и контролем за массивами и отсутствием адресной арифметики (Oberon, Eiffel, OCaml и, отчасти, Ada) дают точно такую же безопасность. Может быть даже большую, поскольку Ada контролирует в run-time корректность преобразований типов (afaik, если вы объявите тип A как 1..10, а тип B как 5..11, и попробуете преобразовать значение 2 от типа A к типу B, то получите исключение в run-time).

[prog.flame] Пример программерского снобизма

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

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

Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.

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

Но прошло совсем немного времени, гормонов в крови поубавилось, изрядная доля сил, направленных на доказательство своего доминирования (по проф.Савельеву), уже истрачена. И оказалось, что я, такой весь из себя в белом и самый-самый вааще, уже всего лишь средненький программист, просравший задержавший свое мышление на низком уровне абстракции. Ну как же – пришла молодая шпана, которая сметет нас с лица земли :)

Когда-то комментатор с НТВ (не помню фамилию, к сожалению) сказал, что у комментаторов есть всего три правила:

• во-первых, нельзя считать, что ты самый умный;
• во-вторых, нельзя считать, что ты самый умный,
• ну и, в-третих, ни в коем случае нельзя считать, что ты самый умный.

За годы занятия программированием я убедился, что это очень важные правила и программисты должны им следовать.

PS. Всегда с подозрением относился к участникам форумов, которые не открывали своего настоящего имени. Есть в этом что-то подозрительное. Вот тот же gandjustas на форумах настоящий орел, но кто он по жизни? Легко быть анонимным героем.

[prog.irony] Подразумевает ли шильдик Microsoft MVP наличие какого-то кругозора?

Или же Microsoft Most Valuable Professional -- это как звание лучшего продавца года?

А то как-то дико читать вот такие высказывания профессионала:

realtime — это что за зверь такой?

PS. Таки да, это вновь тот самый gandjustas. Не перестает радовать внимательных читателей :)