Rust и двусвязный список

И что-то не видел я давненько рассказов о том, что вот на гото можно такого классного написать, оказалось что и ветвлений/циклов оказывается достаточно.

конечный автомат требует либо goto, либо языка/компилятора с хорошей поддержкой tail call elimination, который, по сути другая форма записи, но ПОЛНОЙ гарантии не дает; а еще возможно потребуются вычисляемые goto (кстати, они в расте есть?)

А не надо ждать правильного железа. Можно пойти к SiFive и заказать у них кастомных ядер RISC-V, снабдив их своими акселераторами. Да, акселераторы придется разрабатывать самим. Да, это специальный скилл, который еще нужно развить. Но, по крайней мере, есть техническая и организационная возможность.

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

С тех пор, как поняли, что VLIW на DRAM не работает, и продвинутым компилятором это исправлять бессмысленно. Суть OoOE в том, что это способ работы с задержками DRAM: выполняется та инструкция, для которой уже пришли данные из памяти

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

Да, они все равно не нулевые, а еще есть всякие там умножения-деления, которые долго выпоняются, особенно на вещественных числах — тут можно что-то заоптиизировать. Более того, в ARM возможно начать интерпретировать следующую инструкцию до интерпретации предыдущей — это не значит «выполнять», то есть, прямо-таки пытаться читать операнды, которые еще не готовы. Но какой-нибудь безусловный прыжок от операндов не зависит, например. Даже для условных прыжков ARM может прогрузить в конвееры обе ветки — это всё еще не выполнение инструкций (это упомянутая суперскалярность).

То есть, пространства для оптимизаций на армах было достаточно без внеочередного выполнения — потому я и возражал по поводу «кремний нужен был на OoOE». У Alpha не было внеочередного выполнения, а она укатывала x86 в хламину. Правда, там были такие волшебные штуки, из-за которых в ядре линя до сих пор есть макросы READ_ONE/WRITE_ONCE — поскольку на альфе зависящие операнды, как то указатель и значение по этому указателю, могли приходить в произвольном порядке, из-за чего возможно было прочитать значение по указателю до чтения этого указателя — причем, это даже звучит как внеочередное выполнение, но на самом деле это поочередное выполнение, но на разных кэшах, которые видят изменения памяти в произвольном порядке.

Cortex A53/55 — не OoOE (или OoOE, но «лишь чуть-чуть»). Суперскалярность не значит OoOE

Причем, первые RISC процессоры конца 80-х уже были суперскалярными — именно за счет этого они уделывали всякие i386 того времени.

там ты еще много интересного написал, но меня больше интересует, почему ты придаешь такую важность горячей загрузке кода? где она реально полезна? обычно же всегда можно сделать рестарт (причем иногда умный, как nginx), а стейт держать во внешней БД

Что такое «горячая загрузка кода»? Это поменять функцию без перезапуска? Тогда ты не на то сообщение отвечал. Полезна она при отладке. Впрочем, как и быстрая компиляция вообще — еще один бич Rust-а. Если рестарт делается за полсекунды, то необходимость в горячем обновлении кода становится намного меньше. Но не исчезает полностью.

Не нужны тебе объекты, разделяемые между потоками.

собственно, это и есть основная претензия к расту: вот такой ВЕСЬ раст и растоманы: «сегодня в колбасе потребности нет!»

и следующие отсюда постоянные детсадовские идеи «ПОЭТОМУ сделайте граф на массиве» — хотя САМА ПО СЕБЕ идея графа на массиве может быть нормальна

конечный автомат требует либо goto, либо языка/компилятора с хорошей поддержкой tail call elimination

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

Хочется использовать систему доказательств раста для работы с графом? Тогда определи граф как объект владеющий данными. Реши как будет храниться порядок элементов. И реши вопрос как будет происходить заимствование данных из графа (например, через итератор/курсор с указанием времени жизни не превосходящим времени жизни самого графа).

Кто-нибудь это уже сделал? То есть вот так аккуратно написал, хорошо отдокументировал? Окружающие опробовали и выяснили, что такой реализацией можно пользоваться без боли? Или это разговор в стиле «МОЖНО СДЕЛАТЬ!11!11!!!!11»?

Это требует чуть больше кода? Ну так естественно, т.к. этот код будет содержать утверждения для системы доказательства корректного заимствования данных.

нет, не естественно

Даже когда ты все узкие места иерархии памяти разошьешь, останется проблема недетерминированных задержек и параллелизма DRAM. OoOE — это архитектура, которая позволяет динамически подстраиваться под темп работы DRAM. Она неизбежна там, где количество ядер меньше, чем степень параллелизма памяти. В противном случае (например, сотни и тысячи мелких ядер), лучше работает In-order.

Есть же свитчи на бинарном поиске

если ты хранишь состояние автомата не в переменной, а в instruction pointer процессора, то switch тебе не годится

Можно пойти к SiFive и заказать у них кастомных ядер RISC-V, снабдив их своими акселераторами.

Я щас не понял, вы предлагаете условным разработчикам условных apache, nginx, sqlite, photoshop или msoffice пойти к производителям железа и заказать что чтобы что?

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

А что на неё обращать внимания? Эвфемизм - это форма. По сути желание обзываться у тебя не пропало, значит, этику не освоил.

останется проблема недетерминированных задержек и параллелизма DRAM.

Не соблаговолите ссылочками поделиться? А то что-то оно пока не очень укладывается в моё мировосприятие, особенно в части параллелизма DRAM.

В Аде же вроде есть параметрические модули, это аналог шаблонов.

Это требует чуть больше кода? Ну так естественно, т.к. этот код будет содержать утверждения для системы доказательства корректного заимствования данных.

нет, не естественно

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

Правильна ли сделка в случае Раста, не переплатили ли за надёжность цену? Не упала ли надёжность из-за усложнения кода? Вот тут ответ пока неясен.

Ссылочками на что? На то, что у нас OoOE вместо VLIW сейчас?

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

И работать потом только на специфическом железе, а не там, где только можно?

Дико звучит, да?

Вы даже не представляете насколько.

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

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

почему ты придаешь такую важность горячей загрузке кода? где она реально полезна? обычно же всегда можно сделать рестарт (причем иногда умный, как nginx), а стейт держать во внешней БД

А почему состояние держат во внешней БД? Во многом - по той причине, что там как раз есть alter table, т.е. горячая модификация типов данных. Т.е. твое решение по отказу от горячей загрузке кода на самом деле лишь переносит эту загрузку кода в другое место.

Ну, как сказать. Всё это вполне укладывается в экономически оправданную сейчас облачную парадигму. Я заказываю кастомное железо, за счет него получаю дополнительные гарантии при снижении издержек на разработку, что и продаю своим клиентам в облаке. Раньше так делать было нельзя. Сейчас — можно.

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

Не совершенно аналогично.

По сути желание обзываться у тебя не пропало, значит, этику не освоил.

Обзывание – это попытка оскорбить собеседника и перевести разговор в русло оскорблений.

Я (и не только я) использовали здесь слово «идиот» для объяснения зияющих дыр в логических построениях byko3y. Потому что высказывания byko3y заставляют усомниться в его способности здраво мыслить. По меньшей мере в способности связно доносить свои мысли. Не уровень царя, конечно, но далековато от нормы, имхо.

и то чот я не вижу ОС на Rust.

Плохо смотришь. Ну или ты забыл уточнить, что хочешь не просто ось на расте, а чтобы тебе линукс на него переписали.

Использование слова «идиот» по отношению к человеку не приветствуется правилами форума. А ты по дороге на машине по встречке обычно ездишь?

А кстати, какие годные ОС есть на Расте? Тема прямо интересная.

Пока у тебя в коде хотя бы один unsafe — это не safe программа

Ну то есть, «сейф программ» в принципе не существует. Ведь «пока у тебя виртуальная машина (хотя бы частично) написана на С…» или «пока у тебя железо не гарантирует отсутствие отказов…» и прочее бла-бла-бла. Впрочем, этот аргумент я у тебя видел уже много раз, ничего нового: довести до абсурда, заболтать и свалить в итоге на абстрактных менеджеров, которые никогда не дают сделать нормально.

А я напоминаю для тех, кто кроме C++ и Rust ничего не видел,\

Напомню и я, что byko3y С++ толком не знает, а про раст ему вообще Рабинович напел.

Теперь сделайте норм ЯП,

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

OoOE — это архитектура, которая позволяет динамически подстраиваться под темп работы DRAM. Она неизбежна там, где количество ядер меньше, чем степень параллелизма памяти

Дело не в степени параллелизма памяти, а в задержке. Сотням тыщ ядер это не нужно, потому что подождут. Внеочередное выполнение — это, как ты правильно написал, асинхронность, то есть, один поток ждет завершения нескольких операций. Если ты, грубо говоря, читаешь память с удаленной машины по HTTP, то ты можешь отправить несколько запросов одним потоком, а ответы будут приходить другим потоком — это лишь воображаемый параллелизм, на самом деле запросы и ответы идут строго последовательно, но задержка у них большая. А всё IT слишком долго пыталось сделать вид, будто доступ ко всем хранилищам происходит мгновенно и атомарно — и вот теперь упёрлось в глухую стену.

Так что им помешало сделать иммутабельные хеш-таблицы?

А разве не сделали? Разве Data.Map не иммутабельная?..

если ты хранишь состояние автомата не в переменной, а в instruction pointer процессора, то switch тебе не годится

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

Разве Data.Map не иммутабельная?..

Я не знаток Хаскеля. Но Data.Map вроде на деревьях построена. Мне сложно понять, что означает

Ord k => Monoid (Map k v)

В Аде же вроде есть параметрические модули, это аналог шаблонов

Важно не то, что там на самом деле есть или нет, а то, что этого «чего-то» сильно меньше, чем в C++, но при этом язык получается таким же сложным, как C++. И что эту ошибку снова повторяет Rust, и что реузльтат будет тот же: громкий язык, который форсится в официальных кругах, а по итогу индустрия посмотрит на него, посмотрит, подумает-подумает, и пойдет писать на Go, потому что сильно проще, итоговая надежность программы та же, а разницы в производительности не заметно.

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

Не совсем книга, но вот: http://www.willamette.edu/~fruehr/haskell/evolution.html

Напомню и я, что byko3y С++ толком не знает

Для меня это говорит в его пользу - т.к. здравомыслящий человек с чуством прекрасного быстро постарается найти место подальше от С++. В частности, если бы С++ был бы достоин познания и решал бы все нужные задачи, то не было бы ни Java, ни Go, ни Rust.

Правильна ли сделка в случае Раста, не переплатили ли за надёжность цену? Не упала ли надёжность из-за усложнения кода? Вот тут ответ пока неясен

С самого начала треда я писал, что Rust не дает никакой надежности. Он заставляет тебя исправлять некорректную работу с памятью, делать ты это будешь руками, то есть, тратить на это время, а логику он не проверяет, от слова «совсем». Что тут еще несного?

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

Мой главный аргумент: вы для кого/чего вообще язык сделали? Для написания одного браузера? Это сомнительная цель разработки ЯП.

большее разнообразие битовых операций

Оператор «ойвсё» и «исключающее штоле».

Ну или ты забыл уточнить, что хочешь не просто ось на расте, а чтобы тебе линукс на него переписали

Да, желательно что-то большее, чем hello world. Пока что в основном под Rust пишут школьные поделки и просто обертки к сишным либам.

Мощно!

хорошая читаемость вот вам хер вместо вывода типов

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

Для написания одного браузера? Это сомнительная цель разработки ЯП.

Если ЯП намного меньше браузера (по совокупной стоимости владения), то нормальная цель. Современные браузеры - порядка 7 млн строк кода. Вполне можно написать ЯП, в котором будет менее 700 тыс.

ну вообще естественно, что надёжный код больше по размеру

и это тоже не естественно

современные программисты ничего слаще морковки не видели, вот так и думают

А почему состояние держат во внешней БД? Во многом - по той причине, что там как раз есть alter table, т.е. горячая модификация типов данных. Т.е. твое решение по отказу от горячей загрузке кода на самом деле лишь переносит эту загрузку кода в другое место.

Все это тема для отдельного интересного разговора. Но вот пара мыслей:

1. хранить стейт в образе (как это принято у лиспов насколько я знаю) — плохая идея; предположим, на помощь Пете Васькину выделен Вася Петькин — и что делать? а в БД все готово к совместной работе

еще вопрос в ту же тему: если образ переходит от Пети к Васе, то там наверно дофига всяких удобств, которые Пете позарез нужны, а Васе незнакомы или хуже того противны; их ведь так легко не вырезать наверно?

2. из недостатков БД: в современных ЯП для выкидывания объектов в БД нужно сделать много лишних телодвижений; если это исправить, то никто в сторону образа видимо даже и смотреть не станет

и это тоже не естественно

При прочих равных

современные программисты ничего слаще морковки не видели, вот так и думают

Ну давай свою капустку.

Ну то есть, «сейф программ» в принципе не существует.

существуют (например, если они формально верифицированы); причем это не только экзотика типа ядра L4

1. хранить стейт в образе (как это принято у лиспов насколько я знаю)

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

из недостатков БД: в современных ЯП для выкидывания объектов в БД нужно сделать много лишних телодвижений;

На фоне того же раста, где для любого alter table/alter procedure нужно грохнуть всю БД целиком, это в любом случае ангельские крылья в голубом небе.

А кстати, какие годные ОС есть на Расте? Тема прямо интересная.

Смотря, что вкладывает в понятие «годные». Очевидно, что ничего уровня линукса, макоси или винды нет, иначе ты об этом знал бы. Часто вспоминают Redox, вроде как, в теме тоже упоминали, но по моему это скорее исследовательский проект. Остальные «фанатские» и того хуже.

Из специализированных есть, например, Bottlerocket. Вполне себе используется в продакшене. Гугл свою фуксию тоже пишет частично на расте, правда не ядро.

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

Я не знаток Хаскеля.

Я тоже, но инсерты, вроде как, возвращают новый инстанс, а не модифицируют.

Ну они могли бы и хеш таблицы, наверное, как-то так сделать, но они засунули их в io. Зачем так сделано, я не знаю, но это сделано.

Из специализированных есть, например, Bottlerocket.

Не очень ясно, как она написана на Расте и в то же время Linux-based. Это какая-то примочка?