40 ответов в теме

[DIMFIRE]

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

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

1. ложь. Я не говорил ничего подобного-был прямой вопрос "когда ццп в последний раз грейдило кластер", на который мне ответили.
2. ложь и передергивание сказанного. Давались другие сроки и говорилось про мощность систем как таковых а не про конкретный процессор
3. передергивание и подмена понятий. Нас не интересует и никогда не интересовал "любой код", нас интересовала ева-ибо процессы в еве могут быть распараллелены процентов на 85-90

А в целом возникает вопрос-вранье и подмена понятий это ваша стандартная методика дискуссий или вы сделали исключение специально для меня?

[DarkPhoenix]

1. ложь. Я не говорил ничего подобного-был прямой вопрос "когда ццп в последний раз грейдило кластер", на который мне ответили.

Формально - вопрос, а выглядит - как вайн из-за выделенного фрагмента.

Напомните мне пожалуйста, когда ццп последний раз обновляло железо? Год назад? Два?

Почему?

В данный моент удвоение мощьностей происзходит каждые 8-10 месяцев.

2. ложь и передергивание сказанного. Давались другие сроки и говорилось про мощность систем как таковых а не про конкретный процессор

Систем? Каких систем? Можно конкретными примерами, а то я немного не понимаю? Если ты имеешь ввиду "процессор стал быстрее на 10%, диск на 15%, оперативка на 2%, ..., вентилятор быстрее на 20% - итого перемножаем/складываем, в 2 раза!

3. передергивание и подмена понятий. Нас не интересует и никогда не интересовал "любой код", нас интересовала ева-ибо процессы в еве могут быть распараллелены процентов на 85-90

Можно поинтересоваться, откуда такие выводы?

[DIMFIRE]

Вы предлагаете обьяснить вам что такое производительность? Или же вас интересует что такое многопроцессорные вычисления? исходя из вами сказанного мне придется начинать оба вопроса с нуля-чего я делать не планирую.

Сообщение отредактировал DIMFIRE: 17 June 2011 - 11:42

[DarkPhoenix]

Вы предлагаете обьяснить вам что такое производительность? Или же вас интересует что такое многопроцессорные вычисления?

Да. Объясни, пожалуйста.

[DIMFIRE]

Да. Объясни, пожалуйста.

Я даже не знаю смеяться мне или плакать

[CHoh]

Не стоит брать пример с некоего ошимы, который любитель яростно засирать топики этим смайлом в ответ на обоснованную просьбу развернуть тезис.

Подробный, хорошо аргументированный ответ ещё никому не вредил. Разве что рабочий (ну или учебный) процесс страдает..

Сообщение отредактировал CHoh: 17 June 2011 - 14:25

[DIMFIRE]

Отсутствие вреда не равноценно пользе-пусть в обратном и пытаются убедить всяческие произвоители бадов

А попытка дать ответ на подобный вопрос заведомо бесполезна-сам факт подобного вопроса в рамках данного топика подразумевает что ответ принят не будет

[Atmega]

Ну, за месяц конечно могли накопать и поболее оптимизируемых кусков, чем этот. Однако же, 8% на дороге не валяются, я бы на месте CCP им премию бы дал. Результат как 15 символов кода - не впечатляет, снижение загрузки - вполне впечатляющее.

[Basil]

За что люблю Димфайра, так это за многочисленные фейлы. Если бы он внимательно прочитал девблог, то понял бы, что проблема тут не в вычислениях, а в вызовах удаленных объектов. Нетворк коллы кагбэ медленные,да. Сериализация, десериализация, установка соединения, все дела. Что-то мне подсказывает, что апгрейд вычислительной мощности в 2 раза прирост производительности в 2 раза не даст. И распараллеливание в текущей архитектуре тоже слабо поможет, ибо основные тормоза, судя по предпринятым фиксам, кроются именно в удаленном вызове объектов. Сейчас его стали инстанцировать локально - сразу буст на 8%. Далее. Распараллеливать имеет смысл только те вычисления, которые могут быть распаралеллены. В частности, если распараллелить откачку цели логистами(допустим) и урон по ней(ну обрабатываются события в разных потоках), то тут возникает очень такая серьезная проблема синхронизации событий на стороне сервера, что в массовых боях может привести к интересным последствиям - например, урон идет, а откачка не работает, и наоборот.

А так в целом впечатление от девблога приятное, да. Видно, что люди разбираются в коде, и вносят разумные фиксы.

Сообщение отредактировал Basil: 17 June 2011 - 14:53

[Yaponiz]

Ну, за месяц конечно могли накопать и поболее оптимизируемых кусков, чем этот. Однако же, 8% на дороге не валяются, я бы на месте CCP им премию бы дал. Результат как 15 символов кода - не впечатляет, снижение загрузки - вполне впечатляющее.

Вот только CPU-per-User далеко не единственный, и скорее всего не самый важный показатель скорости сервера. Так что если эти 8% выльются хотя бы в 3% общей производительности - это будет просто супер. Хотя даже 1% был бы хорошим показателем.

[Basil]

Вот только CPU-per-User далеко не единственный, и скорее всего не самый важный показатель скорости сервера. Так что если эти 8% выльются хотя бы в 3% общей производительности - это будет просто супер. Хотя даже 1% был бы хорошим показателем.

Это интегральный показатель. Скорее всего показывает, сколько тратится в среднем на обработку запроса от одного пользователя в гриде, так что ему вполне можно доверять, имхо .

Сообщение отредактировал Basil: 17 June 2011 - 15:31

[shelmimo]

Это каких мощностей? Потребляемых...

Думаю он имел в виду очередную интерпретацию "закона Мура", который будучи эпирическим наблюдением все же более-менее соблюдается, правда отклонений все больше.

DIMFIRE , если я прав, то там 18 месяцев, никак не 8-10.

Сообщение отредактировал shelmimo: 17 June 2011 - 15:33

[Psihius]

Хоть сейчас процессоры и мощьнее чем раньше при тех же частотах, но основной прорыв в вычислительной мощьности какраз в кол-ве ядер. А вот само ядро как физический исполнитель комманд в скорости не сильно убыстрилось. А CCP какраз работает в одном потоке, а следовательно все эти 3-4 кратные увеличения мощьности за счёт ядер их не коснулись.

Да, оптимизация архитектуры ядер и их вычислительные способности увеличиваются - особенно что качается математики, всяких SSE & Co. Но обычному коду, который тупо исполняет логику и работу с данными это пофигу - такому коду важна частота процессора. Потому что скопировать данные из переменной А в переменную Б занимает N циклов и никакие оптимизации тут не сделаешь - потому что это работа с памятью. А та часть вычислений, которая всё же происходит, в EVE достаточно мала и хорошо оптимизированна и так - CCP об этом писали в девблоге, что физический движок Destiny на самом деле занимает малую часть ресурсов.

Что касается распаралеливания. У CCP и так в кластере все сервисы разнесены по нодам - Inventory, Market, SOL, etc - в девблоге это описывалось - список там не маленький. Т.е. по сути у них и так уже в общем-то всё что можно было - распределено. А ядро, которое отвечает за обработку движений и взаимодействий в космосе очень сложно, если вообще реально, распаралелить. Разделив на несколько потоков взаимодействие столкнёшься с проблемой синхронизации данных и блокировками операций над объектом. К примеру:

Есть два шипа - А и Б. Система обсчитывает всё раз в секунду. Представим что у нас распаралелена обработка дамага и откачки.
Они ведут бой. Шип А на грани смерти и у него врубается очередной цикл шилдбустера. В этот момент в него влетает очередной залп противника.
Если обсчитать залп первым - шип взорвётся. Если шилдбустер - останется живой, т.к. откачалось больше чем дамага вошло.
Как определить что произошло первым? Нужно делать какую-то систему, которая позволила бы это сделать и синхронизировать события между двумя потоками и обработать в правильном порядке.
В итоге получается ситуация, что мы больше тратим времени на синхронизацию (передача данных между потоками не такая тривиальная штука, как кажется. Это довольно долго) чем на сами вычисления. Если взять одну и туже мощьность - то с вероятностью 50% станет только хуже от распаралеливания. Иногда даже сильно хуже. Т.е. можно распаралелить программу, но выигрыш получить 10-15%, а то и вообще негативный эффект получить.
Паралельное программирование штука весьма сложная и слабо развитая ещё. + некоторые вещи принципиально не паралелятся вообще никак.

Сообщение отредактировал Psihius: 17 June 2011 - 16:57

[DarkPhoenix]

Хоть сейчас процессоры и мощьнее чем раньше при тех же частотах, но основной прорыв в вычислительной мощьности какраз в кол-ве ядер. А вот само ядро как физический исполнитель комманд в скорости не сильно убыстрилось. А CCP какраз работает в одном потоке, а следовательно все эти 3-4 кратные увеличения мощьности за счёт ядер их не коснулись.

Это в машинах конечных пользователей многоядерность/многопроцессорность - в диковинку. Забодяжить кучу процов в один блок сверх определенной меры мешали разве что всякие электромагнитные поля, давящие сигнал, на печатных платах. Но иметь 6-8 процов в 1 блоке - можно было уже давно.

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

Ты упоминаешь синхронизацию (при доступе 2+ потоков к 1 объекту) и некую "передачу данных между потоками" (зачем? Данные в основном шарятся, а не передаются) в одном посте. По-моему, что-то из них лишнее.

[MiX]

Имхо очередная отмазка на тему - "мы все видем, мы работаем..."

[Kil]

Есть два шипа - А и Б. Система обсчитывает всё раз в секунду. Представим что у нас распаралелена обработка дамага и откачки.
Они ведут бой. Шип А на грани смерти и у него врубается очередной цикл шилдбустера. В этот момент в него влетает очередной залп противника.
Если обсчитать залп первым - шип взорвётся. Если шилдбустер - останется живой, т.к. откачалось больше чем дамага вошло.
Как определить что произошло первым? Нужно делать какую-то систему, которая позволила бы это сделать и синхронизировать события между двумя потоками и обработать в правильном порядке.

Думаю, что все гораздо проще. Имеем значение -XXX дамага и значение +YYY накачки щита. И они просто складываются. Получили отрицательное число ZZZ - значит щит сдувается, имеем положительное ZZZ - щит накачивается, не смотря на обстрел. Это - гораздо более простая модель, при этом исключающая упомянутые Вами вопросы синхронизации. Зачем в игровом движке плодить сущности реального мира без меры? И да - в этом случает не надо ничего распараллеливать, не надо синхронизировать, не надо делать лишней работы. Получили в любом порядке два числа, по таймеру сравнили их. Профит!

[Argonicus]

Думаю, что все гораздо проще. Имеем значение -XXX дамага и значение +YYY накачки щита. И они просто складываются. Получили отрицательное число ZZZ - значит щит сдувается, имеем положительное ZZZ - щит накачивается, не смотря на обстрел. Это - гораздо более простая модель, при этом исключающая упомянутые Вами вопросы синхронизации. Зачем в игровом движке плодить сущности реального мира без меры? И да - в этом случает не надо ничего распараллеливать, не надо синхронизировать, не надо делать лишней работы. Получили в любом порядке два числа, по таймеру сравнили их. Профит!

А что делать если циклы не совпадают? и совпадают например каждые 4 цикла? С какой частотой будем считать?

[Anastasy]

Ну вроде Дестени как бы раз в секунду всё обсчитывает, и может быть когда нибудь будет чуть реже

[Psihius]

Ну вроде Дестени как бы раз в секунду всё обсчитывает, и может быть когда нибудь будет чуть реже

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

Скорее всего обсчёт одного грида практически разделить не возможно. А пока реальность войн такова, что вся массовка и забивается в один грид. Т.е. в любом случае необходимо что-то менять, что бы в один грид не напихивалось по 1500+ пилотов.

Сообщение отредактировал Psihius: 20 June 2011 - 13:54

[Basil]

Скорее всего обсчёт одного грида практически разделить не возможно. А пока реальность войн такова, что вся массовка и забивается в один грид. Т.е. в любом случае необходимо что-то менять, что бы в один грид не напихивалось по 1500+ пилотов.

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