LINUX.ORG.RU

Ada в 2024

 , ,


0

5

Привет, ЛОР!

В тредах про Rust и сишечку периодически всплывает пример языка Ada в качестве аргумента, что Rust, дескать, не нужен.

Скажи, а есть ли примеры историй успеха, связанных с этим языком? Вот, например, передо мной сейчас стоит задача написать некоторое количество довольно низкоуровневого кода и хочется использовать инструменты, от которых не придётся отказываться через 5 лет. И если этот инструмент будет лучше чем сишка по скорости и качеству разработки, то о нём как минимум стоит слышать.

Про Ada Core, SPARK и Alire я в курсе. Хочу историй типа «у нас было три килограмма говнокода на C, мы его выкинули и переписали на Ada, и теперь багов стало с 8 раз меньше, а девки стали давать в 5 раз чаще».

Пока что есть только история неуспеха от анонимуса, но этого явно мало, чтобы судить об инструменте.

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 1)

Ответ на: комментарий от hateyoufeel

лавсанчег активно путает аллокацию в сборщике мусора с уплотнением, которая там инкрементная, забыв, сколько стоит такое уплотнение и что для этого надо иметь.

про апдейт указателей при уплотнении он отвечать отказывается. он сцуко даже не понимает как оно делается.

про то, что при сборке надо сначала облазить все доступные обьекты, как из кучи, так из регистров и локальных фреймов функций всех тредов - ему тоже пофиг.

alysnix ★★★
()
Ответ на: комментарий от alysnix

про то, что при сборке надо сначала облазить все доступные обьекты, как из кучи, так из регистров и локальных фреймов функций всех тредов - ему тоже пофиг.

Зависит от языка. В хачкелло-эрлангах вот не надо. Прелести иммутабельности.

Но меня больше удивляет, что я ещё не видел реализации языка с ГЦ с относительной адресацией. Потому что многие объекты ссылаются на другие, лежащие всегда рядом в памяти.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Зависит от языка. В хачкелло-эрлангах вот не надо. Прелести иммутабельности.

Правда о сопоставимом throughput на изменяемых данных приходится забыть из-за постоянного копирования для модификации.

cumvillain
()
Ответ на: комментарий от hateyoufeel

Зависит от языка.

какую стратегию б ты не использовал, на любой аллок должен быть свой деаллок.

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

и для этого надо иметь и дескрипторы всех обьектов, и всех фреймов, и это стоит и памяти и тактов.

как бы инкременто не аллокировался обьект, на N аллокаций, надо N деалокаций, что муторно в сборщиках мусора.

alysnix ★★★
()
Ответ на: комментарий от hateyoufeel

Потому что многие объекты ссылаются на другие, лежащие всегда рядом в памяти.

зачем она? для относительной адресации надо два регистра - база и смещение, а для обычной - только один.

и потом - как понять когда указатель относительный и когда абсолютный?

alysnix ★★★
()
Ответ на: комментарий от lovesan

ну так как перемещать обьекты в памяти, чтобы твой alloc был инкрементным? и чтоб ты радостно вопил, что память быстрей аллоцируется. это ж ключевой момент твоей пурги.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Потому что многие объекты ссылаются на другие, лежащие всегда рядом в памяти.

зачем она? для относительной адресации надо два регистра - база и смещение, а для обычной - только один.

По двум причинам:

  1. Чтобы не хранить целиком 8 байт указателя. Если посмотришь, из чего состоят структуры данных в языках с GC (да и не только), там просто дохрена памяти уходит на указатели;
  2. Чтобы не обновлять указатели, если весь регион памяти переносится целиком.

и потом - как понять когда указатель относительный и когда абсолютный?

Тег поставь.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Тег поставь.

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

на надо этого. указатель должен быть скалярным обьектом и передаваться в одном регистре всегда.

alysnix ★★★
()
Ответ на: комментарий от alysnix

какую стратегию б ты не использовал, на любой аллок должен быть свой деаллок.

как бы инкременто не аллокировался обьект, на N аллокаций, надо N деалокаций, что муторно в сборщиках мусора.

Нет. В случае с generational gc, в новое поколение копируются только живые объекты и те, на которые они ссылаются. Под живыми подразумеваются те, на которые есть ссылки из текущего кода/тредов.

У эрланго-хацкеллов тут есть жирный бонус ввиду иммутабельности в том, что старые объекты не могут ссылаться на более новые. То есть, если у тебя самый новый живой объект имеет адрес X, то на все объекты начиная с X+1 можно класть жирный болт, они мертвы.

Ещё жирным бонусом по части generational gc идёт то, что в них есть отдельное нулевое поколение nursery (ясли), которое обычно имеет размер кэша процессора. Профит в том, что подавляющее большинство объектов долго не живут, и 80-90% из них не покидают ясли в принципе. Соответственно, при переносе из яслей в первое поколение, нужно обработать только 10-20% объектов, а остальные просто сносятся скопом и даже в оперативную память не попадают.

GC действительно эволюционировали и весьма сильно за последние лет 50, тут лавсанчег прав. Но в чём он неправ, так это в том, что GC будет быстрее ручного управления. Как показывает практика, не будет, если не задрачивать GC до такой степени, что код выглядит хуже чем на C++.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от alysnix

вот есть функция, принимающая указатель.

Нету такой функции. Если мы говорим о языках с GC, то ни о какой работе с сырыми указателями и речи идти не может. Это всё подковёрные половые трудности рантайма языка.

на надо этого. указатель должен быть скалярным обьектом и передаваться в одном регистре всегда.

Он и будет. Тег можно прямо внутри скаляра всунуть. Благо, разгуляться есть где.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

У эрланго-хацкеллов тут есть жирный бонус ввиду иммутабельности

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

которое обычно имеет размер кэша процессора.

кеш процессора один на все ядро. и явно не может монопольно принадлежать приложению.

В случае с generational gc, в новое поколение копируются только живые объекты и те, на которые они ссылаются.

и чтобы найти живые - надо пройти все обьекты от корня, локальных фреймов и регистров. а чтобы переместить - надо навтыкать на место старых объектов заглушки с тегом <перемещено> и куда перемещено. и все адреса, что будут показывать на эти заглушки надо апдейтить на новый адрес.

alysnix ★★★
()
Ответ на: комментарий от hateyoufeel

Если мы говорим о языках с GC, то ни о какой работе с сырыми указателями и речи идти не может.

указатели там есть. просто они называются ссылками. но физически это адреса.

alysnix ★★★
()
Ответ на: комментарий от hateyoufeel

Как показывает практика, не будет, если не задрачивать GC до такой степени, что код выглядит хуже чем на C++.

там есть еще одна деталь о которой предпочитают помалкивать, и понятно почему.

https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

разные алгоритмы GC дают сравнимую производительность с ручным управлением при обьеме расходуемой памяти в 5 раз больше.

то есть именно потому что памяти полно, они редко собирают мусор, и могут подползти к ручному управлению, за счет копирования только живых обьектов. но памяти на кучу нужно в 5 раз больше. :)

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

Нет.

кеш процессора один на все ядро. и явно не может монопольно принадлежать приложению.

Может на короткий момент времени. Но для короткоживущих объектов это норм. Плюс, можно использовать только часть кэша, например, и расчитывать что он не инвалидируется за то время, что процесс ждёт исполнения. Что в принципе верно в большинстве ситуаций.

и чтобы найти живые - надо пройти все обьекты от корня, локальных фреймов и регистров. а чтобы переместить - надо навтыкать на место старых объектов заглушки с тегом <перемещено> и куда перемещено. и все адреса, что будут показывать на эти заглушки надо апдейтить на новый адрес.

Не надо никуда ничего втыкать. Прочитай ещё раз про generational gc, там живые объекты копируются, а старые убиваются скопом.

указатели там есть. просто они называются ссылками. но физически это адреса.

Нет, нету. С точки зрения программиста на этом языке у него есть только значения, и его в 99.9% случаев абсолютно не парит что там под капотом.

разные алгоритмы GC дают сравнимую производительность с ручным управлением при обьеме расходуемой памяти в 5 раз больше.

Ну, да. Всё так. Если повезёт, то всего в два раза. Если не повезёт, то в 10. Главное, лавсанчегу об этом не говори.

то есть именно потому что памяти полно, они редко собирают мусор

Не, это не имеет отношения к частоте сборки мусора. Там другие проблемы.

А вот что действительно очень плохо, так это то, что почти все языки с GC на время сборки мусора выключают работу вообще всех тредов в процессе. Потому что у них шаренная куча, и собрать мусор для одного треда, пока другой может насрать в память, не представляется возможным. Там работает Жаба, так работает сисярп, так работают лиспы и даже Haskell так работает. Единственное исключение тут – Erlang, потому что у него на каждый его микропроцесс своя куча сделана и память они не шарят (ETS не считается).

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

там живые объекты копируются,

как ты будешь копировать живой объект, если ссылка на него, то есть физический адрес, лежит в каком-то регистре, или вообще спасена на стек, у спящего треда. и когда тред проснется, окажется, что ссылка указывает на обьект который передвинули

alysnix ★★★
()
Ответ на: комментарий от alysnix

там живые объекты копируются,

как ты будешь копировать живой объект, если ссылка на него, то есть физический адрес, лежит в каком-то регистре, или вообще спасена на стек, у спящего треда. и когда тред проснется, окажется, что ссылка указывает на обьект который передвинули

В регистре её не будет, потому что перед началом GC происходит синхронизация тредов. Тут как раз нет проблемы.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

синхронизация тредов.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

синхронизация тредов.

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

Господи, чувак. Ну сходи исходники рантайма любого язычка почитай, я не знаю.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Но в чём он неправ, так это в том, что GC будет быстрее ручного управления. Как показывает практика, не будет, если не задрачивать GC до такой степени, что код выглядит хуже чем на C++.

Я скажу, что ручное управление памятью тупо не везде применимо, не то, что быстрее. Если, например, твоя структура данных это граф, живущий всё время работы программы, то у тебя не остаётся выбора кроме как использовать сборку мусора.
Но в целом, хочешь чтобы было хорошо — делай осмысленный выбор в зависимости от задачи. Иногда ты выбираешь GC, иногда — арену, иногда — что-то ещё.

quantum-troll ★★★★★
()
Ответ на: комментарий от alysnix

то у тебя не остаётся выбора кроме как использовать сборку мусора.

вы какбэ намекаете, что на с++ и тем более си, графы корректно нереализуемы? ой-ёй-ёй-ёй-ёй!

Нет. Он намекает, что на C и C++ придётся самому реализовывать наколеночный сборщик мусора для подобных структур. Что обычно и происходит, собственно.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

Ты шизофреник, твои намёки как минимум непонятны, а скорее даже и неинтересны.

надо взять какую-нить либу для работы с графами и не парить себе мозг каким-то наколенным сборщиком.

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

там еще куча разных алгоритмов и функциональности, которые давно не стоит велосипедить.

Да. А ещё можно взять язык с GC и не велосипедить этот GC в библиотеку. А если у тебя таких библиотек одновременно три или четыре, то сэкономишь кучу кода!

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

Кстати, забавно, что ты про жабу тут упомянул. Потому что одна из самых популярных графовых баз данных написана… НА ЖАБЕ!

https://github.com/neo4j/neo4j

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

на жабе много чего написано и работает оно медленно и печально. упомянул жабу как монстра, переходить на которую ради удаления узлов и подграфов - это идиотизьм.

alysnix ★★★
()

Кстати, ещё же есть RTSJ, и её бесплатные реализации, типа JamaicaVM. И для мавена вроде есть пакеты, т.е. тулингом не обделено. Почему оно не рассматривается как альтернатива? Слухи сообщают нам, что чуть ли не в американском патриот софт на RTSJ.

seiken ★★★★★
()
Ответ на: комментарий от seiken

Java

Потому что мне лично в данном случае требуется нулевой или близкий к тому рантайм.

А ещё потому что оно выглядит ещё более дохлым чем Ada.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
16 мая 2024 г.