OberonCore https://forum.oberoncore.ru/ |
|
Modula-2+ https://forum.oberoncore.ru/viewtopic.php?f=120&t=6022 |
Страница 1 из 3 |
Автор: | Иван Левашев [ Суббота, 04 Март, 2017 12:25 ] |
Заголовок сообщения: | Modula-2+ |
Был ещё и такой диалект: https://en.wikipedia.org/wiki/Modula-2%2B Чтобы понять, чем он примечателен, давайте посмотрим, как обстоят дела с ARC в ветках Паскаля:
Куда ни кинь, всюду клин. И тут оказывается, что был язык, в котором сделано хоть как-то близко к нормальному. Этим и примечателен. |
Автор: | Илья Ермаков [ Суббота, 04 Март, 2017 15:21 ] |
Заголовок сообщения: | Re: Modula-2+ |
Простите, что-то не считал мысль: обстоят дела с чем? С ARC? А что это? |
Автор: | Дмитрий Дагаев [ Суббота, 04 Март, 2017 15:34 ] |
Заголовок сообщения: | Re: Modula-2+ |
Automatic Reference Counting https://habrahabr.ru/post/209288/ OCTAGRAM писал(а): [*]Oberon-2: безнадёжно сломан трассирующим сборщиком мусора Хотелось бы прояснить |
Автор: | Comdiv [ Суббота, 04 Март, 2017 16:20 ] |
Заголовок сообщения: | Re: Modula-2+ |
Илья Ермаков писал(а): Простите, что-то не считал мысль: обстоят дела с чем? С ARC? А что это? Automatic reference counting, вестимо. Правда, непонятно, почему такая возможность сломана в Обероне-2. В этом плане Оберон-2 не отличается от простого Оберона( или нет?), а я проводил эксперимент в простом Обероне - на нём вполне можно программировать с ARC без внесений изменений в язык с той разницей, что циклические связи нужно разрывать самостоятельно. |
Автор: | Иван Левашев [ Суббота, 04 Март, 2017 19:16 ] |
Заголовок сообщения: | Re: Modula-2+ |
Comdiv, да, по-хорошему должны быть слабые ссылки, чтобы их вручную не разрывать. Смотрел Javolution, там, как выясняется, даже сборщика циклов нет, и ничего, джависты пишут. Просто им в других обстоятельствах не давали нормально писать, а тут, когда дали, выясняется, что могут. Но если много чужого кода, то начинаются проблемы. Дмитрий Дагаев писал(а): Automatic Reference Counting https://habrahabr.ru/post/209288/ OCTAGRAM писал(а): [*]Oberon-2: безнадёжно сломан трассирующим сборщиком мусора Хотелось бы прояснить Про попытки починить язык после того, как болезнь капитально запущена: http://sealedabstract.com/rants/why-mob ... -are-slow/ Цитата: There is another group that has tried to fork a dynamic language to meet the needs of mobile developers–and it’s called RubyMotion. So these are smart people, who know a lot about Ruby. And these Ruby people decided that garbage collection for their fork was A Bad Idea. (Hello GC advocates? Can you hear me?). So they have a thing that is a lot like ARC that they use instead, that they have sort of grafted on to the language. Turns out it doesn’t work: Objective-C повезло гораздо больше. Там вовремя объявили TGC устаревшим и не влипли в серьёзные проблемы. Статья вроде как про мобильные приложения, но я и на других платформах страдаю. Как ни глянешь в Диспетчер задач, так сразу понятно, кто у нас тут трассирующую сборку мусора применяет, перетягивая своп туда-сюда: Вложение:
Комментарий к файлу: Кто у нас тут трассирующую сборку мусора применяет? Swap.png [ 8.8 КБ | Просмотров: 19852 ] За свои программы по возможности краснеть не хочется. Зная о том, как потом на больших масштабах кода и данных будет болезненно лечиться от TGC, разумно просто не начинать. Всё, что с неизвлекаемой или сильно въевшейся трассирующей сборкой мусора, отбрасывать без сожалений. И получается, что из веток C есть Objective-C 2.0 и C++/CX, а в ветках Паскаля — негусто. |
Автор: | Илья Ермаков [ Суббота, 04 Март, 2017 21:30 ] |
Заголовок сообщения: | Re: Modula-2+ |
Первый раз вижу такую аббревиатуру, обычно просто reference counting. Это либо с ObjC повелось? Там ещё у Compaq-DEC (Вы же на их Модулу 2+ ссылку давали) и свой смысл был ARC, имя собственное ) Про трассирующий GC согласен. И про то, что способ управления памятью пронизывает всё - и потом фиг поменяешь, тоже очень важно понимать. У меня для КП есть решение. Не "всепогодное", но для систем с детерминированной нагрузкой (массовое обслуживание запросов со статистическим распределением, так сказать; ну а для большинства систем управления и встроенки вообще детерминированное количество объектов циркулирует, ещё проще жить). Дмитрий Дагаев на Оберон-дне 2015 рассказывал про их решение для Active Oberon с выделением на старте и потом выключением. |
Автор: | Илья Ермаков [ Суббота, 04 Март, 2017 21:47 ] |
Заголовок сообщения: | Re: Modula-2+ |
P.S. Присмотрелся к ARC внимательнее. Да, это не просто reference counting. А расширенная поддержка компилятором, статический анализ. С одной стороны, хорошо, когда что-то уходит на компилятор. С другой стороны, иногда тонкости скрытого поведения ещё сложнее держать в голове, чем что-то делать явно. Мне механизм показался сложным для безошибочного использования средним разработчиком. Лучше любой вариант явного освобождения с гарантией не-разрушения памяти (в машинах с широкой адресацией типа Эльбруса - однократное использование виртуального адреса; на обычной архитектуре - хранение доп. метки UID адресуемого объекта вместе с указателем и сверка при обращении; либо рециркуляция объектов по типам). А любой умный механизм освобождения уже над этим безопасным ручным управлением делать библиотечно специально под задачу. Допустим, граф объектов привязан к своему домену, он отвечает за освобождение. Или спец. подсчёт ссылок уже в базовом типе для какой-то разновидности объектов. |
Автор: | Дмитрий Дагаев [ Суббота, 04 Март, 2017 21:57 ] |
Заголовок сообщения: | Re: Modula-2+ |
Но вопрос поднят правильно, спасибо, проблема существует. Для каждой новой задачи приходилось искать приемлемое решение, для мягкого RealTime (SCADA), вызываю GC в 10 сек цикле. Для жесткого - да, запрещал. Что хорошо, можно подкрутить под задачу рантайм в Blackbox, A2, Ofront. Рано или поздно, кто-то под llvm серьезно перейдет, и новый механизм там и окажется. Кто знает, кто знает, есть над чем подумать... |
Автор: | Comdiv [ Воскресенье, 05 Март, 2017 00:30 ] |
Заголовок сообщения: | Re: Modula-2+ |
OCTAGRAM писал(а): Как ни глянешь в Диспетчер задач, так сразу понятно, кто у нас тут трассирующую сборку мусора применяет, перетягивая своп туда-сюда: Вложение: Swap.png Неужели Thunderbird, написанный на С++? Вообще, подсчёт ссылок даёт больше накладных расходов, чем сборщик мусора и паузы может давать сопоставимые за счёт длинных цепочек освобождения. В Java главная проблема - это злоупотребление динамической памятью, а не само наличие сборщика мусора. |
Автор: | Дмитрий Дагаев [ Воскресенье, 05 Март, 2017 10:16 ] |
Заголовок сообщения: | Re: Modula-2+ |
Comdiv писал(а): я проводил эксперимент в простом Обероне - на нём вполне можно программировать с ARC без внесений изменений в язык с той разницей, что циклические связи нужно разрывать самостоятельно. А поподробнее можете рассказать? |
Автор: | Иван Левашев [ Воскресенье, 05 Март, 2017 10:38 ] |
Заголовок сообщения: | Re: Modula-2+ |
Comdiv писал(а): Неужели Thunderbird, написанный на С++? В XUL без JavaScript ничего не обходится. Он постоянно в фоне что-то делает, начинает сборку мусора, потом сообщение вылезает, что скрипт долго не отвечает, и там какой-нибудь JavaScript указан. Comdiv писал(а): Вообще, подсчёт ссылок даёт больше накладных расходов, чем сборщик мусора и паузы может давать сопоставимые за счёт длинных цепочек освобождения. Я слышал это много раз, но никогда не видел. Зато я видел, как работал Хакинтош 10.4.10 (когда TGC ещё не поддерживался в движке Objective-C) на 512Mb RAM. И я вижу, как загоняет в ноль современное железо Windows 10 на 4Гб RAM, где помешательство на .NET на своём пике. Я вижу, как жрут батарею Андроиды и как — BlackBerry и iOS. Я вижу, как работает J2EE сервер и как работает AWS. Мне понятно, как получаются дикие фризы, когда программы по очереди ходят собирать мусор и вязнут в соревновании за страницы памяти. Они делают это снова и снова. Это же как вечный двигатель наоборот! Я сыт по горло этими постоянными играми «вот там трассирующий сборщик мусора плохой, но здесь-то точно хороший». Может быть, совпадение, но мне почему-то постоянно не везёт, всё сплошь плохие попадаются, и мне это надоело. Надоело держать в уме, сколько на компьютере сейчас запущено программ со сборкой мусора и хватит ли ресурсов для ещё одной. И не хочу, чтобы в эти игры играли пользователи моих программ. Хочу делать программы, которые работают и не парят мозг своим вечным двигателем наоборот. Пусть там каждая пауза будет по делу, а не чтобы втихушку сгладить програмные ошибки взаимного владения. |
Автор: | Info21 [ Воскресенье, 05 Март, 2017 11:37 ] |
Заголовок сообщения: | Re: Modula-2+ |
Comdiv писал(а): В Java главная проблема - это злоупотребление динамической памятью Поясните, пожалуйста.
|
Автор: | Comdiv [ Воскресенье, 05 Март, 2017 14:22 ] |
Заголовок сообщения: | Re: Modula-2+ |
Дмитрий Дагаев писал(а): Comdiv писал(а): я проводил эксперимент в простом Обероне - на нём вполне можно программировать с ARC без внесений изменений в язык с той разницей, что циклические связи нужно разрывать самостоятельно. А поподробнее можете рассказать? В своём недоделанном трансляторе с Оберона на Си https://github.com/ComdivByZero/vostok я сделал три возможности работы с памятью - без освобождения, с подсчётом ссылок и со сборщиком мусора. Подсчёт ссылок был сделан на уровне доказательства концепции, без автоматической цепочки освобождений, но вполне работоспособным на простых примерах. |
Автор: | Дмитрий Дагаев [ Воскресенье, 05 Март, 2017 15:12 ] |
Заголовок сообщения: | Re: Modula-2+ |
Раз концепция доказала, значит в Вашем трансляторе можно будет указать (например, как я бы видел): Код: PtrNoFree = POINTER TO RECORD [untagged] next: PtrNoFree END; PtrRefCount = POINTER TO RECORD [strong] next: PtrRefCount END; PtrGC = POINTER TO RECORD next: PtrGC END; ... NEW(p); p.next := p; ... (* p.next := NIL *) p := NIL; И сгенерить код, в котором, при отсутствии внешних ссылок: - В первом случае PtrNoFree память не освобождается; - Во втором случае PtrRefCount освобождение не произойдет, потому, что есть ссылка сама на себя. Но, если раскомментировать и разорвать ссылку, то освобождение произойдет немедленно при p := NIL; - В третьем случае PtrGC сборщик мусора позже в idle-цикле освободит память. |
Автор: | Comdiv [ Воскресенье, 05 Март, 2017 15:36 ] |
Заголовок сообщения: | Re: Modula-2+ |
Info21 писал(а): Comdiv писал(а): В Java главная проблема - это злоупотребление динамической памятью Поясните, пожалуйста.И сам язык располагает и программисты на нём привыкли сорить памятью. Язык не позволяет использовать локальные объекты и массивы, которые можно выделять на стеке, оставляя эту оптимизацию на сложный транслятор. Но поскольку программист не осознаёт в явном виде разницу, то он легко блокирует возможность использования объектов на стеке даже для сложного транслятора. Наглядный пример из языка: Код: Point [128][128] points; Это двумерный массив точек. При необходимости, в нормальных языках его можно представить как один объект, который даже может быть выделен статически. В Java - это (1 + 128 + 128 * 128) динамически выделенных объектов. Тут не только проигрыш в сборке освобождённой памяти, но и на выделение тратится куда больше времени. Про программистов - это отдельная песня. Недавно говорил с коллегой, для которого основная специализация - это Verilog, но также у него есть хобби-проект для Android. Он искал хорошее решение для создания неизменяемых объектов с большим количеством параметров, что при решении в лоб приводит к длинному списку аргументов у конструктора. На просторах интернета он нашёл решение - для создания неизменяемого объекта создаётся один изменяемый, после установки полей которого, вызывается метод создания искомого. Типичное производство мусора в Java. |
Автор: | Info21 [ Воскресенье, 05 Март, 2017 16:10 ] |
Заголовок сообщения: | Re: Modula-2+ |
Большое спасибо, понятно. Основная причина была известна, но масштаб последствий -- неожиданный. Пузырь избыточной сложности в сфере IT становится каким-то совсем оголтелым. Интересно, куда кривая привезёт. |
Автор: | Дмитрий Дагаев [ Воскресенье, 05 Март, 2017 16:39 ] |
Заголовок сообщения: | Re: Modula-2+ |
Кстати, реализация POINTER TO RECORD [strong] приведёт ещё и к решению проблемы многопоточности и проблемы контроля за стеками при кооперативной многозадачности |
Автор: | Comdiv [ Воскресенье, 05 Март, 2017 18:20 ] |
Заголовок сообщения: | Re: Modula-2+ |
Дмитрий Дагаев писал(а): Раз концепция доказала, значит в Вашем трансляторе можно будет указать (например, как я бы видел): ... Код: PtrRefCount = POINTER TO RECORD [strong] next: PtrRefCount END; ... NEW(p); p.next := p; ... (* p.next := NIL *) p := NIL; - Во втором случае PtrRefCount освобождение не произойдет, потому, что есть ссылка сама на себя. Но, если раскомментировать и разорвать ссылку, то освобождение произойдет немедленно при p := NIL; Верно, но с той разницей, что у меня 3-и возможности работы с памятью существуют не одновременно, а нужный режим выбирается во время трансляции. Это позволяет оставить язык неизменным, собственно, этого я и добивался. Поэтому мне непонятны необдуманные утверждения про "безнадёжно испорченный". Ваш пример я добавил в тесты. |
Автор: | Comdiv [ Воскресенье, 05 Март, 2017 18:51 ] |
Заголовок сообщения: | Re: Modula-2+ |
OCTAGRAM писал(а): В XUL без JavaScript ничего не обходится. Он постоянно в фоне что-то делает, начинает сборку мусора, потом сообщение вылезает, что скрипт долго не отвечает, и там какой-нибудь JavaScript указан. И какую долю занимает XUL - 90 % или всё-таки меньше 10%? Цитата: Я слышал это много раз, но никогда не видел. Зато я видел, как работал Хакинтош 10.4.10 (когда TGC ещё не поддерживался в движке Objective-C) на 512Mb RAM Он и в современных версиях не используется, попробуйте использовать их на 512 мб. Когда-то давно я использовал Eclipse на компьютере с 256мб - вполне рабочий вариант, но с новыми версиями Eclipse такая штука бы не прокатила. А ведь и там и там используется GC. Просто дело совсем не в GC. А ещё, раз уж вспоминаю прошлое, страшно сказать, но для мобильных телефонов с 64 кб оперативной памяти я писал приложения тоже на Java с этим ужасным GC, и это работало. Цитата: Я вижу, как жрут батарею Андроиды и как — BlackBerry и iOS. Вот у меня YotaPhone 2 на Android 5. Использую преимущественно экран на электронной бумаге. Батарея живёт 5 дней. Повторюсь, дело совсем не в GC.Цитата: Я сыт по горло этими постоянными играми «вот там трассирующий сборщик мусора плохой, но здесь-то точно хороший». А кто Вам это говорит? Я сказал следующее - проблема не в наличии сборщика мусора, а в злоупотреблении динамической памятью.Цитата: Может быть, совпадение, но мне почему-то постоянно не везёт, всё сплошь плохие попадаются, и мне это надоело Может, Вы просто сознательно игнорируете всё остальное? Мне, к примеру, как пользователю GNU/Linux портит жизнь тормознутость Python, а в нём используются подсчёт ссылок с GC только в качестве страховки от циклов. |
Автор: | Иван Левашев [ Воскресенье, 05 Март, 2017 19:50 ] |
Заголовок сообщения: | Re: Modula-2+ |
Comdiv писал(а): Поэтому мне непонятны необдуманные утверждения про "безнадёжно испорченный". Это уже существенные изменения семантики, создающие другой язык. Безнадёга — она в библиотеках, кишащих программными ошибками. Либо брать с ошибками, либо никаких библиотек, можно считать, и нет. Вот с Modula-2+ — другое дело. Там, конечно, впоследствии были эксперименты с TGC, но штатным режимом был ARC, поэтому как в Objective-C 2.0, можно было ожидать от библиотек, что они на любой режим будут расчитаны, просто тумблером щёлкай, и всё. Comdiv писал(а): OCTAGRAM писал(а): В XUL без JavaScript ничего не обходится. Он постоянно в фоне что-то делает, начинает сборку мусора, потом сообщение вылезает, что скрипт долго не отвечает, и там какой-нибудь JavaScript указан. И какую долю занимает XUL - 90 % или всё-таки меньше 10%? Просто представьте, что вам нужно нанять нового сотрудника для Фонда Мозилла, и либо можно найти такого, что будет писать на C++ хорошо, понимать XPCOM и XPConnect и уметь собрать это всё хотя бы для своей OS, либо можно найти разработчика на JavaScript. Получается, что на C++ только сокеты и базовый UI, а солидная часть — в JavaScript, и там много живых объектов. Если в ARC один раз платить за мёртвые, то в TGC платить за живые. Постоянно. Снова и снова. Оно не будет тихо сидеть, оно постоянно будет делать обход за обходом. На иную программу можно разозлиться, мысленно спросить: «ну ты закончишь там свои дела уже, нет?» Трассирующий сборщик мусора не таков. Ему всегда есть, чем заняться. Comdiv писал(а): злоупотреблении динамической памятью Ну будет вечный двигатель наоборот работать в темпе чуть более медленном, чем обычно.Comdiv писал(а): для мобильных телефонов с 64 кб оперативной памяти я писал приложения тоже на Java с этим ужасным GC, и это работало О, нет, это как раз, на мой взгляд, и есть причина, по которой проблема TGC так далеко зашла. Там не могут программы посоревноваться за своп, буксуя при этом. Там живых объектов может быть не больше, чем эти 64 кб. В Оберон ОС память всех программ была общей, не было свопа и не было конкуренции за него. Программистов завораживало освобождение памяти как бы по волшебству, и ещё не было убийственных побочных эффектов. Tо, что было красиво на 64 кб и даже 640 кб, смасштабировали на несколько Гб, и… Cyberax писал(а): Так можешь не искать, у нас задержка примерно в две минуты на сервере с 16Гб хипом после тюнингов. Что еще не так плохо, кстати. Нам это не так важно, так как неотзывчивый сервер у нас просто из кластера блокируется — Oracle Coherence рулит. … всё это уже не так хорошо выглядит. Comdiv писал(а): Мне, к примеру, как пользователю GNU/Linux портит жизнь тормознутость Python Пользуюсь TortoiseHg и очень доволен, что если оставить его в фоне, он не напоминает о себе, в отличие от некоторых других программ. Насколько мне известно, в Python есть CIL, а раз оно там есть, то источник наиболее частых претензий к ARC, атомарные операции, там должен отсутствовать как явление. Насчёт аномального засилья скриптов и виртуальных машин в Linux у меня есть кое-какие соображения, но это отдельная тема. |
Страница 1 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |