Свободное общение

[darwin128K]

Опять вы стрелки переводите.


Я бы ответил куда вам всем "несогласным" идти, но формат этого ресурса не позволяет.

На пальцах вам разъясняю:

ReHLDS - это прогрессивное, технологичное и современно решение (с переработанной архитектурой), поддерживаемое сообществом. Сообщество это группа профессиональных разработчиков, возможно, тоже фриков-энтузиастов, но числом более 1 чел.

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

Загибайте пальчики преимуществ ReHLDS: безопасность, производительность и стабильность, расширенные лимиты, поддержка современных клиентов, RE-инфраструктура (ReAPI + ReGame + ReHLTV) + нативная интеграция с AMXX и тысячами плагинов.

А вы попробуйте придумать легенду преимуществ для своей песочницы, начать нужно с преимущества в +50% накладных расходов и подмены понятий Sanbox-изоляции и "обертки" на "обертке".

Вы сами это проверяли или откуда вы такие выводы сделали?

Сообщение автоматически объединено: Пятница в 20:17

@Refresh я думаю стоит сказать вам спасибо, тема никому не нужная была, благодаря вам 350 просмотров, каждый выберет то, что считает и то чему доверяет сам, даже если выбор будет не подкреплен ничем. Не занимайтесь попечительством, есть разные работы - разный спектр задач, в том, что вы так не разобрались а я как разработчик попытался все же показать вам, что вы неправы в своих выводах это тоже мой выбор. Считаю, что на этом тема лично с вами закрыта. Вы не показали ничего кроме глупости и какими то суждениями по поводу проекта не установив и не попробовав написать плагин. То что вам потребуется установить CMake и GNU CC не говорит о муторности - уже давно существуют такие утилиты как scoop которые поставят все за вас. Мне честно очень жаль вас. Но хочу отдать должное есть мысль как все таки сделать улучшить проект... В проекте есть болванки - примеры, и документация, представляете, интересно как вы написали плагин за 15 минут не зная API? Это может быть вывести что либо в чат, пожалуйста есть hello проект который вам в этом поможет.

Сообщение автоматически объединено: Пятница в 20:20

Опять вы стрелки переводите.


Я бы ответил куда вам всем "несогласным" идти, но формат этого ресурса не позволяет.

На пальцах вам разъясняю:

ReHLDS - это прогрессивное, технологичное и современно решение (с переработанной архитектурой), поддерживаемое сообществом. Сообщество это группа профессиональных разработчиков, возможно, тоже фриков-энтузиастов, но числом более 1 чел.

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

Загибайте пальчики преимуществ ReHLDS: безопасность, производительность и стабильность, расширенные лимиты, поддержка современных клиентов, RE-инфраструктура (ReAPI + ReGame + ReHLTV) + нативная интеграция с AMXX и тысячами плагинов.

А вы попробуйте придумать легенду преимуществ для своей песочницы, начать нужно с преимущества в +50% накладных расходов и подмены понятий Sanbox-изоляции и "обертки" на "обертке".

На Sven Co-op есть ReHLDS?

 

[Refresh]

Вы сами это проверяли или откуда вы такие выводы сделали?

Вы 3 страницы сначала процитируйте, а потом задавайте конкретный вопрос - можно просто: "ЧО?".

 

[darwin128K]

Вы 3 страницы сначала процитируйте, а потом задавайте конкретный вопрос - можно просто: "ЧО?".

Вы пришли на authum чтобы что? Выразить свое недовольство, что вы устроили тут?
Вы как то причастны к разработке ReHLDS?

 

[Refresh]

если вы даже не знаете что такое кадр (в данном случае это вы)

Все в этой жизни относительно, это с какой стороны посмотреть

Вы пришли на authum чтобы что?

Как и в предыдущем случае, возможно, authum пришел сюда? Чтобы что? Рассказать, как людям, умеющим писать на C, нужна ваша "обертка", "песочница" и архитектурные-матрешки?

Выразить свое недовольство, что вы устроили тут?

Выразил свое критическое мнение, относительно, постулатов, заявленных в шапке-описания ресурса, а также ущербности примененных вами архитектурных решений.

Вы как то причастны к разработке ReHLDS

У меня не достаточно квалификации, к моему сожалению. Но я пользуюсь результатами их интеллектуального труда более 4 лет, за что им искренне благодарен.

 

[Refresh]

На Sven Co-op есть ReHLDS?

Хаха... https://github.com/autisoid/ReHLDS_Sven

 

[Refresh]

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

А я сделал, пока тянул "лямку" установленных модератором ограничений...
(с) "Провокация пользователей" ? Да Но все остальное мимо кассы - максимально конструктивно и аргументированно.

Объект и методика:

• lh 0.3.0 (HEAD 63f1887e)
• 7 размеров × 3 варианта × 3 фазы
• 2 000 000 итераций на точку
• 5 повторов отдельными процессами
• warm-up 10 000
• clock_gettime(CLOCK_MONOTONIC)
• taskset -c 4

Две сборки: с обнулением блоков и без. Время, нс на операцию — alloc+free в одном проходе.

Сборка без обнуления (INIT_ALLOCATED=OFF, ближе к чистому malloc):

| байт | malloc | lh    | sandbox | lh/malloc | tree/malloc |
| ---- | ------ | ----- | ------- | --------- | ----------- |
| 32   | 24.6   | 29.6  | 88.1    | 1.20×     | 3.58×       |
| 64   | 24.8   | 29.3  | 87.9    | 1.18×     | 3.54×       |
| 128  | 24.4   | 29.1  | 89.9    | 1.19×     | 3.69×       |
| 256  | 23.4   | 28.2  | 87.1    | 1.21×     | 3.72×       |
| 512  | 25.0   | 28.0  | 88.7    | 1.12×     | 3.55×       |
| 1024 | 24.8   | 30.1  | 204.4   | 1.21×     | 8.24×       |
| 2048 | 103.6  | 119.1 | 207.2   | 1.15×     | 2.00×       |

Накладные расходы — ровно 80 байт на блок:
sized-заголовок 16 Б + заголовок дерева 64 Б = 80.

| байт | накладные     | % сверх запрошенного |
| ---- | ------------- | -------------------- |
| 32   | 80 (+8 glibc) | 250 %                |
| 64   | 80            | 125 %                |
| 128  | 80            | 62.5 %               |
| 256  | 80            | 31.2 %               |
| 512  | 80            | 15.6 %               |
| 1024 | 80            | 7.8 %                |
| 2048 | 80            | 3.9 %                |

Два независимых источника совпали:
API (lh_memory_tree_get_block_size − size = 64) и замер RSS — 80.0 Б/блок во всех семи размерах.

Состав заголовка дерева:
allocator 8 + parent 8 + sibling 16 + children 16 + destructor 8 = 56 → округление до 16 =64.

Сборка с обнулением (INIT_ALLOCATED=ON, заводская настройка):

| байт | malloc | lh    | sandbox | lh/malloc | tree/malloc |
| ---- | ------ | ----- | ------- | --------- | ----------- |
| 32   | 24.2   | 43.6  | 104.3   | 1.80×     | 4.32×       |
| 64   | 24.8   | 41.7  | 104.0   | 1.68×     | 4.19×       |
| 128  | 25.3   | 49.2  | 100.5   | 1.94×     | 3.97×       |
| 256  | 25.6   | 49.9  | 108.8   | 1.95×     | 4.25×       |
| 512  | 26.2   | 58.1  | 122.5   | 2.22×     | 4.67×       |
| 1024 | 27.7   | 82.7  | 249.7   | 2.98×     | 9.01×       |
| 2048 | 119.4  | 225.6 | 293.1   | 1.89×     | 2.45×       |

Накладные расходы — те же 80 байт на блок
Флаг INIT_ALLOCATED влияет на скорость, не на размер:
sized-заголовок 16 Б + заголовок дерева 64 Б = 80, независимо от обнуления.

| байт | накладные     | % сверх запрошенного |
| ---- | ------------- | -------------------- |
| 32   | 80 (+8 glibc) | 250 %                |
| 64   | 80            | 125 %                |
| 128  | 80            | 62.5 %               |
| 256  | 80            | 31.2 %               |
| 512  | 80            | 15.6 %               |
| 1024 | 80            | 7.8 %                |
| 2048 | 80            | 3.9 %                |

Два независимых источника совпали:
API (lh_memory_tree_get_block_size − size = 64) и замер RSS — дельта tree − malloc = 80.00 Б/блок во всех семи размерах.

Состав заголовка дерева:
allocator 8 + parent 8 + sibling 16 + children 16 + destructor 8 = 56 → округление до 16 = 64.

Вы пока посмотрите цифры, особенно строку:

| 1024 | 27.7   | 82.7  | 249.7   | 2.98×     | 9.01×       |

Я проверил ее дважды и нашел причину... Мне нужно доехать до своего рабочего места, через пару часов продолжим галлюционировать и разбирать ваше архитектурное решения: ошибки, уязвимости, глюки, отсутствие потокобезопасности и т.д. Особенно меня порадовала ваша "шина" данных с cmp()

Я ведь когда писал, что AMXX не могут допилить за 20 лет, как бы намекал, что у средней руки энтузиаста уйдет не меньше времени, на оттачивание аналогичного набора

 

[the_hunter]

1.

Но все остальное мимо кассы - максимально конструктивно и аргументированно.

не смотрел реализацию, но готов оспорить утверждение о ее супер-надежности

То есть, не смотрел, но осуждаю. Ага, очень аргументированно, не поспоришь.
Если есть что конкретное сказать/предложить - говори. Иначе не стоит.

2. В ваших замерах и выводах выше есть фундаментальные ошибки (хотя бы то, что у вас сборка x64) - они не верны. И синтетика оторвана от работы игрового сервера.

3. Прекращайте этот спор не о чём. Кому нужен этот проект (даже если только одному автору) - тому он нужен. Кому нет - проходите мимо. Он вам никак жить не помешает.
Кого что-то не устраивает - делайте своё или ищите другое.

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

 

[Refresh]

То есть, не смотрел, но осуждаю. Ага, очень аргументированно, не поспоришь.
Если есть что конкретное сказать/предложить - говори. Иначе не стоит.

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

Предлагаю допилить AMXX, чтобы можно было делать многопоточные amxx-форварды.

2. Есть погрешность, но нет ошибок, тем более фундаментальных. Ставятся gcc-multilib 4:13.2.0, libc6-dev-i386 2.39, минут 10 - проверим.

3. Пошел-пошел.

а не для того чтобы оскорбить автора и рассказать что это никому не нужно

Я никого не оскорблял. Просто мне было нечего делать и я решил подискутировать.

Сообщение автоматически объединено: Вчера в 22:13

(хотя бы то, что у вас сборка x64) - они не верны

Да ничего не поменялось, фундаментально. На х32 ожидаемое линейное снижение производительности в 1,6-2,2 раза, и размер x32 = 48 Б, не 80. Вот и все. Лаг на 1024 есть в обоих вариантах (размер области превышает tcache_max), с отключенным tcache - пропадает, но скорость выделения мелких чанков значительно падает. Если уж писать свой менеджер памяти, то тогда уже и брать подходящий под задачу аллокатор, а не тянуть его из glibc.

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

 

[the_hunter]

@Refresh,
1. Разница в 1.6-2x на синтетике - это штатный оверхед любого пулового/древовидного аллокатора с метаданными (привет, talloc из Samba). Это очень далеко от ваших изначальных "х9 катастрофических замедлений" на x64. На реальном сервере HLDS эти наносекунды растворяются в 10-миллисекундном тике кадра.

2. Authum спроектирован с чистым C ABI. Никакого C++ в интерфейсе модулей нет и быть не должно, чтобы не ломать бинарную совместимость между разными компиляторами и версиями libstdc++.
Кроме того, unique_ptr не защищает хост от модулей с забытыми malloc: задача песочницы - гарантировать, что хост при выгрузке модуля сносит всё дерево его аллокаций сам, независимо от качества кода модуля.

3. Если есть конкретные баги с воспроизведением (issue, тест или valgrind/ASan лог) - оформляйте issues в репозитории проекта, автор скажет спасибо.

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

 

[Refresh]

Кроме того, unique_ptr не защищает хост от модулей с забытыми malloc

Примеры - класс!

А песочница узнает о забытом malloc, да? Как связан шатный оверхед "где-то там" с ошибкой в реализации конкретной архитектуры? Вы посчитайте "синтетические" расходы, допустим 50 модулей (по 20 вызовов), на кадр - просто на выделение памяти этой чудо песочницы. Автор же замену AMXX-делает. Для 100FPS, пара миллисекунд - это, наверно, приемлемо... Для кого-то...

Это очень далеко от ваших изначальных "х9 катастрофических замедлений"

Так на границе >1024, в конкретной архитектуре с использованием библиотеки lh - он будет всегда Автор просто выделяет всю память при старте и рапортует - накладные расходы на кадр 0.

Но спорить с вами нет смысла.

Да, обертки, песочницы и чистый C лучше STL и всяких там прогрессивных технологий. Ведь положить в корень libstdc++ это сложно, нужно придумать обязательно какой-нибудь костыль.

Сообщение автоматически объединено: Вчера в 23:26

Я вот лезу в "модули" только от безысходности.. Когда реализация в regame+rehlds ну просто кровь из глаз - цикл на цикле по циклу.. И все мои доработки всегда увеличивают производительность минимум в х100-200 раз, парсинг userinfo на UTF - в х4000, относительно штатного функционала. А когда я вижу, что без того убитую и отбитую технологию пытаются еще разок изнасиловать и добить через всякого рода "обертки" - у меня глаз начинает дергаться. Это не про оскорбить, и не про технологИИ.

 

[the_hunter]

@Refresh Вот я про это и говорю... Спорить с вами нет смысла, потому что вы явно не разбираетесь в теме. Однако, очень уверенно и с "доказательствами" несете полную ахинею. Со стороны может даже кому-то показаться, что вы понимаете, о чем говорите.
Вот просто ради примера:

допустим 50 модулей (по 20 вызовов), на кадр

Даже по вашим замерам 100 нс на операцию:
1000 х 100 нс = 100000 нс = 0.1 миллисекунды, а не "пара миллисекунд". Ошибка в расчетах на ровном месте в 20 раз. Но главное - ни один нормальный модуль не дергает кучу по 20 раз за кадр (постоянные структуры хранят в статической памяти).

А песочница узнает о забытом malloc, да?

Модули вызывают authum_sandbox_alloc(), а не malloc(). Аллокации привязываются к корню песочницы модуля. При stop хост сносит всё дерево. Утечь физически ничего не может.

Ну, это так, просто для примера. Про доработки, которые "всегда увеличивают производительность минимум в х100-200 раз" я вообще промолчу...

В общем, удачи вам с вашими доработками! Дерзайте!

 

[Refresh]

Даже по вашим замерам 100 нс на операцию:
1000 х 100 нс = 100000 нс = 0.1 миллисекунды, а не "пара миллисекунд".

Браво.. Только не 100нс (у нас же х32), а средняя будет 600нс. Мой расчет в тесте показал ~0,7мс, а синтетический тест крайнюю точку - 1,4мс. Ни один нормальный модуль не будет использовать эту песочницу

Модули вызывают authum_sandbox_alloc(), а не malloc(). Аллокации привязываются к корню песочницы модуля. При stop хост сносит всё дерево. Утечь физически ничего не может.

Круто, значит в вашем варианте модуль точно использует authum_sandbox_alloc() (это же как-то проверяется, да? или реализовано в виде ограничения), а в моем случае при использовании uniqueprt - обязательно будет дегенерат, который выполнит malloc(), не в обертке. Мне нравятся ваши аргументы, в крайнем случае можно списать на то, что я или кто-то не понимает сути.

Про доработки, которые "всегда увеличивают производительность минимум в х100-200 раз"

Поиск оружия на карте, например Хотите сравним код, там тоже красно-черные деревья, менеджер туда-сюда...