OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 21 Октябрь, 2020 01:46

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 32 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Вторник, 05 Май, 2020 13:26 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 327
Comdiv писал(а):
У меня, кстати, на примере транслятора получилось на 32-битной системе как раз на 42% меньше.

А расскажите подробнее, пож


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Май, 2020 21:11 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 248
Откуда: Austria, Bruck
adimetrius писал(а):
То есть, допустим, есть у нас 64-битный компилятор КП; он генерирует нативные 64-битные инструкции. И есть у него два режима: жадный и скупой: в жадном указатели 64-битные, а в скупом - 32-битные?
И выходит, что можно по желанию одну и ту же программу скомпилировать и жадно, и скупо.

Отлично сформулировано. Но только для Оберон-2(07) сработает.
Для КП\ЧЯ тут проблемы возникают: поскольку параметры компиляции для каждого модуля могут быть различны, то в среде всегда будет часть модулей "скупых" и часть "жадных" что требует: а) согласование вызовов процедур с аргументами-указателями; б) нужно будет два согласованных сборщика мусора.
(Кстати, мне теперь больше понятна реакция Info21 и И.Е. - они смотрят только в ЧЯ)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Май, 2020 21:20 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2846
Моё наивное видение проблемы. Надо сделать какую-то гибридную систему кучи из холма и горы. В холме хранятся только указатели, а данные этих указателей отдельно вне холма в большой горе. По данным в горе сборщик вообще не бегает. А проверяет только холм. И если из холма объект удаляется, то и из горы ему соответствующие данные удаляются.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Май, 2020 22:08 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 327
hothing писал(а):
Отлично сформулировано. Но только для Оберон-2(07) сработает.
Для КП\ЧЯ тут проблемы возникают: поскольку параметры компиляции для каждого модуля могут быть различны, то в среде всегда будет часть модулей "скупых" и часть "жадных" что требует: а) согласование вызовов процедур с аргументами-указателями; б) нужно будет два согласованных сборщика мусора.

Ну, я так далеко не мыслил: вы описываете гибридную систему, в которой одновременно сосуществуют жадные и скупые указатели. А можно ж иметь целиком жадную систему или целиком скупую. Если, скажем, я делаю для заказчика систему с заведомо небольшими требованиями по памяти, то могу собрать для него скупую систему; иначе - жадную.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 01:02 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1103
Откуда: Киев
adimetrius писал(а):
Comdiv писал(а):
У меня, кстати, на примере транслятора получилось на 32-битной системе как раз на 42% меньше.
А расскажите подробнее, пож
Добавил в транслятор вывод кол-ва использованной динамической памяти при использовании с простейшим распределителем памяти без освобождения, и собрал его в 64- и 32-битных режимах. Расходы памяти при трансляции самого себя отличались на 42%. Попробовал, также, собрать в 64-битном режиме с упакованными структурами и без выравнивания выделяемых блоков. Разница с обычным составила 25%.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 18:56 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 327
Очень любопытно!
Comdiv писал(а):
Добавил в транслятор вывод кол-ва использованной динамической памяти при использовании с простейшим распределителем памяти без освобождения, и собрал его в 64- и 32-битных режимах. Расходы памяти при трансляции самого себя отличались на 42%. Попробовал, также, собрать в 64-битном режиме с упакованными структурами и без выравнивания выделяемых блоков. Разница с обычным составила 25%.


Оч интересный результат! Не подберу только название к нему: получается, это не максимальный объем памяти, используемый при компиляции (некоего стандартного теста, коим служит здесь сам компилятор), а как бы объем памяти, который бы понадобился, если бы динамические переменные были неудалимыми. так?
А сборка в 32 и 64 - это Оберон->C->машкод? Т.е. саму сборку посторонние инструменты осуществляют, а не ваш?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 22:10 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1103
Откуда: Киев
adimetrius писал(а):
а как бы объем памяти, который бы понадобился, если бы динамические переменные были неудалимыми. так?
Да. Это, также, приблизительно соответствует использованию сборщика мусора, так как при непродолжительном выполнении он тоже не будет освобождать память.

adimetrius писал(а):
А сборка в 32 и 64 - это Оберон->C->машкод? Т.е. саму сборку посторонние инструменты осуществляют, а не ваш?
Верно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Июль, 2020 16:15 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 191
Откуда: г. Рига, Латвийская ССР
А зачем такая экономия? Может быть, это экономия не в том месте?
Как бывает и оптимизация не в том месте.

Лучше уж целочисленные идентификаторы делать для таких случаев.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Июль, 2020 18:07 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1103
Откуда: Киев
Зачем нужна экономия 40% памяти? Звучит как риторический вопрос.
А к идентификаторам эта экономия вообще никак не привязана.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 25 Июль, 2020 14:29 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 231
Илья Ермаков писал(а):
А внутри контейнера, среди этих микрообъектов такая сложная логика, что нельзя освобождать явно? Нет простой логики владения?

Сборка мусора обязательна в двух ситуациях:
1) В расширяемой системе, где между компонентами гуляют объекты - и явно контролировать владение, его передачу и т.п. очень сложно (что пробует делать Rust, но статически с глобальным анализом, а не для расширяемых систем. (Читаем классические обоснования у Шиперского в EthOS).
2) Всюду :) То есть, решающий свою задачу программист не должен думать об освобождении памяти, иначе будет какой-то процент ошибок, и система будет ненадёжной не на логическом уровне, а на уровне недетерминированного повреждения памяти.

А где можно без сборки мусора:
Когда вы пишите замкнутый компонент, с внутренними объектами, с ограниченной логикой, которую можете спокойно верифицировать. А потом уже 1000 раз безопасно использовать 1 раз написанное.

Если одновременно используется две системы - одна, где требуется сборка муссора, и другая , где требуется несколько или очень много циклов использования замкнутого компонента (контейнера)? У вас было упоминание на дне Оберона о вашей системе в этом аспекте - можно привести пример правильного использования, чтобы не было утечки памяти?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 25 Июль, 2020 22:25 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8381
Откуда: Троицк, Москва
Сборка мусора позволяет разделить (divide et impera) разработку логики и оптимизацию размещения данных в памяти.

Это дико полезно.

Не знаю, было ли это сформулировано в чьей-нибудь диссертации. В моем курсе было.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Июль, 2020 12:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9288
Откуда: Россия, Орёл
arlean1 писал(а):
Если одновременно используется две системы - одна, где требуется сборка муссора, и другая , где требуется несколько или очень много циклов использования замкнутого компонента (контейнера)? У вас было упоминание на дне Оберона о вашей системе в этом аспекте - можно привести пример правильного использования, чтобы не было утечки памяти?


Ну смотрите, у вас 2 пути:
1) Мелкие объекты таки являются управляемыми (создаются через NEW в основной управляемой куче). Тогда просто нужны пулы, в которые вы их возвращаете - и из них же берёте. Тем самым у вас падает количество избыточно созданных и выброшенных (в ожидании сборки мусора) объектов. И можно вообще крайне редко выполнять сборку мусора (или вообще не выполнять, если у вас всё выделение сконцентрировано только в пулах - а ББ неграфический, без чужих компонентов, т.е. вы понимаете, где и что выделяется).
Минус - если сборка всё же выполняется, то при большом количестве мелких объектов пробег по ним сборщика занимает время.

2) Если объекты инкапсулированы в реализации и недоступны внешнему модулю, то можно сделать их через POINTER TO RECORD [untagged] и выделять и освобождать через malloc или WinApi.Heap... Разумеется, нужно строго выверить корректность выделения/освобождения внутри реализации вашего контейнера.
Если логика сложная, я бы без необходимости оптимизации не рисковал этим вообще, пусть гарантирует сборщик (по крайней мере, при выделении/освобождении в пул вы получите логическую ошибку одновременного использования объекта - и это можно подиагностировать, а при неверной работе с неуправляемой памяти у вас всё неуправляемо и сдохнет :) ).
Если логика простая (моменты выделения/освобождения ну прямо очевидны) - то игра стоит свеч, т.к. если мелких объектов внутри очень много, то и задержки они дают на сборку очень существенные.

Ещё есть такая штука, как POINTER [untagged] TO RECORD - такой указатель не трассируется сборщиком, но является теговым, т.е. можно иметь методы, полиморфизм, WITH и проч. Только за размещение тега в выделенном блоке отвечаете сами. Надо положить сначала тег типа, а потом взять за указатель +SIZE(POINTER) (чтобы тег остался по -4). Ну и освобождать с соответствующей логикой.
Это может быть важно, если внутри реализации вашей структуры вы таки используете ООП (подвиды листов дерева там, ну и т.п.)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 32 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


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

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB