РАЗНОСТЬ ТЕХНОЛОГИЙ
Чем дальше в лес — тем толще партизаны. Популярные ну очень большие системы реального времени. Особенно ММО; но и те кто просто МО — там же, тогда же. Хотя бы потому, что отдельных сессий очень много. Творчески разделять, и делать вид, что властвуем. Разбивать на кластеры и жить в прошлом веке. Всякий случайный доступ к памяти, всякая сборка мусора, красивый вынужденно многонитевый код. EA STL, а лучше C# или жаба; морда на флеше, гуй на флеше. Шкаф, вентилятор, радости в жизни. Догоним и перегоним Blizzard.
Железные люди смеялись. NVIDIA CUDA. Intel Larrabee. IBM Cell. (Кстати, а что у AMD\ATI?). Даже банальный клиентский код уже очень давно просит много нитей. 2010 год на носу — одноядерные процессоры уже, наверное, никто не делает. Изготовителям драйверов пламенный привет — когда-нибудь Simon расскажет почему. Но речь не про клиент.
CUDA STL??? Или, хотя-бы, CUDA LISP… Или таки шкаф с IBM Cell…. Сомнения меня не оставляют. Масштабы сомнений или сомнения в масштабе. Когда система перерастает из большой в очень большую, худшие случаи имеют тенденцию превращаться в типичные. Код про O(N) превращается в O(N*LogN) – иногда, при сборке мусора, или просто так. 30 мсек помноженные на 10.000 пользователей — это такой лаг в 5 минут. Every 5 minutes god kills a kitten – think of kittens.
А давайте запишем каждую транзакцию в лог. Желательно в виде читаемого текста. А потом попробуем в нём что-нибудь найти. Напишем перловый скрипт. На ruby. Напишем систему анализа логов. Банки такое делают очень давно, жаль что до сих пор приходится «подождать» перевода денег. А это только логи — из того что на поверхности. На этаж ниже — чудесные чудеса, про которые никто нигде никому ничего не сказал. Я бы много денег дал, посмотреть на тот тулсет.
Не дышит, начинает заикаться к понедельнику — давайте придумаем еженедельный (ежедневный??) рестарт. А потом придумаем куда девать backup. А потом придумаем откатываться на предыдущие состояния. Ну кроме тех состояний, за какие мы берём деньги. Эти запишем отдельно. А где облажаемся — там телефонный номер и человеческий фактор.
Разделяем. Властвуем. Обратно в 1985. Только … давайте не будем чуть-чуть беременные. Давайте очень статический код. CUser g_allUsers[MAX_USERS_FOR_REAL]. Никаких malloc \ free \ new \ delete \ gcnew \ insert_you_bullshit_way_of_handling_lifetime_here. Никого скрипта. Никаких случайных доступов к памяти. Очень локальные данные линейно. Чтобы можно было прям на CUDA. Прям на SPU. Прям как есть data_in → data_out. А сбоку константное состояние. Не хотите? Я тоже не хочу.
Где-то там есть какое-то такое золотое сечение, когда слева очень простой код — а справа очень простой код. Слева data_in → data_out, и константое состояние. Справа data_in → data_out, и состояние тоже не меняется. Слева данные в памяти линейно. И справа не лежат абы как в произвольных контейнерах. И только где-то в середине медленно крутится очень асинхронный код про настройки, события, инициализацию, протоколирование, и прочие замечательные задачи — и пусть C# будет ему пухом. Надо только где-то его найти.
Пока не нашли — а зарплату уже надо получать? Кризис? Таки лучше всего работает тот самый код — который не написан. Не дописан. Без архитектуры. Без дизайна. Без абстракций. Прям как есть. За вычетом лишних технологий.
Ну вот не придумали как эффективно обрабатывать 10000 паровых стейт-машин — не делаем; упрощаем дизайн, потом ещё упрощаем — снова сортируем по состояниям, храним в явном виде. Пишем очень плоский код — вот прямо запрещаем наследование глубже 3х. Пишем object_manager->process ( object [] all_objects ) а не foreach ( all_objects ) → process. Пишем, стираем, пишем снова. User g_allUsers[MAX_USER_COUNT * MARKETING_BOOLSHIT].
Код про много-много объектов не может обрабатывать один объект за раз. Совсем не может. Правда-правда. Работать на уровне абстракций он тоже не может.
Давайте писать «как есть»?
