OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 22 Сентябрь, 2017 03:47

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




Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 12:25 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
Был ещё и такой диалект: https://en.wikipedia.org/wiki/Modula-2%2B

Чтобы понять, чем он примечателен, давайте посмотрим, как обстоят дела с ARC в ветках Паскаля:

  • Modula-2: нету
  • Delphi для Windows: лишняя писанина, дублировать и синхронизировать классы и интерфейсы
  • Ada: лишняя писанина, дублировать и синхронизировать классы и умные указатели
  • Delphi для мобильных: нет версии для Windows и Mac OS X
  • Oberon-2: безнадёжно сломан трассирующим сборщиком мусора
  • Oxygene: только в версии для Apple, остальные безнадёжно сломаны трассирующим сборщиком мусора

Куда ни кинь, всюду клин. И тут оказывается, что был язык, в котором сделано хоть как-то близко к нормальному. Этим и примечателен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 15:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8781
Откуда: Россия, Орёл
Простите, что-то не считал мысль: обстоят дела с чем? С ARC? А что это?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 15:34 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 95
Откуда: Москва
Automatic Reference Counting https://habrahabr.ru/post/209288/
OCTAGRAM писал(а):
[*]Oberon-2: безнадёжно сломан трассирующим сборщиком мусора

Хотелось бы прояснить


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 16:20 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Илья Ермаков писал(а):
Простите, что-то не считал мысль: обстоят дела с чем? С ARC? А что это?

Automatic reference counting, вестимо.
Правда, непонятно, почему такая возможность сломана в Обероне-2. В этом плане Оберон-2 не отличается от простого Оберона( или нет?), а я проводил эксперимент в простом Обероне - на нём вполне можно программировать с ARC без внесений изменений в язык с той разницей, что циклические связи нужно разрывать самостоятельно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 19:16 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
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
Swap.png [ 8.8 КБ | Просмотров: 727 ]


За свои программы по возможности краснеть не хочется. Зная о том, как потом на больших масштабах кода и данных будет болезненно лечиться от TGC, разумно просто не начинать. Всё, что с неизвлекаемой или сильно въевшейся трассирующей сборкой мусора, отбрасывать без сожалений.

И получается, что из веток C есть Objective-C 2.0 и C++/CX, а в ветках Паскаля — негусто.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 21:30 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8781
Откуда: Россия, Орёл
Первый раз вижу такую аббревиатуру, обычно просто reference counting. Это либо с ObjC повелось?
Там ещё у Compaq-DEC (Вы же на их Модулу 2+ ссылку давали) и свой смысл был ARC, имя собственное )

Про трассирующий GC согласен.
И про то, что способ управления памятью пронизывает всё - и потом фиг поменяешь, тоже очень важно понимать.

У меня для КП есть решение. Не "всепогодное", но для систем с детерминированной нагрузкой (массовое обслуживание запросов со статистическим распределением, так сказать; ну а для большинства систем управления и встроенки вообще детерминированное количество объектов циркулирует, ещё проще жить).
Дмитрий Дагаев на Оберон-дне 2015 рассказывал про их решение для Active Oberon с выделением на старте и потом выключением.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 21:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8781
Откуда: Россия, Орёл
P.S. Присмотрелся к ARC внимательнее. Да, это не просто reference counting.
А расширенная поддержка компилятором, статический анализ.
С одной стороны, хорошо, когда что-то уходит на компилятор.
С другой стороны, иногда тонкости скрытого поведения ещё сложнее держать в голове, чем что-то делать явно.
Мне механизм показался сложным для безошибочного использования средним разработчиком.

Лучше любой вариант явного освобождения с гарантией не-разрушения памяти (в машинах с широкой адресацией типа Эльбруса - однократное использование виртуального адреса; на обычной архитектуре - хранение доп. метки UID адресуемого объекта вместе с указателем и сверка при обращении; либо рециркуляция объектов по типам).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Суббота, 04 Март, 2017 21:57 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 95
Откуда: Москва
Но вопрос поднят правильно, спасибо, проблема существует.
Для каждой новой задачи приходилось искать приемлемое решение, для мягкого RealTime (SCADA), вызываю GC в 10 сек цикле.
Для жесткого - да, запрещал.

Что хорошо, можно подкрутить под задачу рантайм в Blackbox, A2, Ofront. Рано или поздно, кто-то под llvm серьезно перейдет, и новый механизм там и окажется. Кто знает, кто знает, есть над чем подумать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 00:30 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
OCTAGRAM писал(а):
Как ни глянешь в Диспетчер задач, так сразу понятно, кто у нас тут трассирующую сборку мусора применяет, перетягивая своп туда-сюда:
Вложение:
Swap.png

Неужели Thunderbird, написанный на С++?
Вообще, подсчёт ссылок даёт больше накладных расходов, чем сборщик мусора и паузы может давать сопоставимые за счёт длинных цепочек освобождения.
В Java главная проблема - это злоупотребление динамической памятью, а не само наличие сборщика мусора.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 10:16 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 95
Откуда: Москва
Comdiv писал(а):
я проводил эксперимент в простом Обероне - на нём вполне можно программировать с ARC без внесений изменений в язык с той разницей, что циклические связи нужно разрывать самостоятельно.

А поподробнее можете рассказать?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 10:38 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
Comdiv писал(а):
Неужели Thunderbird, написанный на С++?

В XUL без JavaScript ничего не обходится. Он постоянно в фоне что-то делает, начинает сборку мусора, потом сообщение вылезает, что скрипт долго не отвечает, и там какой-нибудь JavaScript указан.

Comdiv писал(а):
Вообще, подсчёт ссылок даёт больше накладных расходов, чем сборщик мусора и паузы может давать сопоставимые за счёт длинных цепочек освобождения.


Я слышал это много раз, но никогда не видел. Зато я видел, как работал Хакинтош 10.4.10 (когда TGC ещё не поддерживался в движке Objective-C) на 512Mb RAM. И я вижу, как загоняет в ноль современное железо Windows 10 на 4Гб RAM, где помешательство на .NET на своём пике. Я вижу, как жрут батарею Андроиды и как — BlackBerry и iOS. Я вижу, как работает J2EE сервер и как работает AWS. Мне понятно, как получаются дикие фризы, когда программы по очереди ходят собирать мусор и вязнут в соревновании за страницы памяти. Они делают это снова и снова. Это же как вечный двигатель наоборот!

Я сыт по горло этими постоянными играми «вот там трассирующий сборщик мусора плохой, но здесь-то точно хороший». Может быть, совпадение, но мне почему-то постоянно не везёт, всё сплошь плохие попадаются, и мне это надоело. Надоело держать в уме, сколько на компьютере сейчас запущено программ со сборкой мусора и хватит ли ресурсов для ещё одной. И не хочу, чтобы в эти игры играли пользователи моих программ. Хочу делать программы, которые работают и не парят мозг своим вечным двигателем наоборот. Пусть там каждая пауза будет по делу, а не чтобы втихушку сгладить програмные ошибки взаимного владения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 11:37 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7616
Откуда: Троицк, Москва
Comdiv писал(а):
В Java главная проблема - это злоупотребление динамической памятью
Поясните, пожалуйста.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 14:22 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Дмитрий Дагаев писал(а):
Comdiv писал(а):
я проводил эксперимент в простом Обероне - на нём вполне можно программировать с ARC без внесений изменений в язык с той разницей, что циклические связи нужно разрывать самостоятельно.

А поподробнее можете рассказать?

В своём недоделанном трансляторе с Оберона на Си https://github.com/ComdivByZero/vostok я сделал три возможности работы с памятью - без освобождения, с подсчётом ссылок и со сборщиком мусора. Подсчёт ссылок был сделан на уровне доказательства концепции, без автоматической цепочки освобождений, но вполне работоспособным на простых примерах.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 15:12 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 95
Откуда: Москва
Раз концепция доказала, значит в Вашем трансляторе можно будет указать (например, как я бы видел):
Код:
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-цикле освободит память.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 15:36 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Info21 писал(а):
Comdiv писал(а):
В Java главная проблема - это злоупотребление динамической памятью
Поясните, пожалуйста.

И сам язык располагает и программисты на нём привыкли сорить памятью.

Язык не позволяет использовать локальные объекты и массивы, которые можно выделять на стеке, оставляя эту оптимизацию на сложный транслятор. Но поскольку программист не осознаёт в явном виде разницу, то он легко блокирует возможность использования объектов на стеке даже для сложного транслятора.

Наглядный пример из языка:
Код:
Point [128][128] points;

Это двумерный массив точек. При необходимости, в нормальных языках его можно представить как один объект, который даже может быть выделен статически. В Java - это (1 + 128 + 128 * 128) динамически выделенных объектов. Тут не только проигрыш в сборке освобождённой памяти, но и на выделение тратится куда больше времени.

Про программистов - это отдельная песня. Недавно говорил с коллегой, для которого основная специализация - это Verilog, но также у него есть хобби-проект для Android. Он искал хорошее решение для создания неизменяемых объектов с большим количеством параметров, что при решении в лоб приводит к длинному списку аргументов у конструктора. На просторах интернета он нашёл решение - для создания неизменяемого объекта создаётся один изменяемый, после установки полей которого, вызывается метод создания искомого. Типичное производство мусора в Java.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 16:10 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7616
Откуда: Троицк, Москва
Большое спасибо, понятно.

Основная причина была известна, но масштаб последствий -- неожиданный.

Пузырь избыточной сложности в сфере IT становится каким-то совсем оголтелым.

Интересно, куда кривая привезёт.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 16:39 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 95
Откуда: Москва
Кстати, реализация POINTER TO RECORD [strong] приведёт ещё и
к решению проблемы многопоточности и проблемы контроля за стеками при кооперативной многозадачности


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 18:20 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Дмитрий Дагаев писал(а):
Раз концепция доказала, значит в Вашем трансляторе можно будет указать (например, как я бы видел):
...
Код:
PtrRefCount = POINTER TO RECORD [strong]
    next: PtrRefCount
END;
...
    NEW(p); p.next := p;
...
    (* p.next := NIL *) p := NIL;

- Во втором случае PtrRefCount освобождение не произойдет, потому, что есть ссылка сама на себя. Но, если раскомментировать и разорвать ссылку, то освобождение произойдет немедленно при p := NIL;

Верно, но с той разницей, что у меня 3-и возможности работы с памятью существуют не одновременно, а нужный режим выбирается во время трансляции. Это позволяет оставить язык неизменным, собственно, этого я и добивался. Поэтому мне непонятны необдуманные утверждения про "безнадёжно испорченный".

Ваш пример я добавил в тесты.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 18:51 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
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 только в качестве страховки от циклов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Modula-2+
СообщениеДобавлено: Воскресенье, 05 Март, 2017 19:50 
Аватара пользователя

Зарегистрирован: Пятница, 23 Май, 2008 09:24
Сообщения: 32
Откуда: Барнаул
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 у меня есть кое-какие соображения, но это отдельная тема.


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

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


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

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


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

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