[00:00:57] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <ага, ага. "нормально…>
Я реально применял literate-style в верилог-прошивках. Когда потребовалось через 4 года вносить правки - самому себе сказал огромное спасибо, почти как в той истории :)
[00:01:00] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Ну это часто так. По…>
надо было сказать, что "починил" 🙂 еще через полгода может обнаружили бы, что снова не работает 🙂
[00:04:07] <ada_ru> (vasil_sd) отвечает (vasil_sd) на <Я реально применял l…>
Даже конфиги и скрипты для этого выложил: https://github.com/vasil-sd/literate-rtl
[00:10:59] <ada_ru> (vasil_sd) Вот ещё вспомнил: https://github.com/vasil-sd/md4litprog
Там можно настроить для literate programming без emacs org mode, через pp pandoc и Ko.
[00:45:44] <ada_ru> (Максим) цитирует (Jellix)
https://github.com/rod-chapman/SPARKNaCl
[01:02:50] <ada_ru> (I_vlxy_I) отвечает (Максим) на <https://github.com/r…>
почему этого еще нет на https://news.ycombinator.com ?
[01:04:25] <ada_ru> (vasil_sd) отвечает (Максим) на <https://github.com/r…>
Круто!
[01:05:19] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <почему этого еще нет…>
Кстати в продолжении дискуссии про комменты:
"
The TweetNaCl code (unsurprisingly) contains no comments at all, so merely understanding its behaviour is non-trivial.
The code deploys various non-obvious mathematical tricks to improve performance.
The code deploys "constant time" algorithms, where no conditional statements depend on sensitive data. This programming style renders the code somewhat difficult to understand, both for a human reader and formal verification tools.
"
[01:06:43] <ada_ru> (I_vlxy_I) значит либо хреновый код либо неподходящий инструмент
[01:06:58] <ada_ru> (I_vlxy_I) точнее, в итоге то код хреновый в любом случае
[01:07:04] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <значит либо хреновый…>
Там просто оптимизированный сишник
[01:07:16] <ada_ru> (I_vlxy_I) ну я и говорю - язык не подходит
[01:07:45] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <ну я и говорю - язык…>
:) Нужно было BrainFuck брать... :)
[01:07:48] <ada_ru> (I_vlxy_I) когда у тебя код после ручного кодинга выглядит так, будто его сгенерировала машина - значит не на том языке ты решаешь задачу
[01:08:39] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <когда у тебя код пос…>
Отчасти да. Но иногда оптимизации могут быть такие, которые автоматика сама не осилит ни на одном языке.
[01:09:58] <ada_ru> (vasil_sd) Даже сейчас часто бывает, что вручную можно сделать такие бит-хаки, что компилятор сделать не сможет. Ну и всякие трюки, которые просто плохо выразимы в любых языках (например, использование битиков в указателях и пр)
[01:10:51] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Отчасти да. Но иногд…>
не так. часто не имеет смысл разрабатывать специальный язык для задачи и специальную автоматическую тулзу для оптимизирующей кодогенерации из этого языка.
[01:11:04] <ada_ru> (I_vlxy_I) проще наструячить на неподходящем языке обмазав доками
[01:11:47] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <проще наструячить на…>
Ну и это тоже.
[01:13:49] <ada_ru> (I_vlxy_I) btw: я не уверен, что спарковская реализация столь же хороша как сишная тут
[01:13:52] <ada_ru> (I_vlxy_I) в плане скорости
[01:14:44] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <в плане скорости>
это нужно тестить. Но теоритически может даже быть быстрее, ибо в спарковом коде можно проверок больше выпилить.
[01:15:01] <ada_ru> (I_vlxy_I) в бОльшую скорость - не верю
[01:15:58] <ada_ru> (I_vlxy_I) ибо про такие штуки много говорят (в теории паскаль быстрее си, в теории хаскель быстрее си и так далее), но на практике - не видел ничего подобного ни разу, кроме, разве что, специально подобранной синтетики
[01:16:05] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <в бОльшую скорость -…>
Это не вопрос веры/ не веры. Это вопрос измерений. Нужно просто взять и имерить со оключенными верифицированными проверками.
[01:17:46] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <ибо про такие штуки …>
Дело в том, что в оптимизации сишных/плюсовых компиляторов столько человеко-лет вложено, что другим компиляторам и не снилось.
Если в компиляторы с других языков столько вложить усилий, думаю результат будет не хуже
[01:18:46] <ada_ru> (vasil_sd) Хотя знаю один компилятор, который на математике почти всегда рвёт сишник - stalin schema
[01:19:05] <ada_ru> (vasil_sd) Он, кстати, компилится в сишник :))))
[01:19:48] <ada_ru> (vasil_sd) https://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)
[01:25:32] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Дело в том, что в оп…>
в clang например, во фронте, нет оптимизаций вообще. все оптимизации там в IR
поэтому нельзя сказать, что в оптимизации для сишного clang там больше вложили чем для какого-нибудь раста или ады
[01:25:44] <ada_ru> (vasil_sd) Вот это позор для западной цивилизации: https://engineering.purdue.edu/~qobi/diversity-statement.pdf
Профессор вынужден явно передислять всех diversyt'нутых с кем имел дело, чтобы не дай бог не обвинили в какой-нить некорректности....
[01:26:30] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <в clang например, во…>
Там много промежуточных стадий, многие из которых специализированны на паттерны, генерируемые фронтэндом.
[01:27:06] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Хотя знаю один компи…>
дык, сталин то это ж full source optimozation, это как написать на плюсах header only project 🙂 оно и компиляет медленно аж жуть
но есть язык который в числодроблении рвет си - это фортран. 🙂 хотя и там и сям gcc например или llvm
[01:27:10] <ada_ru> (nitrocerber) отвечает (vasil_sd) на <Вот это позор для за…>
Высокая наука, как, впрочем, и спорт, да и прочие области жизни уже давно рука об руку с политотой. Ничего нового.
[01:27:16] <ada_ru> (I_vlxy_I) просто за счет отсутствия алиасинга в фортране
[01:27:34] <ada_ru> (vasil_sd) В общем, если пайплайн вылизывают всегда в связке с сишным/плюсовым фронтендом, то неудивительно, что пайплайн специализирован для именно этих фронтэндов явно и неявно
[01:27:52] <ada_ru> (vasil_sd) отвечает (nitrocerber) на <Высокая наука, как, …>
Это печаль ;(
[01:28:25] <ada_ru> (nitrocerber) Это сурвайвл оф зе фиттест.
[01:28:36] <ada_ru> (Yurymaster) Привет, адисты))
[01:28:53] <ada_ru> (nitrocerber) Привет
[01:29:15] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <В общем, если пайпла…>
дык то, что не используется - то умирает. ну или отстает и там накапливаются ошибки. типа как в неиспользуемой ДНК накапливаются ошибки и там уже только обломки генов
[01:29:16] <ada_ru> (vasil_sd) отвечает (Yurymaster) на <Привет, адисты))>
Привет
[01:29:21] <ada_ru> (I_vlxy_I) отвечает (Yurymaster) на <Привет, адисты))>
Йоу!
[01:30:17] <ada_ru> (I_vlxy_I) но, скажем, какую-нибудь жабу юзают очень массово и не меньше чем плюсы. и вылизывают всячески. и неоднократно заявлялось что "жаба обгоняет плюсы!". но нет
[01:31:08] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <дык то, что не испол…>
Ну я с этим и не спорю. Просто из-за моды и пр в пайплайн компиляторов для плюсов/сишника вложено несопоставимо больше усилий чем наверно для всех остальных языков вместе взятых (возможно исключая фортран). Поэтому условия изначально не совсем корректные для сравнения
[01:31:31] <ada_ru> (I_vlxy_I) хорошо, что gnat не самостоятелен (то есть без своего IR и бэка), а является частью gcc таки.
[01:31:40] <ada_ru> (nitrocerber) Эт смотря с какой точки зрения сравнивать
[01:31:42] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <но, скажем, какую-ни…>
Жаба иногда обгоняет плюсы. От задач зависит
[01:31:48] <ada_ru> (nitrocerber) Рынку пофигу на инджастис
[01:32:33] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Жаба иногда обгоняет…>
дофига и оооочень редко. pgo то для плюсов никто не отменял тоже например. как и сборку под конкретную железку
[01:32:42] <ada_ru> (nitrocerber) А академические вопросы - для академиков. А у низ там сертификаты разнообразия, им некогда)
[01:32:47] <ada_ru> (vasil_sd) отвечает (nitrocerber) на <Рынку пофигу на индж…>
Ну рынку-то на всё пофигу. И эволюция там идёт такая же кривая как в реальности :)
[01:33:04] <ada_ru> (nitrocerber) И это печально
[01:33:32] <ada_ru> (I_vlxy_I) сертификэт
[01:33:42] <ada_ru> (nitrocerber) Fittest далеко не всегда best)
[01:33:48] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <дофига (редко) и ооо…>
pgo неадаптивно при серьёзной вариативности данных входных для ПО
[01:34:22] <ada_ru> (vasil_sd) отвечает (vasil_sd) на <pgo неадаптивно при …>
А вот джиты могут в ран-тайм специализацию весьма неплохо
[01:34:24] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <pgo неадаптивно при …>
а джит при такой вариантивности тоже будет дергаться и тормозить. так что...
[01:34:38] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <а джит при такой вар…>
Не факт, зависит
[01:34:43] <ada_ru> (I_vlxy_I) алсо, что мешает jit для плюсов?
[01:34:53] <ada_ru> (I_vlxy_I) что мешает часть с jit плюсы, а часть с pgo?
[01:35:10] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <алсо, что мешает jit…>
В принципе ничего. Кроме религии.
[01:35:24] <ada_ru> (I_vlxy_I) а что мешает c jit Ada и pgo для Ады? 🙂
[01:35:52] <ada_ru> (vasil_sd) Есть интересный ber metaocaml. Он умеет в специализацию по входным данным без жита :)
[01:36:36] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <а что мешает c jit A…>
а оптимизации по профилю разве нет?
[01:36:52] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <а оптимизации по про…>
в gcc должно быть
[01:36:58] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <а что мешает c jit A…>
А Ада с джитом уже есть :)
[01:37:21] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <А Ада с джитом уже е…>
надеюсь без jvm? 🙂
[01:37:23] <ada_ru> (vasil_sd) которая умела в JVM
[01:37:47] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <надеюсь без jvm? 🙂>
к сожалению нет
[01:38:01] <ada_ru> (I_vlxy_I) ну, теперь есть llvm, значит и будет jit
[01:38:43] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <ну, теперь есть llvm…>
Да, это большой шаг вперёд.
Столман своей ошибкой старой gcc приговорил к медленной смерти :(
[03:05:29] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Да, это большой шаг …>
о какой ошибке речь?
[10:57:38] <ada_ru> (shiz01) отвечает (I_vlxy_I) на <ЛЮБОЙ БИДОН ПРАЙМАРИ…>
Лоооооол.
"Что это за солянка, бля, кривыз и убогих?"
[10:57:57] <ada_ru> (shiz01) <прислал наклейку> 🕘
[10:59:04] <ada_ru> (shiz01) отвечает (shiz01) на <Лоооооол.
"Что это з…>
картинка https://www.ada-ru.org/files/bot/2020-02-26-x42.jpg
[10:59:31] <ada_ru> (shiz01) отвечает (I_vlxy_I) на <https://www.youtube.…>
Ммммм, старые добрые бояны...
[11:04:17] <ada_ru> (I_vlxy_I) отвечает (shiz01) на <Лоооооол.
"Что это з…>
Вы все коллеги, коллеги вы все!
Ну или как-то так :-)
[11:05:12] <ada_ru> (shiz01) отвечает (I_vlxy_I) на <Вы все коллеги, колл…>
Дааааа, славное было время...
[11:07:15] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <о какой ошибке речь?>
https://mobile.twitter.com/steipete/status/679207087562481664
[11:09:44] <ada_ru> (vasil_sd) отвечает (vasil_sd) на <https://mobile.twitt…>
В двух словах, он отказался договариваться о gcc плюсовом фронтенде для появляющегося тогда llvm. А потом они сделали clang и конкурента gcc.
[11:10:53] <ada_ru> (vasil_sd) Потом пытался свою резкость и недальновидность свалить на misuderstanding из-за типа плохого почтового клиента.
[11:11:55] <ada_ru> (vasil_sd) В общем, рекомендую загуглить детали, если интересно. Столман потом сильно пожалел, но поезд уже ушёл....
[11:12:26] <ada_ru> (vasil_sd) Комьюнити свободнокомпиляторное уже раскололось
[11:15:24] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <В двух словах, он от…>
Очень хорошо, что clang это не просто фронт к gcc
[11:21:41] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Очень хорошо, что cl…>
Они хотели по-другому: gcc фронт к llvm.
[11:22:08] <ada_ru> (vasil_sd) Но Столман всегда был против модуляризации gcc и вытаскивания gimpl наружу
[11:22:22] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Они хотели по-другом…>
Хорошо, что этого не случилось
[11:23:16] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Но Столман всегда бы…>
Тем не менее, фронт таки теперь отдирабелен. А вот миддл и бэк - пока плавно перетекают друг в друга
[11:23:19] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Хорошо, что этого не…>
Ну сложно сказать. Если бы столман тогда согласился, возможно бы мы сейчас имели более продвинутый единый компилятор, ибо усилия бы не распылялись
[11:23:37] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Ну сложно сказать. Е…>
Конкуренции бы не было. Ну нафиг
[11:24:10] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Тем не менее, фронт …>
Ну он условно отдирабелен. gimpl насколько я помню, до сих пор не выделен в отдельный хорошо задокументированный формат
[11:25:25] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Ну он условно отдира…>
«Хорошо задокументированный» это вообще не про gcc. Про любую его часть
[11:26:06] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Конкуренции бы не бы…>
Ох уж эти мифы про конкуренцию. Вот сейчас есть конкуренция среди сосисок. Они все хорошие и качественные стали? Или производители просто соревнуются, кто сможет ловчее нае... обмануть органолептические рецепторы покупателя за меньшую себестоимость? :)
[11:26:17] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <«Хорошо задокументир…>
Да и это тоже :)
[11:28:01] <ada_ru> (vasil_sd) отвечает (vasil_sd) на <Ох уж эти мифы про к…>
Как по мне, уж лучше иметь единый хороший модульный тулчейн, где все части хорошо совместимы друг с другом, чем зоопарк тулчейнов с разными проблемами совместимости и пр.
[11:29:32] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Ох уж эти мифы про к…>
Они были бы лучше если бы стоили как компиляторы для пользователей - 0 рублей
[11:30:42] <ada_ru> (I_vlxy_I) Тогда получать конкурентное преимущество понижая цену и качество не вышло бы
[11:31:39] <ada_ru> (shiz01) отвечает (vasil_sd) на <Как по мне, уж лучше…>
+
Очень грустно получается, когда пытаешься прикрутить фортран (gfortran in gcc) с сишечкой, собранной clang-ом. Ошибки линковки (что ld.bfd, что ld.lld) километровые...
[11:32:13] <ada_ru> (I_vlxy_I) отвечает (shiz01) на <+
Очень грустно полу…>
Используй ллвмный фортран
[11:32:19] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Они были бы лучше ес…>
Компиляторы для пользователей в общем случае не бесплатны. Пользователи их оплачивают косвенно. Посмотри, сколько корпорации контрибьютят в опен-сорс. Стоимость труда всё-равно так или иначе прекладывается в товары. Только за счёт опенсорса эти затраты шарятся между корпорациями и в целом для потребителя получаетя дешевле, но эти затраты всё-равно есть
[11:32:21] <ada_ru> (shiz01) отвечает (shiz01) на <+
Очень грустно полу…>
Ибо abi разное.
[11:32:26] <ada_ru> (I_vlxy_I) flang который
[11:32:32] <ada_ru> (shiz01) отвечает (I_vlxy_I) на <Используй ллвмный фо…>
Flang на 7.0 llv,
[11:32:41] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Используй ллвмный фо…>
А если его нет, или он ещё сырой? Пиши свой?
[11:33:50] <ada_ru> (shiz01) отвечает (vasil_sd) на <А если его нет, или …>
Во-во. Приходится отказываться от clang-зависимого кода :(
И переезжать на gcc+gfortran+ld.bfd.
[11:34:11] <ada_ru> (I_vlxy_I) отвечает (shiz01) на <+
Очень грустно полу…>
Кстати, а почему? Почему Си с Си стыкуется, а Си с фортраном - нет?
[11:34:23] <ada_ru> (I_vlxy_I) Какая-то фигня тут проскальзывает :-)
[11:34:30] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Кстати, а почему? По…>
Си и си тоже не всегда гладко стыкуются.
[11:34:41] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Си и си тоже не всег…>
Можно пример?
[11:34:58] <ada_ru> (shiz01) отвечает (I_vlxy_I) на <Кстати, а почему? По…>
https://t.me/adalang/63705
[11:35:26] <ada_ru> (I_vlxy_I) отвечает (shiz01) на <https://t.me/adalang…>
И? Почему с Си и Си это работает?
[11:35:38] <ada_ru> (I_vlxy_I) Фортран же может в Си
[11:36:05] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Можно пример?>
Детально сейчас не распишу, но много раз наступал на проблемы манглинга в плюсах, в сишнике что-то с линковкой было.
Линковка разных объектников - это сразу всё lto выкидываем и тд.
[11:36:13] <ada_ru> (shiz01) отвечает (I_vlxy_I) на <И? Почему с Си и Си …>
Хз, но на "веселых" проектах, с кучей асма, фортрана и С, ничем, кроме как gcc не собирается.
[11:36:25] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Детально сейчас не р…>
В плюсах - да. Но не в Си же
[11:36:48] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <В плюсах - да. Но не…>
С сишкой тоже есть проблемы, и чаще чем хотелось бы.
[11:37:24] <ada_ru> (vasil_sd) Во всяком случае, от lto сразу придётся отказаться. А дальше уже как повезёт
[11:37:38] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <С сишкой тоже есть п…>
Хочу проблему с Си
Я бы пощупал. Хочу пример
[11:38:13] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Во всяком случае, от…>
lto понятно. Там не объектники генерируются при LTO
[11:38:26] <ada_ru> (I_vlxy_I) И там нет машинного кода по факту
[11:38:33] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Хочу проблему с Си
…>
Да возьми два сишника, скомпилируй два объектника с поддержкой lto шлангом и гцц и попробуй слинковать...
[11:38:49] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Да возьми два сишник…>
Это не обсуждаемая проблема же
[11:39:17] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Это не обсуждаемая п…>
В смысле? Явная несовместимость форматов.
[11:39:21] <ada_ru> (I_vlxy_I) В этом случае там нечего линковать - там докомпиляция нужна
[11:39:46] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <В смысле? Явная несо…>
Не а форматах дело, а в содержимом
[11:39:57] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <В этом случае там не…>
В гццшных lto объектниках, если мне память не изменяет объектный код есть.
[11:40:33] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Не а форматах дело, …>
Ну да, в форматах IR засунутых в объектники, можно и так обозвать
[11:42:21] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Ну да, в форматах IR…>
А при LTO у gcc тоже не машкод в объектниках?
[11:42:41] <ada_ru> (vasil_sd) В общем, по факту тулчейны совместимы частично, с потерей части функционала.
Думаю этот очевидный факт в обосновании не нуждается?
А ещё фронтенды часто стандарты по-разному трактуют. В бытность работы в Интеле я столько этих граблей собрал, когда код нормально собираемый одним тулчейном не собирается другим.
[11:43:07] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <А при LTO у gcc тоже…>
Я уже не помню деталей, там по-моему и то и то
[11:44:36] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Я уже не помню детал…>
Надо глянуть детальней
[11:45:07] <ada_ru> (I_vlxy_I) Но давайте про случаи когда Си ABI реально сломан, а не про lto
[11:45:25] <ada_ru> (I_vlxy_I) Такие случаи реально важны
[11:46:24] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Но давайте про случа…>
Эти грабли я видел года 3-4 назад. Доступа к тому коду у меня нет, ибо проприетарный интеловский. Сейчас уже не смогу по памяти воспроизвести, да и тулы изменились
[11:48:02] <ada_ru> (vasil_sd) но разницу в трактовке стандартов языка - это постоянно ловил. Чаще, конечно на плюсовке причём на несложном CRTP даже. Но и на C99 тоже что-то с арифметикой длинной всплывало....
[11:48:56] <ada_ru> (vasil_sd) После Интела я с двумя тулчейнами одновременно уже не работал.
[11:49:25] <ada_ru> (I_vlxy_I) Проверил - при -flto clang просто выдаёт IR обычный. То есть там бек вообще не участвует. А вот gcc, скорее всего реально генерирует бинарь
[11:50:35] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <но разницу в трактов…>
Фронты разные, это понятно. У интела и ms (особенно) вообще своё понимание языков. И это норма. И это даже хорошо.
[11:50:38] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Проверил - при -flto…>
Насколько помню, gccшные lto объектники содержат просто допсекцию с IR. Но их можно и тупым не lto линкером слинковать, он просто те секции выбросит
[11:50:59] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Фронты разные, это п…>
Какое нафиг хорошо для стандарта языка?
[11:51:20] <ada_ru> (vasil_sd) Стандарт не просто же так пишут и утверждают....
[11:51:23] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Насколько помню, gcc…>
Вот похоже на правду, да. В llvm lto более радикально - оно объектники не генерит вовсе
[11:52:14] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Какое нафиг хорошо д…>
Для стандарта - особенно хорошо. Это значит, что не будет стандарта де-факто, как в Аде или питоне, следовательно сам стандарт будут писать и прорабатывать аккуратней
[11:53:17] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Для стандарта - особ…>
Где в Аде стандарт де-факто? Вроде там единый международный стандарт языка, причём весьма детально расписанный, с хорошим обоснованием, в отличии от.
[11:54:23] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Для стандарта - особ…>
И насчёт детальной проработки - что-то незаметно. Разные группы просто пытаются пропихнуть нужные им фичи, не сильно волнуясь за стандарт языка в целом....
[12:27:43] <ada_ru> (geniepro) отвечает (vasil_sd) на <Где в Аде стандарт д…>
ну, на данный момент нет компиляторов ады, на 100% сертифицированных на соответствие стандарту, а, поскольку, GNAT самый живой из всех трансляторов ады, то язык, реализованный в GNAT, и есть стандарт де-факто
[12:29:50] <ada_ru> (vasil_sd) отвечает (geniepro) на <ну, на данный момент…>
Насколько я помню, GNAT вроде следует стандарту, немного его опережая иногда предложенными расширениями. То есть не стандарт подгоняется под фичи компилятора.
[12:37:22] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Насколько я помню, G…>
Вспомни про перекомпиляцию при изменении боди дженерика :-)
[12:37:58] <ada_ru> (I_vlxy_I) Ну и по факту в гнат, по отзывам, многое из стандарта или не реализовано или сделано не так. Но заказчикам это и не нужно
[12:39:51] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Ну и по факту в гнат…>
Может быть. Я не настолько пока знаком с тонкостями GNAT.
Кроме дженериков больше особо никаких приблем не видел.
Да и насчёт порядка компиляции и зависимостей нужно детальнее посмотреть в стандарт, возможно это там оставили на откуп реализаций
[12:40:38] <ada_ru> (I_vlxy_I) Особенно это все касается новых стандартов (после Ады-95)
[12:41:05] <ada_ru> (I_vlxy_I) Оно и понятно - после 95 Ады гнат по сути зохавал рынок
[16:06:24] <ada_ru> (I_vlxy_I) Максим смотри какая статья https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part1.html
[16:06:30] <ada_ru> (I_vlxy_I) Перевод нужен?
[16:21:01] <ada_ru> (I_vlxy_I) Перевод 1 части https://m.habr.com/en/post/478168/
[16:21:17] <ada_ru> (I_vlxy_I) 2 части https://m.habr.com/en/post/489862/
[16:21:22] <ada_ru> (I_vlxy_I) Перевода 3 нет
[16:46:04] <ada_ru> (vasil_sd) А наиболее продвинутые решения - используют MPMC-очереди, которые почти без атомиков (там атомики амортизированы хорошо) и получается ещё круче чем горутины и другие зеленые потоки и асинхронщина
[16:46:41] <ada_ru> (vasil_sd) Только народ ленится нормально системы дизайнить с точки зрения data-flow и control-flow :(
[16:52:02] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Только народ ленится…>
А насколько это решение поменяет прикладной код? То есть заметит ли что-то прикладной программист если заменить горутины на это? Код надо будет переписать?
[17:39:27] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <А насколько это реше…>
Для использования такого типа очередей нужно дата-флоу в проге изначально так дизайнить. Но там и выигрыш получается очень ощутимый, ибо есть алгоритмы очередей которые динамически адаптируются к гетерогенной ccNUMA системе и атомиков практически не используют.
[17:40:18] <ada_ru> (vasil_sd) В многоядерных системах выигрыш может быть в разы, по сравнению с другими решениями
[17:43:25] <ada_ru> (vasil_sd) Вот например такой вариант: https://www.google.com/url?sa=t&source=web&rct=j&url=https://arxiv.org/abs/1908.04511&ved=2ahUKEwjh-_z_tu_nAhWllosKHY0WAeYQFjABegQIBBAB&usg=AOvVaw0rtFqQI0RmMxTnMLIWh5lD&cshid=1582727406582
[17:45:11] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Для использования та…>
Значит оно не универсально и использовать нельзя в Го. Для узких ниш - да
[17:47:36] <ada_ru> (vasil_sd) Там ниши не узкие, огромный класс задач можно эффективно переформулировать на mpmc очереди.
Просто народу лень это делать. Вообще архитектуру мало кто нормально продумывает, чаще кодят прямолинейные решения, которые сразу увидели.
[17:57:38] <ada_ru> (vasil_sd) Вон даже в растРастРАСТе есть оптимизированные mpmc очереди: https://docs.rs/crossbeam/0.7.3/crossbeam/
Не стали же они делать либу для узких ниш :)
[18:09:06] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Вон даже в растРастР…>
Это ж не стандартная либа
[19:18:07] <ada_ru> (I_vlxy_I) Кстати, о гимпе: https://www.linux.org.ru/news/multimedia/15547932
[19:43:51] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Кстати, о гимпе: htt…>
Да, гимп неплохо развивается. Лично для меня он очень удобен, там можно своего всякого понапрограммировать :)
[23:15:45] <ada_ru> (I_vlxy_I) https://blog.golang.org/go1.14
[23:15:51] <ada_ru> (I_vlxy_I) <прислал наклейку> 😳
[23:16:27] <nordwind> Раст? ;)
[23:16:46] <ada_ru> (I_vlxy_I) отвечает на <(nordwind) Раст? ;)>
Нет :-(
[23:16:50] <ada_ru> (vasil_sd) отвечает на <(nordwind) Раст? ;)>
Поддерживаю. А как же раст? :)
[23:17:19] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Поддерживаю. А как ж…>
Раст хорош для мемасов :-)
[23:19:50] <ada_ru> (I_vlxy_I) <прислал наклейку> 🎡
[23:19:56] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Раст хорош для мемас…>
Да ладно. Как замена сишнику тоже норм
[23:21:37] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Да ладно. Как замена…>
Сомнительно :-)
[23:22:39] <ada_ru> (I_vlxy_I) Но как немалый стимул для остальных плюсов и Ады - язык отличный
[23:22:59] <ada_ru> (I_vlxy_I) Заметил, что clang начал некоторые ub как ошибки компиляции выдавать
[23:23:05] <ada_ru> (I_vlxy_I) Раньше был варнинг
[23:23:14] <ada_ru> (I_vlxy_I) А гцц просто молчит :-)
[23:24:21] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Заметил, что clang н…>
это только приветствую
[23:24:49] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <А гцц просто молчит …>
Да, гцц в плане диагностики сейчас хуже шланга
[23:24:58] <ada_ru> (I_vlxy_I) Там и экспериментальный бранч с лайфтаймами есть для с++
[23:25:14] <ada_ru> (I_vlxy_I) Как в расте :-)
[23:25:31] <ada_ru> (I_vlxy_I) Лет через 8 может в язык втащат :-)
[23:25:53] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Там и эксперименталь…>
Сомневаюсь, что это в плюсах можно сделать нормально без потери совместимости с легаси
[23:26:37] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Сомневаюсь, что это …>
А что в плюсах делали нормально вообще? :-)
[23:26:38] <ada_ru> (I_vlxy_I) Сделают не нормально, а как обычно
[23:27:42] <ada_ru> (I_vlxy_I) В с++ все в едином узнаваемом стиле :-)
[23:27:52] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Сделают не нормально…>
Вот этого-то я и опасаюсь ;)
[23:29:11] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <В с++ все в едином у…>
Нужно в комиет закинуть идейку по использованию юникодных скобочек.
Это будет бомба :) Даёшь ещё 10 видов скобок, включая горизонтальные! :)
[23:31:30] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Нужно в комиет закин…>
Это скорее к расту :-)
[23:31:47] <ada_ru> (I_vlxy_I) У них же юзают вертикальные скобки :-)
[23:42:02] <ada_ru> (nitrocerber) Я дико прошу прощения, а чо, бывают горизонтальные скобки?
[23:42:41] <ada_ru> (vasil_sd) отвечает (nitrocerber) на <Я дико прошу прощени…>
Ага :) Кусочки для них есть в юникоде
[23:43:04] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <У них же юзают верти…>
Где? пока не видел....
[23:44:05] <ada_ru> (I_vlxy_I) отвечает (vasil_sd) на <Где? пока не видел..…>
|val| val + x
[23:44:13] <ada_ru> (I_vlxy_I) https://doc.rust-lang.org/rust-by-example/fn/closures.html
[23:44:53] <ada_ru> (I_vlxy_I) Растовый синтаксис многих пугает. Даже приплюсников. Но мне вроде норм
[23:45:07] <ada_ru> (vasil_sd) А не. Это они из smalltalka взяли.
В юникоде есть бооольшие вертикальные скобочки на много строк :)
[23:45:39] <ada_ru> (vasil_sd) отвечает (I_vlxy_I) на <Растовый синтаксис м…>
Да, с синтаксисом они промахнулись, на мой вкус
[23:45:47] <ada_ru> (I_vlxy_I) Но мне и erlang был норм :-)