Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет nancygold ([info]nancygold)
@ 2024-05-17 02:40:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Настроение: amused
Entry tags:computing

ECS Table Joins
Classic SQL tables are stored using B+ trees, so the data stays sorted by primary key.
That is good for SQL, since majority of the time is spent loading the data into memory.
But using ECS as a replacement for OOP requires our tables to be fast.
So here is an article about efficiently implementing ECS tables and doing the inner joins:
https://www.dataorienteddesign.com/dodbook/node9.html#SECTION00940000000000000000

Inner join is required when some system operates on several components.

Apparently it is possible to cache such join into an internal "super component" table, which gets invalidated on change.



(Добавить комментарий)


(Анонимно)
2024-05-17 03:25 (ссылка)
Слашай клован, какой тебе нахуй data oriented design, кэши, ECS и прочее? Для того, что ты делаешь -- всё это не нужно. На процессоре 7 летней выдержки оно будет летать с любым подходом, хоть даже самым лоботомированным ООП, и будет полностью влезать в память, а все метаданные полностью влезать в L3 современного игрового процессора.

Ты до 50ти будешь свой движок переписывать, или мы таки какой-то observable результат в виде релиза увидим в этом десятилетии?

(Ответить) (Ветвь дискуссии)


[info]aryk38
2024-05-17 04:11 (ссылка)
камон. чел сам учит матерьял второво курса.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2024-05-17 04:48 (ссылка)
нет, это не второй курс, и вообще вне академической программы, потому что чего-то конкретно научного по этому поводу сказать не могут. Это профессиональные геймдевовские заябы, которые, как отмечено выше, Садкова только отвлекают от delivering actual results.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2024-05-17 07:18 (ссылка)
Это ты срешь у веблена

(Ответить) (Уровень выше)


(Анонимно)
2024-05-17 12:10 (ссылка)
нахуй иди

(Ответить) (Уровень выше)


(Анонимно)
2024-05-17 12:11 (ссылка)
правильно.

(Ответить) (Уровень выше)


[info]nancygold
2024-05-17 12:48 (ссылка)
In my case multiple reasons:
0. It is an R&D project, to see if the classic OOP can be completely replaced with ECS for all purposes. After all, I'm working on a next generation language.
1. Entities model even terrain cells. At the same time my language runs on top of a bytecode interpreter, so I need it to be as efficient as possible. I.e. components and systems which auto attach to entities in specific id range.
2. Flexibility is absolutely mandatory for the game. The goal is to provide foundation for something that is very hard to implement in traditional OOP. Basic example: any static terrain tile could be turned into a moving platform, which can as well go into the multiverse directions. Terrain cells and entities could also map into a virtual array of hashes instead of components, but optionally their randomness could be overridden (i.e. to create a probability anomaly where cells can phase into a multiverse). That implies no predefined entity types, just an integer id.
3. A trivial to implement multi-threading, since ECS systems in the same phase can be split across threads.
4. ECS promotes isolation of concerns, and it is easy to reason about it, since systems are mostly purely functional (i.e. Positions.map: XYZ => XYZ+Entity.velocity), the only difference is that ECS maps supply implicity entity's id argument, and pass it to the the output. Compared to OOP, which is a spaghetti mess of convoluted objects modifying state of each other. I.e. like it is easier to reason about keep, map and fold in separation, as of a pipeline, than when they are convoluted into a single operation. So if you find functional programming easier than massive for loops, you will like ECS too.

TLDR: learn some Lisp/Scheme, before doing ECS. Lisp will help you grasping the basic ideas behind ECS.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2024-05-17 13:51 (ссылка)
никто "R&D" не применят для софтин, потому что технически все софтины это "R&D", т.к. производства в софтинах нет. Буквально софтины qualify R&D Tax Credits. It's "Exploratory" at best.

Ну и это без сомнения highly pretentious, утверждать, что ты типа ниибаца "ресерчер", без пяти минут сотрудник Bell Labs, в белом пальто стоишь умный и красивый, когда гранта тебе никто не дал, ты "self-employed", "зарабатываешь" на жизнь торговлей жопой и паразитированием на голландцах.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ololo
2024-05-17 16:16 (ссылка)
Когда-то по запросу "умный, богатый и красивый" видео Садкова было на первом месте в выдаче гугла.

(Ответить) (Уровень выше)


[info]nancygold
2024-05-17 16:43 (ссылка)
>"self-employed", "зарабатываешь" на жизнь торговлей жопой и паразитированием на голландцах.

Is that morally wrong?

(Ответить) (Уровень выше)


[info]borrowedpointer
2024-05-17 11:58 (ссылка)
>Classic SQL tables are stored using B+ trees, so the data stays sorted by primary key.

или нет
в Mysql так, в постгре не так, и это они еще оба btree, а то ведь можно и LSM tree использовать

(Ответить) (Ветвь дискуссии)


[info]nancygold
2024-05-17 12:14 (ссылка)
In any case, SQL standard guarantees sorted retrieval, which severely limits the data structures you can use.

(Ответить) (Уровень выше)