распределение массива

[Shad0wF1rst]

Сообщение от Артэс

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

На самом деле, интересует вопрос процессорного времени, то, как компьютеру будет проще. Я смотрю предложили вариант "иерархической базы", интересно, первый раз такое вижу. Т.е. предлагается вместо обращения к структурам массива в цикле, по очереди (1 2 3 4 5), будет браться прямой адрес следующей структуры, из текущей? Это интересно, ибо обращение к элементам массива будет проводиться в цикле десятки раз в секунду (проверка объектов, их координат, столкновений, проверка флагов, эвентов и т.п.).

Таким образом, если думать о таком варианте, здесь логичнее цельный массив (1000), с указателями.

Целесообразно ли использовать иерархическую структуру? Намного ли разница в производительности? Если десятки раз в секунду, в цикле, будут прокручиваться 500-1000 элементов?

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

(предметы, персонажи, и т.п.)

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

[Артэс]

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

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

А так, у всех объектов, что на карте, есть общее свойство - они на карте, и их надо проверять. Если использовать общую структуру, будут такие приколы, как "хп у предмета".. или если что-то добавить персонажу, то такое же свойство автоматически становится доступно и предмету на карте. Такой же метод я нашел в исходниках Quake 3 Arena, когда мод писал там общая база для всех "сущностей" на карте, и не важно, персонаж это, предмет, или летящая ракета. Видимо в таком методе есть что-то полезное.

[Shad0wF1rst]

Сообщение от Артэс

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

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

А так, у всех объектов, что на карте, есть общее свойство - они на карте, и их надо проверять. Если использовать общую структуру, будут такие приколы, как "хп у предмета".. или если что-то добавить персонажу, то такое же свойство автоматически становится доступно и предмету на карте. Такой же метод я нашел в исходниках Quake 3 Arena, когда мод писал там общая база для всех "сущностей" на карте, и не важно, персонаж это, предмет, или летящая ракета. Видимо в таком методе есть что-то полезное.

А то что они все на карте это не помешает им находится в разных массивах. И поверьте на производительности это никак не скажется. База может быть и общая, но я подозреваю что хранятся они в разных таблицах это базы.

[Артэс]

Но ведь обратиться по адресу быстрее, чем через индекс массива, причем еще если этих массивов несколько. Разве нет?

[still_alive]

Артэс, по-моему ты фигней маешься) Я думаю так, потому что:
1) ты не планируешь ничего распараллеливать, поэтому тебе не нужно заботиться о "ложном разделении", перебрасывании кэша и прочих артефактах
2) тебе не нужно, чтобы объекты разных типов попадали в одну кэш-линию
3) особенность реализации должна быть сокрыта от пользователя, а значит поменять ее в случае чего не составит проблем
4) ты не уверен, что именно это будет узким местом в твоем коде.

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

Но ведь обратиться по адресу быстрее, чем через индекс массива, причем еще если этих массивов несколько. Разве нет?

По сути один хрен.

[Кащей]

Сообщение от Артэс

Но ведь обратиться по адресу быстрее, чем через индекс массива, причем еще если этих массивов несколько. Разве нет?

Указатели скорее для большого количества данных большого объёма, которые надо както связать, тогда выгода будет тем ощутимее, чем больше количество данных и их объём.

[_Bers]

Кащей,рекомендую вам почитать что нибудь из цикла "дата ориентированное программирование".

[_Bers]

Сообщение от Артэс

Но ведь обратиться по адресу быстрее, чем через индекс массива, причем еще если этих массивов несколько. Разве нет?

У вас есть указатель на начало группы.

Как вы получите адрес конкретного элемента группы?

Внезапно, вы используете указатель + смещение. Чем и является индекс.

Поэтому, забейте и не парьтесь. Оптимизиции такого уровня - это задача для компилятора, а не для программиста.

[Кащей]

Сообщение от _Bers

Кащей,рекомендую вам почитать что нибудь из цикла "дата ориентированное программирование".

Я ничего такого не нашол.

[_Bers]

Сообщение от Кащей

Я ничего такого не нашол.

http://cheremin.blogspot.ru/2010/02/...ogramming.html
http://gamesfromwithin.com/managing-data-relationships