В с++ это невыразимо. Есть предложение сделать дестрактив мув, но там все сложно и с учётом пандемии я лично считаю что раньше с++3х это не случится. В комитете не считают это проблемой которую целесообразно фиксить в языке и перекладывают это на статические анализаторы.
Ответ довольно таки однозначен, но также очевидно вы либо не знакомы с с/с++ либо не считаете это проблемой. В с/с++ (а может и в других языках тоже) строка message; гарантированно НИЧЕГО не делает и будет удалена компилятором тогда как в расте это скрытый дроп. Вот разница в ожидаемом поведение и реальностью и есть проблема. Так уж случилось что с/с++ появились существенно раньше раста и сформировали семантику ожидаемого поведения для тех кто знакомиться с растом и имеет сишный опыт. Появись раст раньше си тогда бы сишное поведение вызывало заслуженный вопрос — чё за нах.
Да, это блять местный "английский". На самом деле это маорийский. Язык маори использует английский алфавит, но самая жопа это что новозеландские официальные/государственные и не только учреждения смешивают в одном тексте православный английский и вот эту поебень настолько густо и часто что порой нихера не понять, но так плохо бывает довольно редко. Мне пока чаще всего такое встречается в письмах из детсада где на маорийском обращаются к родителям и в целом терпимо и понятно, но бесит шо пипец. Из того что здесь написано я знаю только последнее слово — самоназвание НЗ на маорийском, что переводится на человеческий как — страна длинного облака.
А как на счёт обработки ошибок? Я как то год назад написал кастомный стрим на mmap, а потом на ревью был справедливо закидан помидорами(ссылками на майллисты и статьи) где куча людей обоснованно доносили, что как только у вас есть две и более библиотеки(в одном процессе) которые что то mmapят и подходят к этому ответственно с обработкой ошибок, то у вас не просто УБ, а отдельный котел в аду под названием глобальный обработчик сигналов, который впринципе "правильно" не приготовить. Я к тому что ммап можно использовать безопасно, но только когда есть только одна библиотека, а это почти наверняка не вариант для большого проекта с длинной историей и который использует сразу много больших библиотек. Например культю и буст и тогда готовьтесь к увлекательному дебагу. Ну и как обычно в таких статьях описан самый простой хэпи пас, но хотя бы самую простую ситуацию разберите — читаете из замапленного файла с усб диска, а пользователь, вопреки всем сообщениям ОС, сука такая взял и выдернул флеху и что будет при использовании этой либы? Вариант чуть посложнее — как добавить данные в конец файла? А что если свободного места вдруг не стало, ну например другой процесс записал что то на диск. Тут же все ленивое и преподносится типа как безусловно лучше чем не ленивое. В общем мне как написавшему свой полностью работоспособный стрим и юнит тесты и все такое, а потом выкинувшему все к хренам по причине невозможности правильной работы с ошибками очевидно что статья — не зачёт, даже 10% всей мякотки не раскрывает.
А есть ли вероятность что некоторые страны могут заставить такой межспутниковый трафик идти через свой собственный спутник(и) или спутник маска но сертифицированный кем надо где и будет установлен сорм или это бессмысленно/не гарантирует контроль над трафиком? Так то межспутниковпя связь решает много насущных проблем и что то мне не верится что прагматизм не победит хотя бы в некоторых странах. Если уж ставить сервер для эффективной утилизации канала, то не такая уж и большая дополнительная работа добавить ещё и сорм. Даже если такая идея тупиковая думаю инженеры найдут другой способ при соответствующем стимуле.
Статья конечно куцая, но все равно спасибо. Мне на моей работе будет крайне полезна (если подойдёт) т.к. миграции у нас почти всегда с багами получаются из за минимализма скулайта и естественно очень прямых рук.
Я не очень продвинутый телепат, так что давайти я придумаю за вас с чем вы не согласны и отвечу.
Наверное мой предыдущий ответ не лучшим спосособом доносит такую мысль:
* Общепринято с помощью машины Тьюринга моделировать ЧИСТЫЕ функции — алогритмы с предоставленным входом, для например анализа алгоритмической сложности. Такое моедилирование и анализ не вызывают ни у кого никаких проблем. И я думаю вы наставиаете, что это и есть то единтсвенное на что способна модель машины Тьюринга.
* В таких чистых функциях, любое зацикливание означает некорректность алогритма.
* Реальные/полезные программы не чистые — имеют побочные эффекты (ввод/вывод), а в терминах машины тьюрига, любой побочный эффект моделируется зацикливанием и поэтому не отличим от некорретного алгоритма.
* Реальные компьютеры — детерминированны (ГПСЧ — детерминирован), а любое истинно недетерминированное поведение невозможно БЕЗ ввода/вывода.
* Чтобы избежать проблемы неразличения причины зацикливания (некорретность или ввод) и происходит разбиение реальной программы на подпрограммы двух типов.
* Чистые, что означает они ничего не ожидают/нет в(ы)вода/побочных эффектов и поэтому их зацикливание == некорректность
* Менеджер — исключительно ожидает ввод/вывод и поэтому его зацикливание не является признаком некорректности.
Любой кто писал корректный сложный локфри код делал это же самое разбиение на участки и затем анализировал свой алгоритм на коретность с учетом гарантий модели памяти в его языке. Так что да, анализ (не очень больших, сложных, многопоточных) программ возможен чисто технически вот прям дюбом квалифициованным инженром. Да делать это для всей программы не представляется практически возможным без автоматизации. Какие нибудь агды или идрисы могут помочь. Схема такая — разбиваете вашу программу на части описанные выше, учитываете гарантии предоставляемые вашим железом и компилятором, а дальше полный перебор (с учетом ограничений вытекающих из гарантий) всех состояий вашей программы (возможного ввода/вывода) и доказательство или опровержение корректности (зацикливание) вашей программы. Т.е. техническая проблема как раз с той частью программы которая — менеджер, проверка всех возможных входных данных (с учетом ограничений) и является ресурсоемкой на практике, но не является принципиальной/теоретической проблемой.
Ну и то что я все это время пытаюсь донести — зацикливание != некорретность в общем случае для реальных програм. И даже наоборот, я могу специально написать тест который будет проверять, что программа ДОЛЖНА зациклиться/ожидать ввод, т.к. это поведение является частью спецификации и следовательно корректным. И для моделирования такого поведние/тестирования мне нужен оракул который скажет, что программа зациклилась/ожидает ввод.
Насколько мне известно уже идет реальная работа в этом направлении называется верификация программ, да сложно и не всегда возможно полное доказательство на практике из за ограниченности ресурсов, но в ТЕОРИИ/ФУНДАМЕТНАЛЬНО полностю разрешимая проблема, т.к. реальный компьютер НЕ способен выполнить ЛЮБУЮ программу. Думаю что для кого нибудь 8086 процессора (с учетом всех его ограничений на доступную память) уже возможно на практике верефицировать/доказать корректность ЛЮБОЙ программы которую можно на нем запустить только это не практично т.к веротяно затребует мощности самых передовых суперкомпьютеров для анализа, что бы выполнить его в разумное время.
Вы вероятно забыли про факт того что ВСЕ дохулион ядер конкурентно пишущих по одному и ТОМУ же адресу будут сериализованны шинной памяти, многоканальность она про одновременный доступ по РАЗНЫМ адресам. Следовательно что моноядерник что дохулион ядерник это тоже самое — машина Тьюринга.
DMA меняет состояние памяти в обход исполнителя
Ну так об это и шла речь — это и есть ввод/вывод и моделируется он прекрасно = зацикливанием и переписыванием ленты.
А по другому никак, иначе придётся моделировать человека, который собственно вводит.
Да нет, не нужно никого моделировать. Что делает программа ожидающая ввод? Висит. Поэтому если мы моделируем ввод то программа ОБЯЗАННА повесить машину Тьюринга. Если мы ввод не хотим моделировать, то да можно записать данные на ленту заранее.
Вам же mayorvp вверху почти правильно написал как это моделируется:
* Программа разбивается на подпрограммы которые ничего не ожидают — привет фп чистые функции.
* В модель вводится програма «менеджер» которая запускает подрограммы и ЗАЦИКЛИВАЕТСЯ на момент ввода вывода.
Так что еще разок — вся инженерная/программисткая сложность современных компьютеров принципиально/фундаментально/теоретически ни как не отличается от машины Тьюринга и прекрасно ею моделируется. А модель из 2 пунктов вверху это вобщем то описание того как компилятор фп языка подходит к проблеме чистых не чистых функций и позволяет ФП программистам писать не упражнения в математику, а нормальные полезные программы.
Кеши, ядра, дма, и т.д. никак не влияет, это все просто оптимизации не дающие ничего принципиально отличного от машины Тьюринга, и следовательно никак не отображаются на модель.
Моделирование программы которая ждёт ввода с записанным на ленту вводом это не моделирование, точнее это моделирование другой программы. И мы все такие программы не раз писали называются они тесты.
Ещё раз — ожидание ввода это неостанов для машины Тьюринга и никак иначе. С выводом чуть сложнее т.к. лента у Тьюринга бесконечная то и блокировок не бывает, т.е. ожидание вывода моделируется наложением искусственного для Тьюринга ограничения на размер ленты(не насаму ленту, а на количество ячеек используемых программой через входной параметр) и тоже зацикливание.
Ну и на последок, если бы машина Тьюринга не могла моделировать реальные программы, то это было бы просто не более чем занятное упражнение в математику не имеющее инженерную ценность. Но это далеко не так. Машина Тьюринга это модель не простейшего вычислителя (хотя я думаю имелось ввиду инженерная сложность а не теоретическая), а самого мощного того который может вычислить все что вообще возможно вычислить. А т.к. компьютер не более чем калькулятор и МЕНЕЕ способный чем машина Тьюринга, то утверждение что компьютер и ЛЮБАЯ программа не может быть представлены машиной Тьюринга это ложное утверждение.
Я что здесь, не понял. Программа такая есть, а машиной Тьюринга она смоделированна быть не может? Я может быть не прав, но вроде подразумевается, что компьютер это машина Тьюринга да ещё и с конечной лентой разве нет? А если нет, то в чем практическая польза машины Тьюринга если она не применима к реальным программам? Если машина Тьюринга не может описать реальную программу, то и никакие выводы основанные на рассуждениях с машиной не применимы к реальным программам. Получается пчелы против меда, компьютер не может быть описан математически, какой то это абсурд или магия.
Если мне не кажется, то состояние ожидание ввода вывода это и есть не останов/зацикливание машины Тьюринга. При этом факт ввода это изменение состояния ленты НЕ машиной Тьюринга — извне, но при этом это изменение может прервать бесконечный цикл и завершить программу. Т.е. по какой угодно логике, ваш оракул должен выдать программа не завершается (сама по себе с заданной лентой, что как бы подразумевается).
and memmove() simply just checks whether the destination address is above the source address and decides to copy backwards if so
Знаете ли я тоже имею некоторое представление о сложности этого «simply just checks», т.к. задавался конкретно этим вопросом. Я не сишник и сишный стандарт как отче наш на знаю, но вот в мире с++ это нифига не простая проверка и думаю си здесь не отличается от с++. Если интересно за подробностями сюда
Так что, то что пишет Линус о том, что это чушь это он мегко говоря не прав в общем случае. Конечно, на тех платформах с которыми он привык работать наверное это действительно просто, но не на всех.
Т.е. то что он предлагал — вернуть назад простую наивную реализацию, которая также еще и оверлапинг проверяла, нормальное предложение, но оно по очевидным для меня причинам (не работает в общем случае) было отвергнуто. То что он назвал граничными случаями наверное(код не смотрел) и есть учет разных экзотических платформ — реализация общего случая корректным образом.
Еще раз перевожу с Линксвого языка на человеческий — я вертел вашу корретность в общем случае, ваша реализция поламала код который нормально работал для пользователей моего продукта, так шо давай те вашу корректность засуним куда подальше и поможем нашим пользователям. Нормальный, здравый подход защищать свой продукт и продавливать решения которые позволяют избежать работы. Я бы тоже такую дичь говорил если бы был заинтересованной (в таком решении) стороной.
Нет, спасибо, не надо, пусть лучше будет впервую очередь коректно и во второую максимально быстро, а за дополнительными плюшками идите в memmov.
Спасибо. Я не особо знаток Линуса как человека, но похоже на какой-то плач обиженной девчонки. Кому надо тот пусть и фиксит (причем довольно просто) свой код следуя как раз неплохому предложению Линуса — в своем коде пусть и заводят макросню алиасищаю memcpy на memmov, а мне пожалуйста оставьте код который работает с УБ и по стандарту (да тому который он применяет по «назначению»), но хотя бы потенциально быстрее.
Мне кажется, решение недостаточно кардинальное. Смотрите сейчас календарь реализует 2 естественных цикла (годовой и суточный) и ещё несколько искусственных (месяцы, недели, часы, минуты) в виде даты (годовой цикл) и времени (суточный цикл). И в таком простом виде календарь работал очень долго, это потом выяснилось, что все немного сложнее и люди привели много разных календарей к единому отсчёту пофиксили саму систему подсчёта добавив высокомные дни и секунды — проблемы годичного цикла, и наконец решили последнюю проблему часовые зоны — суточный цикл. По факту базовая идея календаря оказалось очень удачной т.к. пережила тысячелетия и многократно допиливалась не меняя своей сути. Отказ от часовых поясов, но с сохранением остального наследия — это очевидный регресс. Вы предлагаете устранить уровень абстракции, который надежно, удобно и эффективно решает много задач, только лишь во благо упрощения реализации частной задачи — цифрового представления времени. Это как предложить забанить днс адреса глубже ну например 2го уровня.
Решение проблемы календаря в цифровом виде уже давно существует — timestamp. Никакой неоднозначности, никаких циклов. Проблема в том, что люди не умеют, не хотят и обоснованно недоумевают от идеи использовать штампы в повседневной жизни. Штамп это как в6 айпишник, отличное решение для машин и совершенно непригодное для людей. Поэтому проблема которую вы пытаетесь решить технически не является технической, система временных зон отличная идея и технически она решена. Все сложности цифрового представления из за еб… тых политиков, и решение этой проблемы лежит в области онигиляции корня проблемы, а не костылевания техническими средствами.
Ещё раз надо либо прошивку у всех человеков поменять чтобы мы напрямую в штампы умели или выпилить несколько особо одаренных которые портят жизнь всем остальным — это надёжные и логичные решения, а то что вы предлагаете какая то херня.
Люди сошли с ума и пытаются решать не ТЕ проблемы. Вместо того чтобы спорить кто кого чаще убивает, надо решать проблему оружия — и я не про запрет, а про эффективное НЕ смертельное оружие. Цель должна быть не убить преступника, а просто обезвредить, но это сложно. Проще убить, а потом всем миром ныть шо негров оказывается убивают чаще.Я за владение эффективным не смертельным оружием и против владения смертельным.
А вот самое интересное — адаптер FuncPassManager в ModulePassManager не показан. Я так предполагаю, что там модуль представляется как коллекция функций и для каждой вызывается все что добавленно в функциональный пасс менеджер? Честно Шон очень клёвый, но он не единственный кто до этой идеи дошёл. Впервые я это увидел (не сам додумался) почти 20 лет назад когда из всего с++ мира только про страуса знал и то по книгам. уверен что и раньше это тоже было известно. С тех пор разве что мув добавился для производительности, но и без него на указателях по сути также все и работало.
Я тестирую ваш мобильный браузер с самой первой беты. И с самого начала есть проблема которая так никуда и не ушла. Вивальди на Андроиде УЖАСНО тормозит. Конкретно скрол любой страницы дергается. Уже все чего мне не хватало есть темный режим и реклама резка, но вот это дёрганье никак не может победить лису с тем же функционалом. Пожалуйста пофиксите дёрганье при скроле это блокер. Телефон 8 гигов памяти дракон 855 т.е. точно дело не в железе лиса просто летает.
Да вобщем то ничего не мешает. Только без колег значит в одиночку значит какой-то мало кому нужный опен соурс в ваше свободное время. На работах за последние 10 лет не было ни разу случая что нужно что то писать с нуля. Это всегда уже существующий и как то работающий код который нужно расширить/пофиксить. Мест работ и стран и профилей компаний много разных но это ни на что не влияет. Ситуация где у вас на работе нет/мало колег и нужно писать новый код == вы в самом начале стартапа или совершенно новый проект, по какой то неведомой мне причине это значит что вы и 1,5 других колег джуниоры и вам все это ещё неизвестно или нет времени на эксперименты. Может быть потому что стартапы не могут предложить денег/интерес для более опытных девелоперов, а свой стартап опытные девелоперы почему то не спешат начинать. Вобщем такое возможно, но мне не довелось поучаствовать.
Все это очень хорошо в теории. Я так попытался писать на плюсах в реальном проекте, только настоящая проблема этого подхода не в том что система типов слаба (а она на самом деле слаба) а в коллегах, которые с полным недоумением спрашивают, а нахрена это все? И у них есть непрошибаемый козырь писать так объективно сложнее, а читать неподготовленному мозгу такое вообще противопоказанно. С легаси несовместимо категорически, т.к. требует неимоверных усилий по рефакторингу и как обычно в условиях отсутствия тестов и времени под давлением типа давай результат вчера и погуще. Так что в реальном мире мне пришлось согласиться с мертворожденностью этого подхода. Пока мне приходится героически преодолевать ограничения системы типов и костность мозгов это никогда не выйдет дальше вот таких статей. Мозги нужно учить лучшему в вузе, а этого там не рассказывают. Человек валидировал десятки лет и по его словам успешно ( с точки зрения формальных критериев: закрытые таски, вовремя сделанные релизы), это значит вы никогда не сможете убедить его работать больше чем прежде для достижения того же результата. Обещанию меньшего количества багов НИКТО не верит, а увидеть логику почему это так не может в силу скудоумия/костности. Пробовать отказываются не понимая зачем им это надо. Компилятор тоже вам вставит палки в колеса везде где только возможно, т.к. уже давно в тренде требовать от программиста выражать свои намерения максимально явно, а это в свою очередь вызывает необходимость писать много бойлерплэйт кода в парадигме парсинга. Так что я вам категорически не советую даже пробовать такое в реальных проектах на плюсах, идею не оценят, и сделают все от них возможное чтобы вы отказались от этой идеи и по скорее.
В с++ это невыразимо. Есть предложение сделать дестрактив мув, но там все сложно и с учётом пандемии я лично считаю что раньше с++3х это не случится. В комитете не считают это проблемой которую целесообразно фиксить в языке и перекладывают это на статические анализаторы.
Ответ довольно таки однозначен, но также очевидно вы либо не знакомы с с/с++ либо не считаете это проблемой. В с/с++ (а может и в других языках тоже) строка message; гарантированно НИЧЕГО не делает и будет удалена компилятором тогда как в расте это скрытый дроп. Вот разница в ожидаемом поведение и реальностью и есть проблема. Так уж случилось что с/с++ появились существенно раньше раста и сформировали семантику ожидаемого поведения для тех кто знакомиться с растом и имеет сишный опыт. Появись раст раньше си тогда бы сишное поведение вызывало заслуженный вопрос — чё за нах.
Да, это блять местный "английский". На самом деле это маорийский. Язык маори использует английский алфавит, но самая жопа это что новозеландские официальные/государственные и не только учреждения смешивают в одном тексте православный английский и вот эту поебень настолько густо и часто что порой нихера не понять, но так плохо бывает довольно редко. Мне пока чаще всего такое встречается в письмах из детсада где на маорийском обращаются к родителям и в целом терпимо и понятно, но бесит шо пипец. Из того что здесь написано я знаю только последнее слово — самоназвание НЗ на маорийском, что переводится на человеческий как — страна длинного облака.
А как на счёт обработки ошибок? Я как то год назад написал кастомный стрим на mmap, а потом на ревью был справедливо закидан помидорами(ссылками на майллисты и статьи) где куча людей обоснованно доносили, что как только у вас есть две и более библиотеки(в одном процессе) которые что то mmapят и подходят к этому ответственно с обработкой ошибок, то у вас не просто УБ, а отдельный котел в аду под названием глобальный обработчик сигналов, который впринципе "правильно" не приготовить. Я к тому что ммап можно использовать безопасно, но только когда есть только одна библиотека, а это почти наверняка не вариант для большого проекта с длинной историей и который использует сразу много больших библиотек. Например культю и буст и тогда готовьтесь к увлекательному дебагу. Ну и как обычно в таких статьях описан самый простой хэпи пас, но хотя бы самую простую ситуацию разберите — читаете из замапленного файла с усб диска, а пользователь, вопреки всем сообщениям ОС, сука такая взял и выдернул флеху и что будет при использовании этой либы? Вариант чуть посложнее — как добавить данные в конец файла? А что если свободного места вдруг не стало, ну например другой процесс записал что то на диск. Тут же все ленивое и преподносится типа как безусловно лучше чем не ленивое. В общем мне как написавшему свой полностью работоспособный стрим и юнит тесты и все такое, а потом выкинувшему все к хренам по причине невозможности правильной работы с ошибками очевидно что статья — не зачёт, даже 10% всей мякотки не раскрывает.
А есть ли вероятность что некоторые страны могут заставить такой межспутниковый трафик идти через свой собственный спутник(и) или спутник маска но сертифицированный кем надо где и будет установлен сорм или это бессмысленно/не гарантирует контроль над трафиком? Так то межспутниковпя связь решает много насущных проблем и что то мне не верится что прагматизм не победит хотя бы в некоторых странах. Если уж ставить сервер для эффективной утилизации канала, то не такая уж и большая дополнительная работа добавить ещё и сорм. Даже если такая идея тупиковая думаю инженеры найдут другой способ при соответствующем стимуле.
Статья конечно куцая, но все равно спасибо. Мне на моей работе будет крайне полезна (если подойдёт) т.к. миграции у нас почти всегда с багами получаются из за минимализма скулайта и естественно очень прямых рук.
Наверное мой предыдущий ответ не лучшим спосособом доносит такую мысль:
* Общепринято с помощью машины Тьюринга моделировать ЧИСТЫЕ функции — алогритмы с предоставленным входом, для например анализа алгоритмической сложности. Такое моедилирование и анализ не вызывают ни у кого никаких проблем. И я думаю вы наставиаете, что это и есть то единтсвенное на что способна модель машины Тьюринга.
* В таких чистых функциях, любое зацикливание означает некорректность алогритма.
* Реальные/полезные программы не чистые — имеют побочные эффекты (ввод/вывод), а в терминах машины тьюрига, любой побочный эффект моделируется зацикливанием и поэтому не отличим от некорретного алгоритма.
* Реальные компьютеры — детерминированны (ГПСЧ — детерминирован), а любое истинно недетерминированное поведение невозможно БЕЗ ввода/вывода.
* Чтобы избежать проблемы неразличения причины зацикливания (некорретность или ввод) и происходит разбиение реальной программы на подпрограммы двух типов.
* Чистые, что означает они ничего не ожидают/нет в(ы)вода/побочных эффектов и поэтому их зацикливание == некорректность
* Менеджер — исключительно ожидает ввод/вывод и поэтому его зацикливание не является признаком некорректности.
Любой кто писал корректный сложный локфри код делал это же самое разбиение на участки и затем анализировал свой алгоритм на коретность с учетом гарантий модели памяти в его языке. Так что да, анализ (не очень больших, сложных, многопоточных) программ возможен чисто технически вот прям дюбом квалифициованным инженром. Да делать это для всей программы не представляется практически возможным без автоматизации. Какие нибудь агды или идрисы могут помочь. Схема такая — разбиваете вашу программу на части описанные выше, учитываете гарантии предоставляемые вашим железом и компилятором, а дальше полный перебор (с учетом ограничений вытекающих из гарантий) всех состояий вашей программы (возможного ввода/вывода) и доказательство или опровержение корректности (зацикливание) вашей программы. Т.е. техническая проблема как раз с той частью программы которая — менеджер, проверка всех возможных входных данных (с учетом ограничений) и является ресурсоемкой на практике, но не является принципиальной/теоретической проблемой.
Ну и то что я все это время пытаюсь донести — зацикливание != некорретность в общем случае для реальных програм. И даже наоборот, я могу специально написать тест который будет проверять, что программа ДОЛЖНА зациклиться/ожидать ввод, т.к. это поведение является частью спецификации и следовательно корректным. И для моделирования такого поведние/тестирования мне нужен оракул который скажет, что программа зациклилась/ожидает ввод.
Насколько мне известно уже идет реальная работа в этом направлении называется верификация программ, да сложно и не всегда возможно полное доказательство на практике из за ограниченности ресурсов, но в ТЕОРИИ/ФУНДАМЕТНАЛЬНО полностю разрешимая проблема, т.к. реальный компьютер НЕ способен выполнить ЛЮБУЮ программу. Думаю что для кого нибудь 8086 процессора (с учетом всех его ограничений на доступную память) уже возможно на практике верефицировать/доказать корректность ЛЮБОЙ программы которую можно на нем запустить только это не практично т.к веротяно затребует мощности самых передовых суперкомпьютеров для анализа, что бы выполнить его в разумное время.
Вы вероятно забыли про факт того что ВСЕ дохулион ядер конкурентно пишущих по одному и ТОМУ же адресу будут сериализованны шинной памяти, многоканальность она про одновременный доступ по РАЗНЫМ адресам. Следовательно что моноядерник что дохулион ядерник это тоже самое — машина Тьюринга.
Ну так об это и шла речь — это и есть ввод/вывод и моделируется он прекрасно = зацикливанием и переписыванием ленты.
Да нет, не нужно никого моделировать. Что делает программа ожидающая ввод? Висит. Поэтому если мы моделируем ввод то программа ОБЯЗАННА повесить машину Тьюринга. Если мы ввод не хотим моделировать, то да можно записать данные на ленту заранее.
Вам же mayorvp вверху почти правильно написал как это моделируется:
* Программа разбивается на подпрограммы которые ничего не ожидают — привет фп чистые функции.
* В модель вводится програма «менеджер» которая запускает подрограммы и ЗАЦИКЛИВАЕТСЯ на момент ввода вывода.
Так что еще разок — вся инженерная/программисткая сложность современных компьютеров принципиально/фундаментально/теоретически ни как не отличается от машины Тьюринга и прекрасно ею моделируется. А модель из 2 пунктов вверху это вобщем то описание того как компилятор фп языка подходит к проблеме чистых не чистых функций и позволяет ФП программистам писать не упражнения в математику, а нормальные полезные программы.
Кеши, ядра, дма, и т.д. никак не влияет, это все просто оптимизации не дающие ничего принципиально отличного от машины Тьюринга, и следовательно никак не отображаются на модель.
Моделирование программы которая ждёт ввода с записанным на ленту вводом это не моделирование, точнее это моделирование другой программы. И мы все такие программы не раз писали называются они тесты.
Ещё раз — ожидание ввода это неостанов для машины Тьюринга и никак иначе. С выводом чуть сложнее т.к. лента у Тьюринга бесконечная то и блокировок не бывает, т.е. ожидание вывода моделируется наложением искусственного для Тьюринга ограничения на размер ленты(не насаму ленту, а на количество ячеек используемых программой через входной параметр) и тоже зацикливание.
Ну и на последок, если бы машина Тьюринга не могла моделировать реальные программы, то это было бы просто не более чем занятное упражнение в математику не имеющее инженерную ценность. Но это далеко не так. Машина Тьюринга это модель не простейшего вычислителя (хотя я думаю имелось ввиду инженерная сложность а не теоретическая), а самого мощного того который может вычислить все что вообще возможно вычислить. А т.к. компьютер не более чем калькулятор и МЕНЕЕ способный чем машина Тьюринга, то утверждение что компьютер и ЛЮБАЯ программа не может быть представлены машиной Тьюринга это ложное утверждение.
Я что здесь, не понял. Программа такая есть, а машиной Тьюринга она смоделированна быть не может? Я может быть не прав, но вроде подразумевается, что компьютер это машина Тьюринга да ещё и с конечной лентой разве нет? А если нет, то в чем практическая польза машины Тьюринга если она не применима к реальным программам? Если машина Тьюринга не может описать реальную программу, то и никакие выводы основанные на рассуждениях с машиной не применимы к реальным программам. Получается пчелы против меда, компьютер не может быть описан математически, какой то это абсурд или магия.
Если мне не кажется, то состояние ожидание ввода вывода это и есть не останов/зацикливание машины Тьюринга. При этом факт ввода это изменение состояния ленты НЕ машиной Тьюринга — извне, но при этом это изменение может прервать бесконечный цикл и завершить программу. Т.е. по какой угодно логике, ваш оракул должен выдать программа не завершается (сама по себе с заданной лентой, что как бы подразумевается).
Знаете ли я тоже имею некоторое представление о сложности этого «simply just checks», т.к. задавался конкретно этим вопросом. Я не сишник и сишный стандарт как отче наш на знаю, но вот в мире с++ это нифига не простая проверка и думаю си здесь не отличается от с++. Если интересно за подробностями сюда
Так что, то что пишет Линус о том, что это чушь это он мегко говоря не прав в общем случае. Конечно, на тех платформах с которыми он привык работать наверное это действительно просто, но не на всех.
Т.е. то что он предлагал — вернуть назад простую наивную реализацию, которая также еще и оверлапинг проверяла, нормальное предложение, но оно по очевидным для меня причинам (не работает в общем случае) было отвергнуто. То что он назвал граничными случаями наверное(код не смотрел) и есть учет разных экзотических платформ — реализация общего случая корректным образом.
Еще раз перевожу с Линксвого языка на человеческий — я вертел вашу корретность в общем случае, ваша реализция поламала код который нормально работал для пользователей моего продукта, так шо давай те вашу корректность засуним куда подальше и поможем нашим пользователям. Нормальный, здравый подход защищать свой продукт и продавливать решения которые позволяют избежать работы. Я бы тоже такую дичь говорил если бы был заинтересованной (в таком решении) стороной.
Нет, спасибо, не надо, пусть лучше будет впервую очередь коректно и во второую максимально быстро, а за дополнительными плюшками идите в memmov.
А для тех кто на бронетанке можно пожалуйста поподробнее про эту историю?
Решение проблемы календаря в цифровом виде уже давно существует — timestamp. Никакой неоднозначности, никаких циклов. Проблема в том, что люди не умеют, не хотят и обоснованно недоумевают от идеи использовать штампы в повседневной жизни. Штамп это как в6 айпишник, отличное решение для машин и совершенно непригодное для людей. Поэтому проблема которую вы пытаетесь решить технически не является технической, система временных зон отличная идея и технически она решена. Все сложности цифрового представления из за еб… тых политиков, и решение этой проблемы лежит в области онигиляции корня проблемы, а не костылевания техническими средствами.
Ещё раз надо либо прошивку у всех человеков поменять чтобы мы напрямую в штампы умели или выпилить несколько особо одаренных которые портят жизнь всем остальным — это надёжные и логичные решения, а то что вы предлагаете какая то херня.
Люди сошли с ума и пытаются решать не ТЕ проблемы. Вместо того чтобы спорить кто кого чаще убивает, надо решать проблему оружия — и я не про запрет, а про эффективное НЕ смертельное оружие. Цель должна быть не убить преступника, а просто обезвредить, но это сложно. Проще убить, а потом всем миром ныть шо негров оказывается убивают чаще.Я за владение эффективным не смертельным оружием и против владения смертельным.
А вот самое интересное — адаптер FuncPassManager в ModulePassManager не показан. Я так предполагаю, что там модуль представляется как коллекция функций и для каждой вызывается все что добавленно в функциональный пасс менеджер? Честно Шон очень клёвый, но он не единственный кто до этой идеи дошёл. Впервые я это увидел (не сам додумался) почти 20 лет назад когда из всего с++ мира только про страуса знал и то по книгам. уверен что и раньше это тоже было известно. С тех пор разве что мув добавился для производительности, но и без него на указателях по сути также все и работало.
Я тестирую ваш мобильный браузер с самой первой беты. И с самого начала есть проблема которая так никуда и не ушла. Вивальди на Андроиде УЖАСНО тормозит. Конкретно скрол любой страницы дергается. Уже все чего мне не хватало есть темный режим и реклама резка, но вот это дёрганье никак не может победить лису с тем же функционалом. Пожалуйста пофиксите дёрганье при скроле это блокер. Телефон 8 гигов памяти дракон 855 т.е. точно дело не в железе лиса просто летает.
Вы не поверите, с вероятностью примерно 1/7 таки да сможет.
Да вобщем то ничего не мешает. Только без колег значит в одиночку значит какой-то мало кому нужный опен соурс в ваше свободное время. На работах за последние 10 лет не было ни разу случая что нужно что то писать с нуля. Это всегда уже существующий и как то работающий код который нужно расширить/пофиксить. Мест работ и стран и профилей компаний много разных но это ни на что не влияет. Ситуация где у вас на работе нет/мало колег и нужно писать новый код == вы в самом начале стартапа или совершенно новый проект, по какой то неведомой мне причине это значит что вы и 1,5 других колег джуниоры и вам все это ещё неизвестно или нет времени на эксперименты. Может быть потому что стартапы не могут предложить денег/интерес для более опытных девелоперов, а свой стартап опытные девелоперы почему то не спешат начинать. Вобщем такое возможно, но мне не довелось поучаствовать.
Все это очень хорошо в теории. Я так попытался писать на плюсах в реальном проекте, только настоящая проблема этого подхода не в том что система типов слаба (а она на самом деле слаба) а в коллегах, которые с полным недоумением спрашивают, а нахрена это все? И у них есть непрошибаемый козырь писать так объективно сложнее, а читать неподготовленному мозгу такое вообще противопоказанно. С легаси несовместимо категорически, т.к. требует неимоверных усилий по рефакторингу и как обычно в условиях отсутствия тестов и времени под давлением типа давай результат вчера и погуще. Так что в реальном мире мне пришлось согласиться с мертворожденностью этого подхода. Пока мне приходится героически преодолевать ограничения системы типов и костность мозгов это никогда не выйдет дальше вот таких статей. Мозги нужно учить лучшему в вузе, а этого там не рассказывают. Человек валидировал десятки лет и по его словам успешно ( с точки зрения формальных критериев: закрытые таски, вовремя сделанные релизы), это значит вы никогда не сможете убедить его работать больше чем прежде для достижения того же результата. Обещанию меньшего количества багов НИКТО не верит, а увидеть логику почему это так не может в силу скудоумия/костности. Пробовать отказываются не понимая зачем им это надо. Компилятор тоже вам вставит палки в колеса везде где только возможно, т.к. уже давно в тренде требовать от программиста выражать свои намерения максимально явно, а это в свою очередь вызывает необходимость писать много бойлерплэйт кода в парадигме парсинга. Так что я вам категорически не советую даже пробовать такое в реальных проектах на плюсах, идею не оценят, и сделают все от них возможное чтобы вы отказались от этой идеи и по скорее.