OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 12 Август, 2020 18:09

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




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

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


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

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

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


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

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


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

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

Цитата:

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 436
Цитата:
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
Сообщения: 436
Код:
А вот про минусы Раста достаточно точно указано

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

Занялись всяким обилием средств, направленным хорошо если на 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
Сообщения: 8351
Откуда: Троицк, Москва
Мракобесные диспуты недоучек (это про хабр).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2020 11:24 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1470
Да - ничто Си не заменит.
Дело - не в языке.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3191
Откуда: Астрахань
ИМХО достаточно в языке запретить ВСЕ умолчания - и минимизировать средства.
Но фреймворк должен быть обширный.
Тогда это будет ВЕСЧЬ!


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1093
Откуда: Киев
В целом, понятно, что Вы имеете ввиду, но

Все правила языка заданы по умолчанию, потому что они внешние по отношению к программе. Есть, конечно, утопические проекты, вроде, SLang от Зуева и Канатова, в которых многое пытаются определить максимально библиотечно, но это неработоспособно из-за той или иной ресурсоёмкости.

Помимо этого есть и другие вещи, удобные выполнением по умолчанию
- переход на следующую инструкцию в линейной последовательности инструкций
- "выделение" и "освобождение" локальных переменных
- отсутствие экспорта у объявлений
- аварийное завершение ошибочного кода, например, из-за выхода за границы массива
- ничего не делание в IF при ложном условии вместо явной ELSE ветки с явным ничем
- можно предположить, что многое из того, что принято воспринимать как должное, но являющееся поведением по умолчанию


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2020 06:58 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3191
Откуда: Астрахань
Comdiv писал(а):
Помимо этого есть и другие вещи, удобные выполнением по умолчанию
- переход на следующую инструкцию в линейной последовательности инструкций
Дык это просто принцип фон Неймана. Это - не умолчание, это - основа.
- "выделение" и "освобождение" локальных переменных
Не. Это уже как раз опыт разработки компиляторов. Можно было и по-другому, но реализация в стеке оказалась наилучшей. Во-первых, с точки зрения эффективности. Во-вторых, понятная семантика возникла
- отсутствие экспорта у объявлений
Под объявлениями что имеется ввиду?
- аварийное завершение ошибочного кода, например, из-за выхода за границы массива
Этого как раз в С-подобных практически нигде нет... :)
- ничего не делание в IF при ложном условии вместо явной ELSE ветки с явным ничем
Дык это как раз так устроена команда условного перехода - никакое это не умолчание
- можно предположить, что многое из того, что принято воспринимать как должное, но являющееся поведением по умолчанию

В целом я согласен, что удобные, понятные и простые в реализации свойства постепенно становятся общепринятыми.
Но я имел ввиду несколько другое.
Самый яркий для меня пример - отсутствие наследования по умолчанию.
Наследование - это фича ВЫСОКОГО уровня.
Поэтому должна управляться программистом.
Собственно, отсюда практически все проблемы С++ - простому прикладному программисту сложно держать в башке все эти действия системы, если он чего-то не написал. Вызовы конструкторов по умолчанию - это для начинающего вообще кошмар.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2020 10:55 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1093
Откуда: Киев
Дык это просто принцип фон Неймана. Это - не умолчание, это - основа.
Здесь нет противоречия. Это поведение по умолчанию положено в основу. Я о том и толкую, что поведение по умолчанию - это нормально, а не зло в общем случае. Если всё поведение должно быть явным, то и любая связь инструкций должна быть явной.

- "выделение" и "освобождение" локальных переменных
Не. Это уже как раз опыт разработки компиляторов. Можно было и по-другому, но реализация в стеке оказалась наилучшей. Во-первых, с точки зрения эффективности. Во-вторых, понятная семантика возникла
Почему "не"? Какая разница, почему это возникло с точки зрения того, является ли это поведением по умолчанию или нет?

Под объявлениями что имеется ввиду?
Любое объявление(declaration) константы, типа, переменной, процедуры и т.д.

Этого как раз в С-подобных практически нигде нет... :)
Во-первых, есть повсеместно(даже в Си, уже устал рассказывать про sanitize, что вписывается в стандарт). Во-вторых, при чём тут С-подобные языки? Если запретить ВСЁ поведение по умолчанию, то аварийный останов тоже надо прописывать явно.

Дык это как раз так устроена команда условного перехода - никакое это не умолчание
Тут снова поиск противоречия, где его нет. Уж если есть ветка "иначе", то никаких умолчаний с её отсутствием. Смысл слова "умолчание" понятен же?

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


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 436
PSV100 писал(а):
Сейчас в IT наблюдаются интересные решения для альтернативного управления "пространством жизни", с меньшим выламыванием мозга при реализации прикладных задач.

Нашёлся ещё один любопытный язык с автоматическим управлением памятью на основе "регионов" (статически в compiletime): ParaSail (Parallel Specification and Implementation Language) от AdaCore:
- ParaSail: A Pointer-Free Pervasively-Parallel Language for Irregular Computations
- презентация

Впечатление, что это некий испытательный полигон для Ada/SPARK (напр., в новый планируемый стандарт Ada 202x также вводятся параллельные действия и параллельные циклы, имеющиеся и в ParaSail).
Примечательно, какие именно "impediments" ликвидированы в языке:
ParaSail: Less is more with multicore
Цитата:
What are the impediments to easy parallel programming? With apologies to David Letterman, we would identify the following as the biggest impediments to doing things efficiently and safely in a highly parallel multicore world:

* Global Variables
* Garbage-Collected Global Heap
* Parameter Aliasing
* Run-Time Exception Handling
* Explicit Threads
* Explicit Lock/Unlock
* Explicit Wait/Signal
* Race Conditions
and worst of all …
* Pointers

В языке нет не только глобальных переменных, сборщика мусора и пр., но и "самого худшего" -- традиционных указателей. Введены опциональные типы (объект содержит null или "владеет" определенным значением). Также имеются локальные временные ссылки на объекты (ссылочные параметры процедур и локальные переменные специального типа ref). Конструкции языка позволяют выразить, напр., рекурсивные типы, но затруднительно с циклическими структурами и в целом с произвольными ссылками. В подобных случаях для агрегатных типов предлагают реализовывать (перегружать) операцию "индексации" (как в массивах). Авторы утверждают, что такое положение дел лучше, чем, напр., в SPARK, который для гибких динамических структур принуждает к эквилибристике на массивах (по-видимому, фактически, в ParaSail эта эквилибристика запаковывается вовнутрь реализации типа).
Такие ограничения, однако, позволяют организовать контроль памяти компилятором, в том числе и недопущение алиасов на изменяемые объекты (а также, видимо, возникает больше эффективности у системы верификации программ (имеется на борту) и пр.).


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

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


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

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


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

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