CargoDist vs YACD

[Wowan]

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

Ну и вообще можем тут обсуждать все, что касается двух патчей.

[kraks]

Насколько я понял, основное отличие состоит в следующем:
CargoDist распределяет грузы, УЖЕ попавшие на станции, причем только между другими станциями (т.е. некоторый пассажир не может захотеть поехать туда, где нет станции).
YACD распределяет грузы, которые как бы вообще существуют в источниках грузов (предприятиях и зданиях), причем между вообще потребителями грузов. Т.е. некоторый пассажир в некотором городе может захотеть поехать в некоторое другое место (совсем не факт, что там есть станция), в том числе и в этот же самый город (это в патче называется local destinations - локальные назначения).
Я мог ошибиться, но думаю, в главном написал правильно (просто сам читал про YACD некоторое время назад, мог что-нибудь перепутать). Теоретически YACD, конечно, работает "правильнее" и, наверное, предпочтительнее к использованию (хотя, по отзывам, играть с ним посложнее). Но он достаточно "молодой" в отличие от CargoDist, поэтому пока лучше немного подождать с его включением в патчпаки - будет глючить...

[Wowan]

Да, это я тоже так читал - первые пару страниц ветки о YACD, когда она появилась, я осилил. А потом забил читать - невозможно уследить за всеми обсуждениями.

Интересно, какой вариант предпочтительнее с точки зрения экономии ресурсов процессора?

[Ghost]

Интересно, какой вариант предпочтительнее с точки зрения экономии ресурсов процессора?

Думаю, что принципиальной разницы нет. Чтобы экономить ресурсы процессора, ему надо поделиться нагрузкой с чем-нибудь другим. Благо, ясно чем - это хорошо видно, когда в игре слегка подтормаживающей открыть кучу окошек с движущимися ТС.

[Loko]

Интересно, какой вариант предпочтительнее с точки зрения экономии ресурсов процессора?

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

[Wowan]

Насколько я помню по своим старым играм, если на станциях собирается много народу (>500), то при изрядном количестве станций на карте (>100) игра начинает подтормаживать. И напротив - пустые перроны несколько снимают проблему тормозов. Проверял сам, откручивая туда-сюда коэффициент производства грузов городом.

[Loko]

Это вполне логично. Для каждого из пассажиров генерируется точка назначения. 100 станций по 500 пассажиров это уже 50000 ячеек памяти, которые нужно постоянно мониторить. А еще есть почта, уголь, товары, лес и пр. Чем больше ячеек , тем дольше происходит их обход.

[Wowan]

Отсюда вывод: если YACD генерирует пассажиров/товары по несуществующим маршрутам - это лишние пассажиры и товары, которые занимают лишние ячейки памяти. И тогда CargoDist как идея лучше, потому что генерирует трафик только туда, куда и вправду можно доехать.

[Loko]

Не совсем. Сама генерация точки назначения в обоих случаях потребляет примерно одинаковое количество ресурсов. Но это конечно при условии, что алгоритмы генерации построены по одному принципу. При 500 пассажирах на 100 станциях количество ячеек будет одинаковым, следовательно и время их опроса тоже не должно менятся.
Но это только при условии что точка назначения генерируется при генерации пассажира один раз. Т.е. пассажир не может со временем передумать ехать в X вместо Y. В этом случае алгоритм отрабатывает всего один раз, а значит в принципе не может вызывать тормоза в дальнейшем. Естественно если ежесекундно появляется 200 новых грузов, то алгоритм отрабатывает 200 раз в секунду. Далее уже идет мониторинг. Например прибыл поезд и мы последовательно проверяем каждого пассажира сядет он в него или нет. Вот тут скорее всего тормоза и происходят, но связаны они исключительно с большим количеством данных. А количество этих данных зависит уже не от алгоритма, а исключительно от рейтинга на станции.

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

[Ghost]

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

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

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

[Loko]

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

Переписывать код не надо. ЯВУ разрабатывались как раз для того что бы программист описал, что он хочет не задумываясь, что процессор может. Т.к. исходник скорее всего не на чистом ассемблере, а на каком нибудь Си, то вполне достаточно перекомпилировать с указанием какие инструкции можно использовать при генерации кода. Компилятор сам все оптимизирует в меру своих талантов. Время выполнения уменьшится может и не в разы, но было бы заметно на глаз. Тормоза бы начинались не на 500 пассажирах, а на 700 Но делать это всего ровно никто не будет, так что это все из области "а если бы...".

И раз уж мы все ниже и ниже спускаемся от теории к практике, то тупик неизбежен.
Т.к. мы выяснили, что на конечную производительность влияет множество факторов (квалификация программиста, используемый язык, используемый компилятор, алгоритм, ограничения платформы). И это далеко не полный список. На практике порой получается что программа, которая по идее совершает меньше действий, работает медленнее, чем та что совершает больше действий. Причин миллион. Неэффективный алгоритм, плохое знание языка и его неэффективное использование, тупой компилятор, тупой программист
Иными словами, пытаться определить производительность на глаз основываясь только на описании действий программы невозможно. Можно предположить что 3D игрушка будет грузить процессор сильнее чем текстовый редактор. Но если сравнивать 2 программы аналогичного назначения, то тут поможет либо анализ исходного кода, либо метод научного тыка. В виду отсутствия первого придется использовать второе