OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 03 Апрель, 2020 04:13

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




Начать новую тему Ответить на тему  [ Сообщений: 8 ] 
Автор Сообщение
СообщениеДобавлено: Среда, 26 Февраль, 2020 23:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9222
Откуда: Россия, Орёл
https://habr.com/ru/post/460989/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Февраль, 2020 05:48 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2709
Rust не для тех, кто хочет работать в предметной области, и поэтому он мне не нравится. Не хочу думать про сборку мусора, например.
Так что может для профессиональных программистов — это хороший язык, а для меня он не лучше C.

MultiOberon тоже LLVM умеет теперь, который обеспечивает скорость для Rust.
Соложноватую правда Дмитрий Викторович сделал структуру проекта. До сих пор въехать не могу :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Февраль, 2020 13:06 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9222
Откуда: Россия, Орёл
Иван Денисов писал(а):
Rust не для тех, кто хочет работать в предметной области, и поэтому он мне не нравится. Не хочу думать про сборку мусора, например.
Так что может для профессиональных программистов — это хороший язык, а для меня он не лучше C.


Да, именно так.

Я тут высказывал в диалоге с коллегой:

Цитата:

А вот про минусы Раста достаточно точно указано

Они нарушают Парето

Занялись всяким обилием средств, направленным хорошо если на 20%, а то на 10% проблем

Загромождая решение прикладной задачи

Ну и, типа, "грамотно-формально" спроектировали типы, пространства жизни и т.п. Примерно как языковое развитие всяких safe pointerов на шаблонах, которые в библиотеках С++.

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

Rust реально набирает обороты в замену С/С++ в системщине именно на волне безопасности. Что уязвимости и переполнения никто больше терпеть не хочет.

Но железячники тяжко на него вздыхают - ибо чтоб его грамотно использовать, нужно продышаться абстракциями его примерно как с С++ с шаблонами и либами или как с Хаскелем.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Февраль, 2020 19:21 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 433
Откуда: Москва
Иван Денисов писал(а):
MultiOberon тоже LLVM умеет теперь, который обеспечивает скорость для Rust.
Соложноватую правда Дмитрий Викторович сделал структуру проекта. До сих пор въехать не могу :)

Спасибо за критику, но я в процессе. Система управления сборкой будет кардинально меняться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Февраль, 2020 19:26 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2709
Дмитрий Дагаев писал(а):
Иван Денисов писал(а):
MultiOberon тоже LLVM умеет теперь, который обеспечивает скорость для Rust.
Соложноватую правда Дмитрий Викторович сделал структуру проекта. До сих пор въехать не могу :)

Спасибо за критику, но я в процессе. Система управления сборкой будет кардинально меняться.

Низкий поклон вам за труд с LLVM и творческих успехов!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Март, 2020 20:45 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 410
Цитата:
Rust не для тех, кто хочет работать в предметной области, и поэтому он мне не нравится. Не хочу думать про сборку мусора, например.
Так что может для профессиональных программистов — это хороший язык, а для меня он не лучше C.

MultiOberon тоже LLVM умеет теперь, который обеспечивает скорость для Rust.

Но в Rust-е пока не внедрён сборщик мусора ("box"-ы на основе GC, имевшее место когда-то в ранних версиях до релиза, пока выпилены до лучших времён).

Во время последнего из опубликованных докладов Дня Оберона (про "метапрограммирование") была фоновая реплика от Недори насчёт языка Jai (обращал внимание на организацию вычислений в compiletime, а также в его заметках есть акцент на Jai как пример решения проблематики ООП). Язык декларируется как замена С в области gamedev-а. Там принципиально отказываются от сборщика на уровне "философии языка", мусорщик не решает проблем в этой предметке ("video games are machines that fill memory", "data-oriented programming"), но создаёт новые ("language features like garbage collection and templated data streams and dynamic string classes may help the programmer write code faster, but they don’t help the programmer write faster code"). Используются "владеющие" указатели, custom-аллокаторы, инициализация по умолчанию, Data-Oriented Structures (с возможностью автоматической (на уровне типа) конвертации из массива структур в структуру массивов), Joint Allocations (может быть и какие-то иные техники, но необходимо изучать многочасовые видео-материалы).

В Java, например, наблюдается весьма любопытный эксперимент для задач "Big Data" -- на основе существующих алгоритмов HotSpot (и без изменения в языке, как альтернатива использованию внешних heap) внедряется возможность организации множества динамических "поколений" (в дополнение к традиционным двум old и young) для уменьшения количества операций копирования объектов между "поколениями", фактически, косвенно вводится тот же custom-аллокатор (добавляется небольшой API и аннотации к операции new):
* NG2C: Pretenuring Garbage Collector with Dynamic Generations for HotSpot Big Data Apps
* Презентация

На форуме недавно была ссылка на полезный доклад о проблемах сборщика, от товарища-разработчика из Excelsior, где акцентируется на смене их технологии -- после многолетнего применения "консервативной" модели вынуждены были перейти к "точной" (затруднительно в "консервативщине" обеспечить корректность и не допускать "мертвецов", да и при "точной" модели не обойтись без всяких ручных дёргалок вокруг сборщика и помогалок вида "слабых" ссылок аля java.lang.ref), с увеличенными затратами (из-за save point и прочие барьеры записи/чтения):
https://forum.oberoncore.ru/viewtopic.php?f=22&t=6529&sid=3c963af72aca980f0b6fe68041ca5eb1#p110604

В докладе отмечается, что, всё же, вынужденны отказываться от некоторых оптимизаций кода, однако без конкретики. По поводу вспоминается старенькая статейка насчёт экспериментов вокруг Modula 3, где был акцент на проблематике этапа сканирования -- либо не допускать некоторые оптимизации, либо сканирование -- дело непростое, например:
A Language-Independent Garbage Collector Toolkit
Цитата:
The stack map is necessary but not sufficient for stack and register decoding in the presence of optimizations. For example, if a procedure has many uses of the expression A[i-100], the optimizer may calculate the address of A[-100] and use it as a base for address calculations. If the array A is in the heap and a scavenge occurs, we must properly update the base register. We use the term attached pointers for pointers attached to heap objects in this way. To handle attached pointers we augment the map to indicate what the pointer is attached to (A in this case). At scavenge time the attached pointer is converted to an offset, then at the end of the scavenge, the offset is converted back into a pointer. A similar example arises when two arrays are frequently indexed by the same value, e.g., A[i] and B[i]. It can be more efficient on some architectures to calculate the difference B - A of the addresses of A and B, with B[i] accessed via double indexing from A[i]. The difference is an example of a derived pointer value. Such derived values can be noted in the map and recalculated after a scavenge. It is also possible for derived values to be calculated differently on different paths in a program, which requires a small amount of work at run-time so that the collector can determine which derivation was actually used. Finally, parameters passed by reference lead to pointers into the middle of objects. These are handled similarly to attached pointers. The only differences are that the attachment crosses procedure boundaries so caller help is required, and we can end up with long chains of attachments through many levels of call.

К слову, в статейке выше ещё в те года (начало 90-х) предлагалось автоматически множество поколений (меньше копирования и лучше дефрагментация).
В докладе от Excelsior упоминается и проблематика финализаторов, несмотря на объявление их как deprecated отказаться и выпилить их, фактически, невозможно. Ещё в начале 2000-х была статья от товарища Boehm (не случайный человек в сфере мусорщиков), где он указывал прежде всего на изначально кривой дизайн этих финализаторов в Java и C# (в статейке затрагивается и универсальная сборка на "reference counter", также имеющая проблемы с деструкторами в общем случае), и показал, что в той же Modula 3 решения были куда "прямее" (напр., в Modula осуществлялось упорядочивание исполнения финализаторов на основе зависимости между объектами, выявляемой косвенно -- объект может содержать ссылки на другие объекты, но не использовать их в финализаторе):
* Destructors, Finalizers, and Synchronization
* Презентация

В статейке Boehm упоминает и про некоторые оптимизации от компиляторов, которые могут привести к некорректной отработке финализаторов.

В соседнем разделе форума есть тема про Esterel, где встречаются материалы и про Real Time Java, там наблюдаются немалые ухищрения для сборщика (если он допустим), чтобы обеспечить этот Real Time. Последствия могут быть даже такие, как, напр., трансформация стандартных массивов в некое виртуальное понятие -- далеко не всегда массив может быть выделен как непрерывный блок памяти (деятельность сборщика/аллокатора должна предполагать возможность крайне высокой "инкрементальности" -- очень частое прерывание своей работы (и обеспечение прикладной и прочей системной активности) и непрерывное управление дефрагментацией). Соответственно возникают нюансы и при взаимодействии с С-окружением и т.д.


Видимо, в целом способ управления памятью -- ключевая штуковина, фундаментально определяющая всю архитектуру ПО, его структуру и свойства.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Март, 2020 20:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 410
Код:
А вот про минусы Раста достаточно точно указано

Они нарушают Парето

Занялись всяким обилием средств, направленным хорошо если на 20%, а то на 10% проблем

Загромождая решение прикладной задачи

Ну и, типа, "грамотно-формально" спроектировали типы, пространства жизни и т.п. Примерно как языковое развитие всяких safe pointerов на шаблонах, которые в библиотеках С++.

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

Rust реально набирает обороты в замену С/С++ в системщине именно на волне безопасности. Что уязвимости и переполнения никто больше терпеть не хочет.

Но железячники тяжко на него вздыхают - ибо чтоб его грамотно использовать, нужно продышаться абстракциями его примерно как с С++ с шаблонами и либами или как с Хаскелем.

Сейчас в IT наблюдаются интересные решения для альтернативного управления "пространством жизни", с меньшим выламыванием мозга при реализации прикладных задач.

Здесь где-то на форуме была ссылка на язык V -- альтернатива C, Go-подобный (с заимствованием всяких fn, mut, pub от Rust), с впечатлением от Оберонов. Работа с памятью выглядит также как и в Go, однако "no garbage collection or reference counting". Проект в начальной стадии (хотя есть уже некоторые работающие приложения), мало документации. Скорее (исходя из скудных публикаций), применяется техника автоматического определения "регионов жизни", когда-то возникшая в одной из вариаций ML (однако, тогда она была лишь частично автоматизирована, "ручное" управление досталось от ML к Cyclone, а затем и Rust-у).
В "лабораториях" Oracle также есть подобные эксперименты для Java, в т.ч. на основе опыта из Real Time (там предусматривается полуавтоматическое управление "регионами"). В статейках ниже есть суть техники:
* Safe and Efficient Hybrid Memory Management for Java
* Презентация

"Hybrid management" выше предполагает и использование традиционного сборщика для обслуживания или наличия глобальных объектов. В "Vlang" же целенаправленно нет глобальных переменных (во всяком случае для "прикладных задач", нет и иных языковых инструментов как модные "объекты-компаньоны" для классов и прочие средства для синглтонов), соответственно все иерархические "регионы" детерминированы, и сборщик не используется.

Если принять такое автоматическое управление "регионами жизни", то возникает задача управления иной жизнью -- "жизнь без глобальных переменных" -- вновь, способ работы с памятью кардинально влияет на архитектуру ПО.

В принципе то, например, для самого Go есть даже "a theory of modern Go" -- "манифест" отказа от глобальных синглтонов (в т.ч. и с переключаемым состоянием). В качестве примера методики указывается Go kit, первичный tutorial раскрывает суть архитектуры -- к вопросу организации "компонент", актуальному здесь на форуме согласно обсуждениям докладов последней Оберон-конференции и смежных вопросов.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8298
Откуда: Троицк, Москва
Мракобесные диспуты недоучек (это про хабр).


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 8 ] 

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


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

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


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

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