Программисты тоже никуда не делись, но все, что они знают об языках, библиотеках, фреймворках и т.д. они вдруг полностью забыли. Остались только общие принципы и алгоритмы, не зависящие от языков и т.д.
А Вы — демиург. В Ваших силах мгновенно создать новое ПО с той же функциональностью (для пользователей), создать языки, библиотеки и фреймворки и вложить это все в головы программистов, так что они сразу будут в состоянии с этими новыми средствами работать на прежнем профессиональном уровне. Ну а Вы после этого отойдете в сторону и вмешиваться больше не будете.
В общем, после того, как Вы это сделали, мир ПО опять существует, но на основе иных, предложенных Вами средств. И программисты продолжают свою работу, тоже с использованием этих новых средств.
Представили ?
Вопрос же следующий.
Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ?
Только просьба — не разменивайтесь по мелочам. Не пишите, что Вы бы поменяли бордюр у какого-то окна или вообще сделали его круглым.
Вот, скажем, предложение заменить TCP/IP на что-то иное — это другое дело. Или вместо файлов ввести... ну уж не знаю что.
Конечно, аргументируйте.
P.S. Для тех, кому моя преамбула не нужна, сформулирую вопрос более реалистично.
Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
P.P.S. У меня сложилось впечатление, что некоторые участники дискуссии не против бы и мир переделать (десятичную систему заменить, время по иному измерять, даже число pi ревизовать). Просьба все же оставаться в рамках темы. Ни железо, ни тем более внешний мир этому демиургу возможности изменять я не давал
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Я бы JavaScript убрал бы. Заменил бы чем ни будь похожим на C# или Java.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Если всё, что не нравится, избежим, и пойдём другим путём, непременно найдём новые грабли, не хуже старых
Здравствуйте, Qulac, Вы писали:
Q>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Q>Я бы JavaScript убрал бы. Заменил бы чем ни будь похожим на C# или Java.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ?
Я бы заменил С++, Java и C# на один язык без VM со сборкой мусора(отключемой). Но насчет этого разных мнений много.
PD>Вот, скажем, предложение заменить TCP/IP на что-то иное — это другое дело. Или вместо файлов ввести... ну уж не знаю что.
Вместо IPv4 и ада с NAT использовать сразу IPv6.
PD>Только просьба — не разменивайтесь по мелочам. Не пишите, что Вы бы поменяли бордюр у какого-то окна или вообще сделали его круглым.
Вообще, в ИТ изменения легче внедряются, чем в других инженерных областях. Поэтому больше ни на какое legacy особенно не жалуюсь.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот, скажем, предложение заменить TCP/IP на что-то иное — это другое дело. Или вместо файлов ввести... ну уж не знаю что.
У меня бы все сразу были на IPv6 не размениваясь на IPv4.
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Не нужно было делать Java, .NET и кучу других разработок вносивших разброд и шатание, деля программистов по специализации относительно инструментов разработки, а не умению использовать алгоритмы. Cмартфоны для приложений использовали бы C/C++ и были дровишки для GNU/Linux. Весь код кроссплатформенный, работал бы на десктопа/серверах, смартфонах, промышленных контроллерах и других устройствах.
Упор в приложениях на высокую производительность и минимальное потребление оперативной памяти, как следствие энергоэффективность. Опять же нафантазировать можно всё что угодно, какой-нибудь световой компьютер. На практике же видим эволюционное движение от одних технологий к другим. Если одна технология для программистов лучше другой, то выживет лучшая, даже не смотря на все попытки продвинуть худшую.
И ещё, совместимость и прочее не так уж сильно и мешают. Другое дело нужно провести огромный труд, а это множество условных человеко часов, причём специалистов высокого уровня. Те же смартфоны делают с расчётом, что пользователь их через несколько лет, а то и раньше выкинет, то есть изначально работа в мусорку. Хорошо было бы стандартизировать библиотеки алгоритмов внедрив в них лучшие практики программирования.
Здравствуйте, Qbit86, Вы писали:
Q>Перейти к системе счисления с основанием, выбранным рационально, а не эволюционно-биологически.
Вообще-то ее в компьютере не так уж много. Вся арифметика в основном не в ней, в ней только вывод результатов.
Если же речь идет не об ИТ, а о мире в целом — это от нас не зависит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Собственно легаси и совместимость осталась только в ОС. Соответственно переписал бы ОС полностью с нуля, с учетом лучших наработок. Чтоб ядро отдельно. Разделенное на модули, максимально независимые, и в ядре б оставил минимально возможное количество модулей. Чтоб одну ОС можно было поставить в микроволновку и в десктоп. И в микроволновке базовая архитектура была та же самая, но там бы было только то, что нужно микроволновке. А в компе — все, что нужно компу, и все можно было собрать из кирпичиков. Софт бы ставил из централизованного магазина приложений, как сейчас. У меня до черта есть идей относительно идеальной ОС, и чтоб собрать все воедино будет огроменный документ. Сразу бы при проектировании закладывался, что ОС должна работать на любом процессоре, от i8080 и проще до современных и будущих монстров. Скорее всего в топку бы выбросил концепцию файловой системы, вместо этого что то вроде объект и набор тегов. Точно бы выкинул понятие пути к файлу! Программу бы сразу ставил со всеми зависимостями, все программы пусть живут в своей песочнице. Плюс механизм взаимодействия между программами, когда они универсально умеют сообщать другим что они умеют. Программы бы сделал в обязательном порядке разбитыми на модули, как минимум бы разделял в обязательном порядке UI (причем UI модулей может быть несколько, например голосовой UI, текстовый UI, графический UI) и функционал. API (максимально компактное и универсальное) старался бы продумывать очень и очень тщательно, чтоб потом не нужно было менять. Допускал бы, например, возможность прямого общения между программами минуя ОС, в том числе и между программами, ничего не знающими друг о друге. Соответственно сначала б в течение года писал документ, касающийся архитектуры будущей ОС, тщательно продумывая, чтоб не повторить все подводные камни, на которые огребла индустрия. В частности сразу б учитывал, что хрен я все предугадаю, но должен как то продумывать механизм рефакторингов будущих косяков. На байтах для высокоуровневых вещей бы не экономил.
Сделал бы так, чтобы все языки на момент создания поддерживали только русский язык. Проснулись бы американцы, ан кругом Пока() Если () Для (пер ё = 0; ё < массив.длина; ё++).
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ?
1. Никаких кодировок кроме utf-8
2. HTML, CSS, гуевые фреймворки на помоечку, вместо всего этого универсальный язык разметки с размерами в миллиметрах (отобразить правильно задача драйвера железки) для всего от принтеров, до экрана телефона. Все иконки строго векторные
3. С на помоечку, вместо него простой, непротиворечивый и логичный язык заточенный (как сделать правильно можно спросить меня)
4. POSIX на помоечку вслед за С, пусть интерфейсы напишут люди умеющие программировать
5. Python, Java script и прочие наколенные поделки на помоечку
Здравствуйте, velkin, Вы писали:
V>Не нужно было делать Java, .NET и кучу других разработок вносивших разброд и шатание, деля программистов по специализации относительно инструментов разработки, а не умению использовать алгоритмы. Cмартфоны для приложений использовали бы C/C++ и были дровишки для GNU/Linux. Весь код кроссплатформенный, работал бы на десктопа/серверах, смартфонах, промышленных контроллерах и других устройствах.
С++ не нужен был бы
Здравствуйте, 0x7be, Вы писали:
0>С++ не нужен был бы
А какая адекватная замена C/C++? Давайте по примеру топика представим, что платформы .NET, Java, а так же многие языки программирования исчезли. В целом компьютерная инфраструктура пострадала, но компьютеры по прежнему работают. Убираем C/C++ и наступает глобальный конец, ядра операционных систем, драйвера, веб-сервера, базы данных, cad, игры и многое другое перестают существовать. Это между прочим так же говорит о том, что подвергать исчезновению нужно именно C/C++, так как после этого всё остальное попросту исчезнет или не будет работать, потому что использует другие программы написанные на C/C++.
Здравствуйте, elmal, Вы писали:
PD>>Чтоб одну ОС можно было поставить в микроволновку и в десктоп. И в микроволновке базовая архитектура была та же самая, но там бы было только то, что нужно микроволновке.
Если в микроволновке примитивный микроконтроллер, тогда используется Си. А если, что покруче, тогда можно поставить линукс или что-то подобное. Обычной микроволновке нужна только машина состояний, здесь можно обойтись и без ОС.
PD>>У меня до черта есть идей относительно идеальной ОС, и чтоб собрать все воедино будет огроменный документ. Сразу бы при проектировании закладывался, что ОС должна работать на любом процессоре, от i8080 и проще до современных и будущих монстров.
Может тогда лучше отталкиваться от идеи единой алгоритмической базы.
PD>>Скорее всего в топку бы выбросил концепцию файловой системы, вместо этого что то вроде объект и набор тегов. Точно бы выкинул понятие пути к файлу!
А вот в современном программировании существуют такие понятия как: URI = URN + URL
URN (англ. Uniform Resource Name) — единообразное название (имя) ресурса.
<URN> ::= "urn:" <NID> ":" <NSS>
<NID> идентификатор пространства имён (англ. Namespace Identifier); представляет собой синтактическую интерпретацию NSS, не чувствителен к регистру.
<NSS> строка из определённого пространства имён (англ. Namespace Specific String);
Эта идея про набор тегов является URN, где NID пространства имён такие как контрольные суммы или что-то менее надёжное, вроде ISBN и так далее, а сами теги представляют собой NSS. Потому мы в принципе ничего нового не получим, те же magnet-ссылки.
URI-схема magnet: — открытый, находящийся в стадии рабочего черновика стандарт, определяющий URI-схему т. н. magnet-ссылок, предназначенных преимущественно для указания на ресурсы, доступные к загрузке через пиринговые сети.
По сути здесь ничего удалять в глобальном смысле не нужно, надо только допилить пиринговые сети до более удобного состояния.
PD>>Программу бы сразу ставил со всеми зависимостями, все программы пусть живут в своей песочнице.
В смартфонах пользователя ставят раком, или давай разрешение программе, или она не установится. В целом да, программы нужно ограничивать, но не так как это сейчас реализовано. Ещё люди жалуются на уязвимости в процессорах.
Здравствуйте, velkin, Вы писали:
V>А какая адекватная замена C/C++?
Какой-то другой язык, в котором из-за эволюционного развития не было бы таких ужасов
Здравствуйте, 0x7be, Вы писали:
V>>А какая адекватная замена C/C++? 0>Какой-то другой язык, в котором из-за эволюционного развития не было бы таких ужасов
Конкретнее, что должен иметь этот язык программирования или даже не иметь. Чисто абстрактно можно вообразить, что есть такая система в которой программа сама создаётся под текущие плохо сформулированные требования, но это уже из области фантастики. К тому же в топике не сказано о замене аппаратной части, то есть мы имеем дело всё с тем же зоопарком из x86, x64, arm и так далее, и видеокарты у нас от зелёных и красных, а не квантовые суперкомпьютеры.
Или какое там было недавно обсуждение. Вот есть у нас некий новый язык программирования, но в нём нет множественного наследования. Кто-то скажет хорошо, а кто-то из-за отсутствия альтернативы начнёт его изобретать заново. Тоже самое с процедурной парадигмой, ну выкинем мы её и оставим обобщённое, а вместо функционального будем использовать объектно-ориентированное. Уровень абстракции повысился, а дальше мы наблюдаем, как программисты уже без нас изобретают процедурное и функциональное программирование.
Так-то если подумать, вот я например, лишил программистов .NET и Java. Сейчас уже признано, что нативный код быстрее. Тем не менее без наглядного примера ту же JIT-компиляцию переизобретут заново, причём ещё и будут всё это использовать. Получается идти нужно по пути создания ПО превосходящее всё имеющееся. А обычное урезание изобретённого приведёт лишь к тому, что люди так и так потратят время на переизобретение. Собственно говоря сейчас и без всяких допущений программирование движется этим путём.
Здравствуйте, 0x7be, Вы писали:
PD>>Железо осталось. Без изменений. 0>А чего так? Я пощупал немного MC68000 — после Intel`а просто рай какой-то. Всё просто и без затей.
Просто предлагаю обсудить только софт, чтобы не уходить в сторону.
От железа не так уж сильно софт в наше время зависит. Появись сейчас для десктопов новый процессор, принятый миром — и очень скоро Linux вместе с Windows для компьютеров на этом процессоре будут готовы. Практически с тем же API и теми же средствами.
А само железо обсуждать, в особенности линейку x86/x64 — так тут и обсуждать нечего. Если бы мой демиург пересоздал этот процессор в том же виде, в каком он сложился в ходе эволюции 4004 -> 8008 -> 8080 -> 8086 -> 80286 -> 80386 -> и далее, то это был бы не демиург, а идиот.
Здравствуйте, velkin, Вы писали:
V>Если в микроволновке примитивный микроконтроллер, тогда используется Си. А если, что покруче, тогда можно поставить линукс или что-то подобное. Обычной микроволновке нужна только машина состояний, здесь можно обойтись и без ОС.
ОС может понадобиться для того, чтобы этой микроволновкой управлять с мобилы. При этом программа микроволновки говорит внешнему окружению, что она микроволновка, умеет включаться, устанавливать мощность из определенного диапазона, умеет крутить гриль и говорить где она расположена. Соответственно я, как разработчик для умного дома могу написать софт, позволяющий на запрос "дай мне пожрать пиццы" достать пиццу из холодильника и поместить в микроволновку, разогреть и далее принести мне на стол. И это будет работать корректно если у меня есть микроволновка, холодильник и робот, который занимается перетаскиванием пищи. При этом микроволновка, холодильник, робот, друг о друге ничего не знают. Если у меня дома нет робота — система управления умным домом скажет что извини, у меня нет устройства для заполнения устройства приготовления пищи. Давай ка сам таскай, но посоветует купить робота.
Здравствуйте, elmal, Вы писали:
E>ОС может понадобиться для того, чтобы этой микроволновкой управлять с мобилы. При этом программа микроволновки говорит внешнему окружению, что она микроволновка, умеет включаться, устанавливать мощность из определенного диапазона, умеет крутить гриль и говорить где она расположена.
Разве для этого микроволновке нужна ОС? И нужно ли все ломать и начинать сначала, что бы появилась такая функциональность?
В 1999 вопросы коммуникации вещей предлагалось решать радиочастотными метками и простейшими протоколами.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Просьба все же оставаться в рамках темы. Ни железо, ни тем более внешний мир этому демиургу возможности изменять я не давал
А зря. Потому что современное железо является таковым по большей части из-за груза совместимости с написанным ранее ПО.
Здравствуйте, vdimas, Вы пис
V>А зря. Потому что современное железо является таковым по большей части из-за груза совместимости с написанным ранее ПО.
Тут 2 момента
Во-первых, архитектуру x86/x64 предложили бы переделать все, тут сомнения нет, нечего обсуждать.А какую именно нужно — на эту тему и без того обсуждений немало
Во-вторых, я не вполне согласен с тезисом. Линукс где только не работает, и появись новый процессор -будет и на нем работать. Windows тоже
А все, что выше ОС — так это совсем слабо от процессора зависит
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Всякий раз чётко решать, для кого делается пользовательское ПО (начиная от операционных систем) — мультяшно-однооконно-пальцетычное для тех кому напрягать мозг больно и страшно, или "инженерное" для не имеющих такой патологии. Если очень надо, то выпускать 2 разные версии. Но не пытаться сводить эти "2 мира, 2 морали" к наиглупейшему общему знаменателю, как делают микрософт с апле и на поводу у них толпа подражателей.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ?
Изобрел бы Фортран 77, наверное. Но с зарезервированными словами и без умолчаний.
И никаких GOTO. Арифметический IF — наше всё!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Железо осталось. Без изменений.
Что ж так мелочиться то? Развитие железа зашло в жестокий тупик, а недавние (но наверняка не последние) уязвимости уже забивают крышку гроба гвоздями.
Нужно новое железо!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ? Как уже упоминали — переделал бы JavaScript.
То есть оставил бы его очень похожим в общем, но починил бы мелочи — все эти автоприведения в сравнениях и прочий WTF, который сейчас не могут выкинуть из-за backwards compatibility. Cама по себе идея иметь HTML5+JS для мобильных приложений — здравая. Мелочи портят всю картину.
Сделал бы SQL строготипизированным.
Отказался бы от аппаратной изоляции в ОС, оставив только софтную с верификацией. Аппаратная защита — дорогая и небезопасная (см. Meltdown). Статическая верификация значительно надёжнее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S> Отказался бы от аппаратной изоляции в ОС, оставив только софтную с верификацией. Аппаратная защита — дорогая и небезопасная (см. Meltdown). Статическая верификация значительно надёжнее.
Не будет медленно ?
И провокационный (зная твое отношение к этому) вопрос.
HTTP не изменил бы ? Или, может, на что-то иное заменил ?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Не будет медленно ?
Будет быстрее. Потому что нет переключений между кольцами для syscall. PD>И провокационный (зная твое отношение к этому) вопрос. PD>HTTP не изменил бы ? Или, может, на что-то иное заменил ?
Вот не знаю. HTTP2 вышел после того, как я перестал читать RFC на протоколы; поэтому не знаю, какие там приняты меры. В целом, HTTP/1.1 уже весьма прекрасен. Не знаю, что такое нужно делать, чтобы упереться в его ограничения в клиент-серверных приложениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Не будет медленно ? S>Будет быстрее. Потому что нет переключений между кольцами для syscall.
А защита ? Ты предлагаешь ее на чисто софтверном уровне делать ? Но тогда и проверять каждый раз придется с использованием ПО, это вряд ли будет быстро
char * p = чему-то
*p = 0;
И как здесь на софтверном уровне проверять, имею ли я право доступа туда ? Встраивать на каждый mov команды проверки ?
PD>>И провокационный (зная твое отношение к этому) вопрос. PD>>HTTP не изменил бы ? Или, может, на что-то иное заменил ? S>Вот не знаю. HTTP2 вышел после того, как я перестал читать RFC на протоколы; поэтому не знаю, какие там приняты меры. В целом, HTTP/1.1 уже весьма прекрасен. Не знаю, что такое нужно делать, чтобы упереться в его ограничения в клиент-серверных приложениях.
Вопрос не в ограничениях, а в архитектуре. Тебе не кажется, что тот же интерфейс GET с параметрами можно бы на что-то более элегантное заменить ? И заодно Header переделать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Не будет медленно ? S>>Будет быстрее. Потому что нет переключений между кольцами для syscall.
PD>А защита ? Ты предлагаешь ее на чисто софтверном уровне делать ? Но тогда и проверять каждый раз придется с использованием ПО, это вряд ли будет быстро
PD>char * p = чему-то PD>*p = 0;
PD>И как здесь на софтверном уровне проверять, имею ли я право доступа туда ? Встраивать на каждый mov команды проверки ?
Очевидно, доступ по произвольному адресу и арифметика указателей (да и вообще трактовка указателей как чисел) в прикладном коде полностью запрещается. В системном коде можно оставить ограниченные возможности манипуляции указателями, безопасность операций с которыми гарантируется статическим верификатором (но такое — "char * p = чему-то" — в любом случае запрещается).
ARK>Очевидно, доступ по произвольному адресу и арифметика указателей (да и вообще трактовка указателей как чисел) в прикладном коде полностью запрещается. В системном коде можно оставить ограниченные возможности манипуляции указателями, безопасность операций с которыми гарантируется статическим верификатором (но такое — "char * p = чему-то" — в любом случае запрещается).
Как ты себе это представляешь ?
Можно, конечно, не использовать указатели в Яве, С# или JS -коде , где их и нет. Так ведь в jvm, .net самой или браузере не запретишь же!
Если вообще запретить указатели (машинные адреса) в юзермоде — придется для каждой команды, работающей с памятью, переключаться в режим ядра. Это будет фантастическая просадка скорости.
А перенести jvm и т.д. в режим ядра — это просто будет означать перенос всей работы в ядро. После этого о безопасности ядра говорить будет сложно.
CM>Что ж так мелочиться то? Развитие железа зашло в жестокий тупик, а недавние (но наверняка не последние) уязвимости уже забивают крышку гроба гвоздями. CM>Нужно новое железо!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно, конечно, не использовать указатели в Яве, С# или JS -коде , где их и нет. Так ведь в jvm, .net самой или браузере не запретишь же!
Почему нет? Запретишь. Просто делать что угодно будет нельзя (например, просто прибавить к указателю единицу и обратиться по этому адресу).
PD>А перенести jvm и т.д. в режим ядра — это просто будет означать перенос всей работы в ядро. После этого о безопасности ядра говорить будет сложно.
Да, речь именно о переносе всего в режим ядра (собственно, никаких "колец" уже и не будет). Безопасность обеспечивается статической верификацией (как в Singularity или Rust).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А перенести jvm и т.д. в режим ядра — это просто будет означать перенос всей работы в ядро. После этого о безопасности ядра говорить будет сложно.
Хотя по условию про софт тут все забыли, железо осталось таким, как было. А про железо, в частности, защиту памяти, тут говорили в далеком 2005 году. Нужна ли Оберон-ОС защита памяти?
Здравствуйте, AlexRK, Вы писали:
ARK>Да, речь именно о переносе всего в режим ядра (собственно, никаких "колец" уже и не будет).
Так, давай по порядку.
Колец не будет.
Приложения могут использовать только управляемый код.
Тогда вопрос — а кто имеет право разрабатывать нативный код ? Его все же добавлять может некий сторонний производитель, или же только изготовитель процессора и те,кому он это доверит ?
>Безопасность обеспечивается статической верификацией (как в Singularity или Rust).
Я понимаю, к чему ты клонишь. Но Singularity не пошла.
Кроме того, я что-то не уверен в том, что статическая верификация совершенно надежна.
Здравствуйте, Privalov, Вы писали:
P>Хотя по условию про софт тут все забыли, железо осталось таким, как было. А про железо, в частности, защиту памяти, тут говорили в далеком 2005 году.
О нем не только говорили, его и сделали (Итаниум), да только архитектура x86/x64 за себя постоять сумела.
Просто если начать это обсуждать — тред превратится в обсуждение того, каким должен быть процессор (потому что архитектуру x86/x64 никто защищать не будет).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Приложения могут использовать только управляемый код. PD>Тогда вопрос — а кто имеет право разрабатывать нативный код ? Его все же добавлять может некий сторонний производитель, или же только изготовитель процессора и те,кому он это доверит ?
Не обязательно в приложениях должен быть управляемый код. Вполне может быть и статически верифицируемый нативный код.
Verve — статически верифицируемая ОС, снизу доверху, абсолютно целиком и полностью — включая самые-самые низкоуровневые части на ассемблере (это, конечно, не простой ассемблер, а TAL — ассемблер, подходящий для статической верификации).
То есть это всё нативный код, но при этом верифицируемый на этапе компиляции. Думаю, в будущем все к тому и придет. Хотя для обычных приложений писать на управляемых языках просто дешевле, поэтому, думаю, управляемый код тоже останется.
PD>Я понимаю, к чему ты клонишь. Но Singularity не пошла.
Не пошла, верно. Но показала, что подобная реализация при желании вполне возможна. (Будет такое желание у кого-то или нет, и если будет, то когда — это все открытые вопросы.)
PD>Кроме того, я что-то не уверен в том, что статическая верификация совершенно надежна.
На 100%, конечно, нет. Равно как и процессоры не надежны на 100% (см. недавние дыры).
Здравствуйте, AlexRK, Вы писали:
ARK>На 100%, конечно, нет. Равно как и процессоры не надежны на 100% (см. недавние дыры).
OK.
Создана эта самая ОС с верификацией. В ней можно писать программы на нативном коде, но его верифицируют.
Но верификация не на 100% надежна. Более того, предполагаю, что она гораздо меньше надежна, чем защита в процессоре. Там все же из 0 кольца к ядру добраться нельзя. И не надо мне про Meltdown и Spectre — они все же доступа по записи не дают.
Кто-то находит способ обойти эту верификацию. Обойти не потому, что ее алгоритм содержит ошибки, а потому что он нашел ситуацию, когда верификация не работает. Какими-то хитрыми упражнениями , сводящими с ума статический верификатор.
Такое может быть ? Все же программа исполняется в динамике — ты уверен, что статическими средствами можно все случаи предусмотреть ?
В итоге он хозяин машины. Другой-то защиты больше нет. У него полный доступ к ядру ОС.
А если он — автор вируса, то есть делает это сознательно — и что теперь делать ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но верификация не на 100% надежна. Более того, предполагаю, что она гораздо меньше надежна, чем защита в процессоре.
Трудно сказать. Вряд ли можно это измерить.
PD>Там все же из 0 кольца к ядру добраться нельзя.
В теории нельзя, но кто сказал, что в процессоре нет дырок? Современные процы — штука очень сложная.
PD>Кто-то находит способ обойти эту верификацию. Обойти не потому, что ее алгоритм содержит ошибки, а потому что он нашел ситуацию, когда верификация не работает. Какими-то хитрыми упражнениями , сводящими с ума статический верификатор. PD>Такое может быть ?
Вполне может, думаю. На практике, ИМХО, вероятность не слишком велика. Но, конечно, что-то в этом плане утверждать я не могу.
PD>Все же программа исполняется в динамике — ты уверен, что статическими средствами можно все случаи предусмотреть ?
Теоретически можно предусмотреть всё, на практике можно какую-то дырку и пропустить.
PD>В итоге он хозяин машины. Другой-то защиты больше нет. У него полный доступ к ядру ОС. PD>А если он — автор вируса, то есть делает это сознательно — и что теперь делать ?
Так и сейчас примерно то же самое. Баги в процессоре, баги в ядре, эскалация привилегий — и у тебя полный доступ к ядру ОС, ты хозяин машины.
Сейчас, конечно, можно сказать, что "эшелонированная оборона" состоит из двух бастионов — сперва дыры в софте, а потом дыры в железе. Но что мешает сделать несколько эшелонов в софте? Не вижу принципиальной разницы.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О нем не только говорили, его и сделали (Итаниум), да только архитектура x86/x64 за себя постоять сумела.
Я, признаться, по Итаниум ничего не знаю. Попробовал читать, но что-то не пошло. Правда, у меня по графику трудовые свершения. Оказывается, они нехило влияют на способность быстро переваривать прочитанное.
Вкратце, у него есть защита памяти или нет?
И если есть, то можно придумывать C++, а если нет, то Оберон? Правда, с последним не все так просто. Короче, Фортран рулит, как ни крути.
Здравствуйте, Privalov, Вы писали:
P>Я, признаться, по Итаниум ничего не знаю. Попробовал читать, но что-то не пошло. Правда, у меня по графику трудовые свершения. Оказывается, они нехило влияют на способность быстро переваривать прочитанное. P>Вкратце, у него есть защита памяти или нет?
Хм, не понял. Как может быть процессор 21 века без защиты памяти ?
P>И если есть, то можно придумывать C++, а если нет, то Оберон? Правда, с последним не все так просто. Короче, Фортран рулит, как ни крути.
Здравствуйте, AlexRK, Вы писали:
PD>>Но верификация не на 100% надежна. Более того, предполагаю, что она гораздо меньше надежна, чем защита в процессоре.
ARK>Трудно сказать. Вряд ли можно это измерить.
Может, я что-то не понимаю, но
int n,m;
read(m,n); // ввод откуда-то
int a[m]; // выделяем память и создаем массив
a[n] = 1;
Как можно этот фрагмент статически проверить ? При корректных m и n все будет замечательно. При большом n мы свободно сейчас можем уехать в адреса ядра, за что и получим AV
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ?
lpd>Я бы заменил С++, Java и C# на один язык без VM со сборкой мусора(отключемой). Но насчет этого разных мнений много.
было такое в Objective-C. Не прижилось. Кстати, не знаю, почему. Есть инсайдеры, пролить свет?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может, я что-то не понимаю, но
PD>int n,m; PD>read(m,n); // ввод откуда-то PD>int a[m]; // выделяем память и создаем массив PD>a[n] = 1;
PD>Как можно этот фрагмент статически проверить ? При корректных m и n все будет замечательно. При большом n мы свободно сейчас можем уехать в адреса ядра, за что и получим AV PD>А статически — как ?
В принципе, идея простая. Можем ли мы сказать, глядя на этот код, что он 100% корректен? Нет. Мы этого не можем утверждать. И верификатор, естественно, тоже не может. Результат? Ошибка компиляции.
Как сделать, чтобы код скомпилировался? Убедить верификатор в том, что код безопасен.
int n,m;
read(m,n); // ввод откуда-тоif (stack_available(m)) // stack_available - специальная функция, известная верификатору
{
int a[m]; // выделяем память и создаем массивif (is_valid_index(a, n)) // is_valid_index - специальная функция, известная верификатору
{
a[n] = 1;
}
else
{
// тут мы хотели обратиться по некорректному адресу, но рантайм-проверка нам не дала
// что делать? наверное вернуть ошибку или выдать какое-то сообщение
}
}
else
{
// тут рантайм-проверка показала, что места на стеке нет, создать массив мы не можем
// и что же нам делать? ну, что угодно, можно вернуть ошибку или терминировать процесс
}
Так что сама идея довольно простая. Там, где верификатор не знает, корректная операция или нет — он заставляет программиста вставить рантайм-проверку.
Конечно, эти явные проверки замусоривают код, но потенциальный выигрыш в том, что их может быть не так уж много. Это как типы данных. Если мы хотим принять в функцию int, то компилятор не даст нам туда сунуть string. Аналогичным образом мы можем потребовать предусловие наподобие "is_valid_index" и тогда внутри функции этой проверки уже не будет — она будет где-то выше по стеку вызовов.
Да, такой код писать сложнее. Но это возможно. Примерно так пишут софт для марсоходов и самолетов. Я думаю, что такой вариант возможен для самых низкоуровневых частей ОС, а что-то более высокоуровневое можно писать уже на управляемых языках, более тормозных, но и более простых.
Здравствуйте, AlexRK, Вы писали:
ARK>В принципе, идея простая. Можем ли мы сказать, глядя на этот код, что он 100% корректен? Нет. Мы этого не можем утверждать. И верификатор, естественно, тоже не может. Результат? Ошибка компиляции.
<skipped>
Понятно, но выглядит пугающе. Для меня, по крайней мере.
Одним махом уничтожается весь существующий нативный код. Он практически со 100% вероятностью не пройдет эту проверку, а значит, придется переписывать в нем очень многое.
Далее. Представь себе, что это программа линейной алгебры. Там этих a[i][j] в каждой строке может быть по нескольку штук. Если заставлять каждое такое описание верифицировать по твоему механизму — код за этими верификациями видно уже не будет, а отладка превратится в ад.
А не запретишь. И управляемые языки не помогут. Ты же ОС собрался делать, и что, ты мне скажешь, что в этой ОС писать "тяжелый" код можно только на управляемых языках ? Он и без того тяжелый, там O(N^3), например, а мне, выходит, его оптимально написать нельзя ?
Кроме того, почему ты решил, что массив отведен в стеке ? Для него относительно просто написать stack_available. А если в куче ? Да еще двумерный и при этом jagged ? И при этом еще и не прямоугольный, а хорошо если только треугольный ? Тебе не кажется, что такая "статическая" проверка просто не получится ? А еще realloc (в С) есть. А еще union в нем же есть.
Что-то у меня такое ощущение, что это лекарство хуже болезни. Сейчас мне как программисту по крайней мере все ясно — я могу делать (в нативе) что хочу, за свои безобразия в юзермодной части АП я отвечаю сам (кстати, и тут мне помогают, доступ к невыделенным адресам блокируется), а за попытку безобразия в системной части АП будут бить со 100% гарантией. И код я при этом пишу, как его всегда писали. А тут предлагается писать его совсем по-другому, с массой накладных расходов, а успех не гарантирован.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм, не понял. Как может быть процессор 21 века без защиты памяти ?
Я ж говорил, период трудовых свершений даром не проходит. Что защита памяти нужна, я писал в Философии еще в 2005 году в оберонных войнах. А про Итаниум, повторю, я ничего не знаю. И чтение в голову не лезет по причине, которую я только что отметил. Попозже я к этому вернусь.
P>>И если есть, то можно придумывать C++, а если нет, то Оберон? Правда, с последним не все так просто. Короче, Фортран рулит, как ни крути.
PD>Фортран наша молодость
И ведь до сих пор работает. И кросплатформенность такая, что C++ и не снилась.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Одним махом уничтожается весь существующий нативный код. Он практически со 100% вероятностью не пройдет эту проверку, а значит, придется переписывать в нем очень многое.
Безусловно. Существующий код переиспользовать в безопасном контексте малореально.
PD>Далее. Представь себе, что это программа линейной алгебры. Там этих a[i][j] в каждой строке может быть по нескольку штук. Если заставлять каждое такое описание верифицировать по твоему механизму — код за этими верификациями видно уже не будет, а отладка превратится в ад.
Верно. Но речь не о математическом ПО. Его вообще писать удобнее с помощью совершенно других средств и языков.
PD>А не запретишь. И управляемые языки не помогут. Ты же ОС собрался делать, и что, ты мне скажешь, что в этой ОС писать "тяжелый" код можно только на управляемых языках ? Он и без того тяжелый, там O(N^3), например, а мне, выходит, его оптимально написать нельзя ?
Для верифицируемого нативного кода внутри ОС не так уж много применений, ИМХО — ядро, менеджер памяти, диспетчер процессов, ну может еще файловая система. Можно и поднапрячься немного.
А остальной код — просто не использует сырые указатели, как я писал вначале (при этом он может быть и не обязательно управляемым, может быть что-то типа Rust).
PD>Кроме того, почему ты решил, что массив отведен в стеке ? Для него относительно просто написать stack_available. А если в куче ? Да еще двумерный и при этом jagged ? И при этом еще и не прямоугольный, а хорошо если только треугольный ? Тебе не кажется, что такая "статическая" проверка просто не получится ?
Может я чего не понимаю, но в чем принципиальное отличие? Ну будет еще функция "heap_available". Треугольный-прямоугольный — сводится к дополнительным проверкам тех же функций. Если я неправ, покажите псевдокод, что вы имеете в виду.
PD>А еще realloc (в С) есть.
Заменяется на типизированную аллокацию (не просто сырой блок памяти).
PD>А еще union в нем же есть.
Дополняется «тегом», описывающим текущее содержимое.
PD>Что-то у меня такое ощущение, что это лекарство хуже болезни.
В некритичных к безопасности местах — да.
PD>А тут предлагается писать его совсем по-другому, с массой накладных расходов, а успех не гарантирован.
Ну, успех никогда не гарантирован. Насчет накладных расходов — они в общем случае будут больше при написании и сопровождении кода, но — опять же, в общем случае — меньше при работе программы (особенно если учесть то, что можно отказаться от аппаратной защиты в процессоре).
PD>Нет, не верю, что это пойдет.
В массы не пойдет. В ядра ОС — вполне может быть, ИМХО.
Здравствуйте, AlexRK, Вы писали:
ARK>Верно. Но речь не о математическом ПО. Его вообще писать удобнее с помощью совершенно других средств и языков. ARK>Для верифицируемого нативного кода внутри ОС не так уж много применений, ИМХО — ядро, менеджер памяти, диспетчер процессов, ну может еще файловая система. Можно и поднапрячься немного. ARK>В массы не пойдет. В ядра ОС — вполне может быть, ИМХО.
Нет, извини, давай уточним. Если бы речь шла о том, что при существующей архитектуре процессора и ОС предлагается добавить эту статическую верификацию — это одно. Ты же предлагаешь существующую архитектуру заменить такой, в которой не будет аппаратной защиты вообще. А значит, все приложения смогут делать что им вздумается, если только не помешает статическая верификация.
И тогда одно из двух. Либо ты запретишь писать на нативном коде любое несистемное ПО (а на это никто не пойдет), либо остается молиться статической верификации в надежде на то, что она безошибочна. Оба хуже.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Одним махом уничтожается весь существующий нативный код. Он практически со 100% вероятностью не пройдет эту проверку, а значит, придется переписывать в нем очень многое.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ты же предлагаешь существующую архитектуру заменить такой, в которой не будет аппаратной защиты вообще. А значит, все приложения смогут делать что им вздумается, если только не помешает статическая верификация.
Да, все верно.
PD>либо остается молиться статической верификации в надежде на то, что она безошибочна. Оба хуже.
Да, вот этот вариант. Но я не вижу, почему этот вариант менее надежен, чем аппаратная защита в процессоре. В чем принципиальная разница?
Здравствуйте, AlexRK, Вы писали:
ARK>Да, вот этот вариант. Но я не вижу, почему этот вариант менее надежен, чем аппаратная защита в процессоре. В чем принципиальная разница?
В количестве вариантов.
Аппаратная защита в процессоре, грубо говоря устроена так. Делайте там в своей программе что хотите. Процессору на все это наплевать. Как вы там адреса вычисляете, что при этом делаете — его не касается.
И только тогда, когда Вы попытаетесь получить доступ к памяти, процессор Вас проверит. Независимо от того, что Вы там до этого делали.
В сущности, у процессора лишь один вариант. Либо пропуск валиден, тогда иди, либо невалиден — тогда иди обратно.
А исполнение программы — это , вообще говоря, NP вариантов, и доказать с помощью статического анализа, что все NP этих путей не приведут к ошибке защиты — сомневаюсь.
Здравствуйте, samius, Вы писали:
PD>>Одним махом уничтожается весь существующий нативный код. Он практически со 100% вероятностью не пройдет эту проверку, а значит, придется переписывать в нем очень многое.
S>По условию топика
S>
S>Представим себе вольную фантазию.
S>Все существующее ПО одномоментно исчезло. Все.
Да. Поймал
Но все же давай договорим это до конца. Да, все ПО исчезло. Но демиург должен его воссоздать, тоже по условиям топика. Он не обязан воссоздать C/C++, но либо он обязан
1. Либо создать новый нативный язык
2. Либо запретить нативный язык как минимум для пользовательских программ. В ОС не запретишь — кто этим управляемым кодом управлять-то будет ?
3. Либо придумать что-то такое, в котором нет понятия нативного и управляемого кода (например, аппаратная Java машина)
Третье невозможно, так как демиургу не дано менять аппаратуру опять же по условиям топика. При существующей аппаратуре нативный код существует по определению.
Что из первых двух выбираешь ?
Если первое — те же проблемы, не на С++, так на ином языке. Потому что проблема не в языке, а в доступе к памяти по адресу.
Если второе — это значит, что ты ставишь всех авторов ПО для пользователя в условия, когда они не могут использовать всю мощь процессора.
Здравствуйте, Pavel Dvorkin, Вы писали:
ARK>>Да, вот этот вариант. Но я не вижу, почему этот вариант менее надежен, чем аппаратная защита в процессоре. В чем принципиальная разница? PD>В количестве вариантов.
Ну, количество вариантов в обоих случаях примерно одинаковое.
PD>В сущности, у процессора лишь один вариант. Либо пропуск валиден, тогда иди, либо невалиден — тогда иди обратно.
У валидатора так же. Либо данный кусок кода валиден, либо нет. Ему не надо смотреть всю программу — максимум только текущую функцию.
PD>А исполнение программы — это , вообще говоря, NP вариантов, и доказать с помощью статического анализа, что все NP этих путей не приведут к ошибке защиты — сомневаюсь.
А все пути исполнения проверять не нужно. Верификатор имеет дело только с входом и выходом функции. Тут нет всего возможного множества путей исполнения, мы анализируем только предусловия функции (ну, опционально еще работу с глобальными переменными, хотя лучше, конечно, без них).
Основная разница в том, что в случае аппаратной защиты рантайм-проверка выполняется автоматически самим процессором при каждом выполнении инструкции, а в случае с программной верификацией проверку инициирует программа, и не для каждой инструкции, а только там, где надо. За счет этого достигается выигрыш в скорости.
Слабое место программной верификации — это возможность аппаратных сбоев, приводящих к искажениям значений в памяти. Ну, тут ничего не поделаешь — для критичных вещей проверок надо как можно больше, а для пользовательских это не столь важно, ИМХО (потому что эксплуатировать такие сбои весьма затруднительно).
Я понимаю, что на интуитивном уровне принять такое сложно. Но, тем не менее, есть реальные примеры подобных реализаций — вышеприведенные Singularity, Verve, полагающиеся только на программные проверки.
Здравствуйте, AlexRK, Вы писали:
ARK>Основная разница в том, что в случае аппаратной защиты рантайм-проверка выполняется автоматически самим процессором при каждом выполнении инструкции, а в случае с программной верификацией проверку инициирует программа, и не для каждой инструкции,
Для аппаратной — отнюдь не для каждой инструкции, а только для тех, которые обращаются к памяти. Остальное вообще не проверяется в этом плане.
>а только там, где надо. За счет этого достигается выигрыш в скорости.
Боюсь все же, что для того, чтобы определить места "там где надо", придется проанализировать тот код, который при аппаратной защите вообще никакой проверке не подвергается.
ARK>Я понимаю, что на интуитивном уровне принять такое сложно. Но, тем не менее, есть реальные примеры подобных реализаций — вышеприведенные Singularity, Verve, полагающиеся только на программные проверки.
Если бы еще была хоть какая-то статистика о том, насколько это надежно. Если бы была информация о том, кто и как пытался ее взломать, и что из этого вышло. А так они пока что Неуловимый Джо.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Для аппаратной — отнюдь не для каждой инструкции, а только для тех, которые обращаются к памяти. Остальное вообще не проверяется в этом плане.
Да, я говорю про такие инструкции.
>>а только там, где надо. За счет этого достигается выигрыш в скорости. PD>Боюсь все же, что для того, чтобы определить места "там где надо", придется проанализировать тот код, который при аппаратной защите вообще никакой проверке не подвергается.
Проанализировать придется, но только во время компиляции. Во время выполнения накладных расходов будет, в общем случае, меньше.
double Log10(double d)
requires d > 0
{
// вычисляем логарифм, никаких проверок нет - аргумент "d" гарантированно больше нуля
}
void Test1(double val)
{
//double log1 = Log10(val); // упс, не компилируется, нам неизвестен интервал "val"if (val > 0) // единственная проверка, которая останется в машинном коде
{
double log2 = Log10(val); // отлично, компилируется - мы проверили val и точно знаем, что он положителен
}
}
void Test2(double val)
requires val > 0 // предусловие гарантирует положительный "val"
{
double log1 = Log10(val); // а вот сейчас всё компилируется и без проверок - все проверки должен сделать тот, кто вызывает эту функцию
}
Как видите, мы не смотрим за границы функций — что пришло, то и анализируем. Причем только во время компиляции, во время выполнения никакого анализа не происходит, равно как и "лишних" проверок.
PD>Если бы еще была хоть какая-то статистика о том, насколько это надежно. Если бы была информация о том, кто и как пытался ее взломать, и что из этого вышло. А так они пока что Неуловимый Джо.
Пока что в промышленной эксплуатации такое применяется ограниченно (в основном аэрокосмическое ПО), так что да, тут пока непонятно.
Конечно, возможности логики первого порядка тоже не бесконечны, поэтому какие-то особо сложные предусловия или постусловия писать не выйдет. Компьютер, конечно, не сможет доказать теорему Пуанкаре. Но оно в ядрах ОС и не нужно.
А что мне делать, если я вообще не могу сказать, что она ensures ? Ничего она не гарантирует, не могу я гарантию дать. Вообще-то этот calls_a_tree_of_subfunctions , надеюсь, вернет >0, иначе что-то не в порядке с моим алгоритмом, ну а если все же иногда может <0 вернуть ? При обычном подходе, если есть подозрения — поставил try-catch, и все дела.
Например, некий приближенный алгоритм, исполняемый на ряде samples. Лучшего, увы, нет. А этот приближенный алгоритм, поскольку он приближенный, на некоторых sample может вообще ерунду выдать, на ноль поделить, INF устроить, логарифм от отрицательного числа брать. По условиям проекта мне разрешено этот sample просто отбросить — ну не смог .
Пример вполне реальный, был в такой ситуации, хоть и немного иначе.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А что мне делать, если я вообще не могу сказать, что она ensures ? Ничего она не гарантирует, не могу я гарантию дать. Вообще-то этот calls_a_tree_of_subfunctions , надеюсь, вернет >0, иначе что-то не в порядке с моим алгоритмом, ну а если все же иногда может <0 вернуть ? При обычном подходе, если есть подозрения — поставил try-catch, и все дела. PD>Например, некий приближенный алгоритм, исполняемый на ряде samples. Лучшего, увы, нет. А этот приближенный алгоритм, поскольку он приближенный, на некоторых sample может вообще ерунду выдать, на ноль поделить, INF устроить, логарифм от отрицательного числа брать. По условиям проекта мне разрешено этот sample просто отбросить — ну не смог . PD>Пример вполне реальный, был в такой ситуации, хоть и немного иначе.
Здравствуйте, AlexRK, Вы писали:
ARK>Тогда просто еще проверка:
<skipped>
Ну и к чему мы пришли ?
В некоторых (относительно простых) случаях получается , верно, статический анализ. А в более сложных случаях — приходится вставлять условие, то есть проверять в рантайме, не статически. Фактически ты заставишь программиста писать все эти проверки в коде, вместо того, чтобы пустить все на нормальный самотек и ловить исключения, если он потек не туда.
Так я и с памятью могу в принципе обойтись без аппаратной проверки. Точнее, не обойтись, а сделать так, что она всегда будет успешной. Заведу у себя свой код, проверяющий при каждом обращении
к памяти указатель на валидность. Своя таблица допустимых адресов и размеров и проверка по ней. В общем, welcome to IndexOutOfBoundException в нативном варианте.
Вот только быстрее это не будет. Потому что 99.9% обращений обычно валидны, так что тут лишние проверки, и ничего больше.
А аппаратный контроль — это по сути тот же подход — пустить на самотек и ловить исключение в случае неприятности. В 99.9% их и не будет. Кстати, я не уверен даже в том, что там все проверки производятся. Если, скажем, *p обращение прошло, будет ли проверка по *(p+1), если это в пределах одной страницы ? Мне кажется, при этом TLB сработает, и проверки фактически не будет. Возможно, ошибаюсь.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В некоторых (относительно простых) случаях получается , верно, статический анализ. А в более сложных случаях — приходится вставлять условие, то есть проверять в рантайме, не статически. Фактически ты заставишь программиста писать все эти проверки в коде, вместо того, чтобы пустить все на нормальный самотек и ловить исключения, если он потек не туда.
Да, всё верно.
PD>Вот только быстрее это не будет. Потому что 99.9% обращений обычно валидны, так что тут лишние проверки, и ничего больше. PD>А аппаратный контроль — это по сути тот же подход — пустить на самотек и ловить исключение в случае неприятности. В 99.9% их и не будет. Кстати, я не уверен даже в том, что там все проверки производятся. Если, скажем, *p обращение прошло, будет ли проверка по *(p+1), если это в пределах одной страницы ? Мне кажется, при этом TLB сработает, и проверки фактически не будет. Возможно, ошибаюсь.
Вы забываете про переключения контекста, которые очень сильно снижают производительность и выполняются в стстемах с аппаратной защитой _постоянно_. Статическая верификация позволяет выполнять весь код в одном «кольце» (да, собственно, кольца вообще не нужны).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Далее. Представь себе, что это программа линейной алгебры. Там этих a[i][j] в каждой строке может быть по нескольку штук. Если заставлять каждое такое описание верифицировать по твоему механизму — код за этими верификациями видно уже не будет, а отладка превратится в ад. http://halide-lang.org/ рвёт С++ как тузик грелку.
При этом он делает все эти проверки.
Но делает их умно. Не на каждое a[i][j], а один раз на всю цепочку операций.
PD>А не запретишь. И управляемые языки не помогут.
То что ты не знаешь как не значит что это сделать нельзя.
Твоя проблема в том, что ты за пределами С++ ничего даже не пытаешься изучать.
Там математически доказано что код:
1)Не выходит за пределы массива.
2)Результирующий массив является перестановкой исходного массива.
3)Результирующий массив отсортирован.
4)Код завершается.
Всё что находится внутри requires, ensures и invariant работает исключительно на этапе компиляции и на результирующий код не влияет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но все же давай договорим это до конца. Да, все ПО исчезло. Но демиург должен его воссоздать, тоже по условиям топика. Он не обязан воссоздать C/C++, но либо он обязан
PD>1. Либо создать новый нативный язык PD>2. Либо запретить нативный язык как минимум для пользовательских программ. В ОС не запретишь — кто этим управляемым кодом управлять-то будет ? PD>3. Либо придумать что-то такое, в котором нет понятия нативного и управляемого кода (например, аппаратная Java машина)
PD>Третье невозможно, так как демиургу не дано менять аппаратуру опять же по условиям топика. При существующей аппаратуре нативный код существует по определению.
PD>Что из первых двух выбираешь ?
Но это ведь не взаимоисключающие вещи.
PD>Если первое — те же проблемы, не на С++, так на ином языке. Потому что проблема не в языке, а в доступе к памяти по адресу. PD>Если второе — это значит, что ты ставишь всех авторов ПО для пользователя в условия, когда они не могут использовать всю мощь процессора.
А разве статическая верификация программы на нативном языке как-то ограничивает мощь процессора?
Вот чисто что бы ради поржать, предлагаю специальный режим многозадачности: программы с недоказанной корректностью обращений к памяти не могут выполняться одновременно с программами, которым нужна гарантия недоступности их памяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> А что мне делать, если я вообще не могу сказать, что она ensures ? Ничего она не гарантирует, не могу я гарантию дать. Вообще-то этот calls_a_tree_of_subfunctions , надеюсь, вернет >0, иначе что-то не в порядке с моим алгоритмом, ну а если все же иногда может <0 вернуть ?
А вот для этого есть branch prediction. Он позволяет исполнять код быстро при наличии runtime-проверки когда всё в порядке и по сути аналог try-catch когда что-то пошло не так.
Здравствуйте, MTD, Вы писали:
MTD>2. HTML, CSS, гуевые фреймворки на помоечку, вместо всего этого универсальный язык разметки с размерами в миллиметрах (отобразить правильно задача драйвера железки) для всего от принтеров, до экрана телефона. Все иконки строго векторные
А задача армии дизайнеров и верстальщиков, сверстать дизайн в миллиметрах для каждого экрана.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А защита ? Ты предлагаешь ее на чисто софтверном уровне делать ? Но тогда и проверять каждый раз придется с использованием ПО, это вряд ли будет быстро
Нет. Современные среды работают не так. PD>char * p = чему-то PD>*p = 0; PD>И как здесь на софтверном уровне проверять, имею ли я право доступа туда ? Встраивать на каждый mov команды проверки ?
Как в C# или Java — происходит статическая верификация кода. "Случайных" указателей в коде не бывает. Нельзя просто взять квадратный корень из Pi и использовать в качестве указателя. PD>Вопрос не в ограничениях, а в архитектуре. Тебе не кажется, что тот же интерфейс GET с параметрами можно бы на что-то более элегантное заменить ? И заодно Header переделать.
У GET нет никаких параметров. Там же только URI. Куда элегантнее-то? Расширить набор поддерживаемых символов? Зачем?...
С заголовками тоже всё хорошо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
поскольку всё получилось так из-за гравитации, а её трогать нельзя...
то тогда надо бы только отказаться от статической типизации и разрешить жалкоскриптерам работать только в водолазном костюме.
Здравствуйте, Ziaw, Вы писали:
Z>А задача армии дизайнеров и верстальщиков, сверстать дизайн в миллиметрах для каждого экрана.
Вот смотри. Палец среднестатистического человека, допустим имеет пятно контакта 5 на 5 мм, из этого следует, что надо кнопочку сделать 10 на 10 мм, условно. Потом, есть текст, известно, что он хорошо читается размером 7 мм, тоже условно. Если задавать размеры в мм, то и выглядеть везде будет одинаково и взаимодействовать будет возможно одинаково. Еще раз — 1 раз задать, получить одно и тоже везде. Теперь переходим к условным попугаям в пикселах — в зависимости от плотности пикселов размер меняется в разы, так что твой комментарий актуален сейчас, если перейти на миллиметры жизнь серьезно упроститься.
Здравствуйте, ·, Вы писали:
·>Поясни, плиз, немного. Как доказать, что в этом доказательстве нет ошибки?
Никак.
Расчет на то, что "если ошибка есть, где-нибудь что-нибудь не сойдется" (и это часто так и есть).
Но доказать это невозможно. Надо писать еще одно доказательство более высокого порядка.
ARK>Вы забываете про переключения контекста, которые очень сильно снижают производительность и выполняются в стстемах с аппаратной защитой _постоянно_. Статическая верификация позволяет выполнять весь код в одном «кольце» (да, собственно, кольца вообще не нужны).
Почему они выполняются постоянно ? Они выполняются при переключении процессов, при системных вызовах и еще в некоторых случаях. Если я просто обращаюсь к юзермодным страницам памяти — никаких переключений контекста не будет.
Здравствуйте, samius, Вы писали:
PD>>Что из первых двух выбираешь ? S>Но это ведь не взаимоисключающие вещи.
Хорошо, давай свой гибрид.
S>А разве статическая верификация программы на нативном языке как-то ограничивает мощь процессора?
Нет, конечно, но я не уверен, что она гарантирует то, что требуется.
S>Вот чисто что бы ради поржать, предлагаю специальный режим многозадачности: программы с недоказанной корректностью обращений к памяти не могут выполняться одновременно с программами, которым нужна гарантия недоступности их памяти.
И на каждую программу ставится клеймо, а в ОС вводим 2 режима и переключаемся между ними для того, чтобы запустить какую-то программу, которая текущему режиму не соответствует
Здравствуйте, Sinclair, Вы писали:
S>Как в C# или Java — происходит статическая верификация кода. "Случайных" указателей в коде не бывает. Нельзя просто взять квадратный корень из Pi и использовать в качестве указателя.
Спасибо, я не знал
PD>>Вопрос не в ограничениях, а в архитектуре. Тебе не кажется, что тот же интерфейс GET с параметрами можно бы на что-то более элегантное заменить ? И заодно Header переделать. S>У GET нет никаких параметров. Там же только URI. Куда элегантнее-то? Расширить набор поддерживаемых символов? Зачем?...
c упаковкой параметров через '&" и знаком вопроса не кажется особенно элегантным. Для 1990 года он был хорош, но сейчас все же можно и что-то лучше структурированное предложить.
Напоминаю, что речь идет о демиурге — аргументы о том, что это в каждом месте, не принимаются.
S>С заголовками тоже всё хорошо.
И вот тут я не уверен. Формат "список ключ:значение" можно было бы тоже на что-то более структурированное заменить.
По существу, HTTP запрос — это же просто вызов некоторого метода клиентом через сеть на сервере. Своего рода RPC. И этому методу надо параметры передать.
Если бы ты (демиург) в момент, когда старое ПО уже уничтожено, а новое еще не создано, стал бы проектировать способ передачи параметров — ты точно сделал бы ее передачу в двух местах (а для POST/PUT и в 3 — json/xml в body) и в таком формате ?
Здравствуйте, WolfHound, Вы писали:
WH>То что ты не знаешь как не значит что это сделать нельзя. WH>Твоя проблема в том, что ты за пределами С++ ничего даже не пытаешься изучать.
Ответить мог бы, но твоя манера сразу переходить на личности отбивает желание отвечать.
Скажу лишь, что на С++ я уже несколько лет, увы, не пишу.
Здравствуйте, Pavel Dvorkin, Вы писали:
ARK>>Вы забываете про переключения контекста, которые очень сильно снижают производительность и выполняются в стстемах с аппаратной защитой _постоянно_. Статическая верификация позволяет выполнять весь код в одном «кольце» (да, собственно, кольца вообще не нужны).
PD>Почему они выполняются постоянно ? Они выполняются при переключении процессов, при системных вызовах и еще в некоторых случаях. Если я просто обращаюсь к юзермодным страницам памяти — никаких переключений контекста не будет.
Планировщик ОС работает постоянно и переключения контекста происходят много раз в секунду. В Singularity замеряли — скорость переключения между процессами в 3 раза быстрее, чем переключение контекста в традиционных системах.
Да если даже говорить только о системных вызовах — много ли вы сможете сделать без них? В типичных приложениях они происходят постоянно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ответить мог бы, но твоя манера сразу переходить на личности отбивает желание отвечать.
Это по тому что тебе ответить нечего.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
·>Поясни, плиз, немного. Как доказать, что в этом доказательстве нет ошибки?
Компилятор проверяет.
Для того чтобы доказать, что в компиляторе нет ошибок достаточно доказать очень простую и маленькую часть компилятора.
А её доказывают так же как доказывают математические теоремы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Я за то чтобы разработчики использовали только ООП или декларативное программирование (ДП) и как можно реже опускались на уровень процедурного программирования. Я не против процедурного программирования в принципе, иногда статические классы или синглтоны упрощают решение задачи, но они не должны быть основой архитектуры. Архитектура должна быть объектно-ориентированной или декларативной, но не процедурно-ориентированной. Тем не менее сейчас в ходу SOA, в которой сервисы процедурные. При взаимодействие с БД, современное декларативное богатство SQL скрывается за первобытным процедурным подходом (SOAP или хранимые процедуры). Я за то чтобы БД была SQL сервисом. Для взаимодействия с no SQL компонентом архитектуры я бы развивал что-то наподобие DCOM.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Sinclair, Вы писали:
S>Возможностями по декомпозиции и по диагностике ошибок.
Если не правильно составил запрос -- логическая ошибка, как типизация поможет? А вот жизнь всем разработчикам субд осложнила бы. Да и от диалектов это бы не спасло.
Про декомпозицию вообще не понял.
Здравствуйте, AlexRK, Вы писали:
ARK>Планировщик ОС работает постоянно и переключения контекста происходят много раз в секунду.
Совершенно верно, много раз в секунду. Именно много раз. Но по сравнению с временем выполнения команд это очень редко делается.
>В Singularity замеряли — скорость переключения между процессами в 3 раза быстрее, чем переключение контекста в традиционных системах.
Вполне возможно, вот только вопрос в проценте времени, уходящем на эти переключения процессов. В Windows WorkStation размер кванта 2 таймерных интервала, в Server — 12. Если за это время поток сам не освободит процессор (сон, ожидание и т.п.), то посчитай, сколько команд он успеет выполнить за эти 2 или 12 таймерных интервала(ов) , и без всякого переключения контекста, если не будет того, о чем пишу ниже.
Ну и еще один момент. Переключение процессов в настольной системе — это (не всегда, конечно) следствие того, что пользователь выбрал иное окно. По той причине, что потоки оконных приложений, пока пользователь с их окнами не работает, в Windows обычно спят и процессор не загружают. А активация окна спящего GUI — потока — это такое количество всяких действий, на фоне которого переключение контекста есть всего лишь мелочь. Одна отрисовка окна чего стоит.
ARK>Да если даже говорить только о системных вызовах — много ли вы сможете сделать без них? В типичных приложениях они происходят постоянно.
Постоянно, но очень редко. В основном при системных вызовах, ну и, конечно, при SEH исключениях. Тут и впрямь много. Но все же количество системных вызовов в секунду крайне невелико по сравнению с количеством обычных операций.
1)Запретить языки с динамической типизацией.
Недостатки:
а)Тормоза.
б)Потребление памяти на ровном месте.
в)Не ловят ошибки программистов.
г)Невозможно создать качественную IDE.
Достоинство:
Нужно писать меньше кода по сравнению с явой.
По сравнению с немерле разница становится минимальной. И на практике не всегда в пользу динамически типизированных языков. Ибо они примитивные.
2)Запретить нативный код.
Проблема нативного кода в том, что он не даёт заменять систему команд процессоров.
Через пару лет после того как не станет нативного кода x86 сдохнет.
Исключение можно сделать только для совсем дохлых микропроцессоров где даже ОС нет.
mutable, readonly и immutable становятся атрибутами кластеров.
в)Добавляем http://halide-lang.org/ для параллельного программирования.
г)Заменяем контракты на это: https://www.microsoft.com/en-us/research/project/dafny-a-language-and-program-verifier-for-functional-correctness/
Учим компилятор вставлять рантайм проверки в тех местах где он не смог статически доказать корректность.
Если проверка провалилась, то молча прибиваем процесс.
Если статически доказано что ошибка будет всегда, то выдаём ошибку компиляции.
Обоснование тут: http://joeduffyblog.com/2016/02/07/the-error-model/
Делаем 3 уровня:
1)Никогда не вставлять. Если программист что-то не доказал выдаём ошибку.
2)Всегда вставлять, но вместо ошибки выдавать предупреждение.
3)Молча вставлять.
Большая часть кода будет всегда жить в третьем режиме. В этом случае мы получаем код в стиле явы и C#. Но так как пред и пост условия всё равно можно будет писать то большая часть проверок будет выполнена статически. И код будет быстрее.
Более того ошибки будут обнаружены там, где они произошли, а не где попало.
Второй режим нужен при начальном написании ответственного кода.
Сначала пишем в третьем режиме. Ибо писать сразу в первом довольно трудно. Когда код написан переходим во второй и начинаем доказывать. Когда все предупреждения закончились переключаем в первый.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>·>Поясни, плиз, немного. Как доказать, что в этом доказательстве нет ошибки? WH>Компилятор проверяет. WH>Для того чтобы доказать, что в компиляторе нет ошибок достаточно доказать очень простую и маленькую часть компилятора. WH>А её доказывают так же как доказывают математические теоремы.
Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CoderMonkey, Вы писали:
CM>Что ж так мелочиться то? Развитие железа зашло в жестокий тупик, а недавние (но наверняка не последние) уязвимости уже забивают крышку гроба гвоздями.
Я бы иначе сказал. Развитие, да, если не прекратилось, то сильно затормозилось. Но ни из чего не следует, что он должно продолжаться вечно. Возможно, мы просто пришли к пределу. А он гарантированно есть по крайней мере пока в силах ОТО и 300000 км/сек.
В конце концов все технологии на данной материальной основе раньше или позже подходят к своему пределу, чем-то обусловленному.
CM>Нужно новое железо!
Смайлик заметил, но если серьезно, то ни из чего не следует, что при нынешней элементной базе оно вообще возможно.
Здравствуйте, Sharov, Вы писали:
S>В чем проблема пересобрать? Исполняющая среда по-любому будет пересобрана. Ну да, выигрыш в кол-ве пересборов. Не думаю, что это так критично.
Это фатально.
Исполняемую среду и низкой уровень ОС адаптирует и пересоберёт разработчик процессора. Это не маленький объём работы, но разработчик процессора справится без проблем. Сделать новый процессор намного труднее.
А теперь попробуй заставить всех разработчиков программ выпускать свои программы еще и под новый процессор. Это не реально. Итаниум сдох по тому что народ не захотел пересобрать программы.
Особенно если вспомнить что есть программы, на поддержку которых разработчик давно забил, разработчика больше нет или исходники потерялись.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ·, Вы писали:
·>Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например?
Такое быть не может.
Ибо у индексера массива есть вот такое предусловие
0 <= i < array.Length
И если это условие не доказано программа просто не скомпилируется.
Можешь поиграть с онлайн компилятором: https://rise4fun.com/Dafny/pX4N
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Исполняемую среду и низкой уровень ОС адаптирует и пересоберёт разработчик процессора. Это не маленький объём работы, но разработчик процессора справится без проблем. Сделать новый процессор намного труднее.
Не вижу проблемы, учитывая что реально новый процессоры появляются раз в 10,а то и 20 лет.
WH>А теперь попробуй заставить всех разработчиков программ выпускать свои программы еще и под новый процессор. Это не реально. Итаниум сдох по тому что народ не захотел пересобрать программы.
Если не ошибаюсь, Итаниум сдох не дойдя до народа -- для него крайне сложно оказалось написать хороший компилятор.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>>>Что из первых двух выбираешь ? S>>Но это ведь не взаимоисключающие вещи.
PD>Хорошо, давай свой гибрид.
Гибрид необязателен. Берем C++ и верификатор. Я не призываю его брать после пропажи всего софта, я просто показываю что выбор не ограничен двумя пунктами.
S>>А разве статическая верификация программы на нативном языке как-то ограничивает мощь процессора?
PD>Нет, конечно, но я не уверен, что она гарантирует то, что требуется.
Если не гарантирует, то значит программу нельзя запускать одновременно с теми, которые требуют гарантии недоступа.
S>>Вот чисто что бы ради поржать, предлагаю специальный режим многозадачности: программы с недоказанной корректностью обращений к памяти не могут выполняться одновременно с программами, которым нужна гарантия недоступности их памяти.
PD>И на каждую программу ставится клеймо, а в ОС вводим 2 режима и переключаемся между ними для того, чтобы запустить какую-то программу, которая текущему режиму не соответствует
Это не два режима, это чуть по-другому работающий шедулер. Все равно его с нуля писать.
Здравствуйте, samius, Вы писали:
S>Гибрид необязателен. Берем C++ и верификатор. Я не призываю его брать после пропажи всего софта, я просто показываю что выбор не ограничен двумя пунктами.
Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
S>Если не гарантирует, то значит программу нельзя запускать одновременно с теми, которые требуют гарантии недоступа. S>>>Вот чисто что бы ради поржать, предлагаю специальный режим многозадачности: программы с недоказанной корректностью обращений к памяти не могут выполняться одновременно с программами, которым нужна гарантия недоступности их памяти. PD>>И на каждую программу ставится клеймо, а в ОС вводим 2 режима и переключаемся между ними для того, чтобы запустить какую-то программу, которая текущему режиму не соответствует S>Это не два режима, это чуть по-другому работающий шедулер. Все равно его с нуля писать.
Вот тут не понял. Писать с нуля, конечно, придется. Но в итоге хочу я одновременно иметь 2 работающих приложения. И вариант, что мы с одного на другое переключаемся так, что когда одно работает, другое работать не имеет права, не принимается — это уже не многопрограммный режим, а бог знает что. Одно приложение с недоказанной корректностью обращений к памяти (какой-то фоновый процесс, которому часами работать надо), другое — нужна гарантия недоступности их памяти. И что делать ?
Здравствуйте, WolfHound, Вы писали:
WH>·>Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например? WH>Такое быть не может.
Угу, конечно. Ошибок в доказательстве быть не может.
Запросто может быть что угодно, причем доказать доказательство будет на порядки сложнее, чем обычный код.
WH>Можешь поиграть с онлайн компилятором: https://rise4fun.com/Dafny/pX4N
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
Ну так а в чем разница с дырой в процессоре?
Одна дыра — и мало не покажется, не заштопаешь. Процессор уже на компьютере пользователя, этап разработки и производства процессора позади, иной защиты нет, не поправишь, как Meltdown.
Здравствуйте, Sharov, Вы писали:
WH>>Исполняемую среду и низкой уровень ОС адаптирует и пересоберёт разработчик процессора. Это не маленький объём работы, но разработчик процессора справится без проблем. Сделать новый процессор намного труднее. S>Не вижу проблемы, учитывая что реально новый процессоры появляются раз в 10,а то и 20 лет.
Так я и говорю, что проблемы не будет если убрать нативный код.
Не пойму ты со мной споришь или соглашаешься.
S>Если не ошибаюсь, Итаниум сдох не дойдя до народа -- для него крайне сложно оказалось написать хороший компилятор.
Компилятор дело техники. Если нет нативного кода, то его нужно написать один раз. И интел в конце концов написал.
А вот то что он тормозил в 10 раз на исполнении x86'ого кода его и убило.
Emulation to run existing x86 applications and operating systems was particularly poor, with one benchmark in 2001 reporting that it was equivalent at best to a 100 MHz Pentium in this mode (1.1 GHz Pentiums were on the market at that time).
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexRK, Вы писали:
PD>>Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
ARK>Ну так а в чем разница с дырой в процессоре?
Разница в том, что Meltdown заштопали вроде как. С накладными расходами, но заштопали.
Потому что это все же дыра на уровне процессора, а у процессора есть kernel mode и user mode, и в kernel mode пользовательские программы не пускают ни под каким видом, а у kernel mode есть хозяин (ОС) , в которую только и нужно внести изменения, что и было сделано.
А вот что будут делать, если в алгоритме статической верификации обнаружилась ошибка, а программы уже прошли этап этой верификации, разошлись в миллионах копий и теперь рушат ОС или получают доступ к чужой памяти — объясни. Срочно патчить все выпущенные программы ? Как ? Фирма, выпустившая эту программу, давно закрылась, авторы разбрелись кто куда.
Я уж не говорю о том, что заставить пользователей быстро поменять программу, даже если есть на что менять — задача почти безнадежная.
Здравствуйте, MTD, Вы писали:
MTD>1. Никаких кодировок кроме utf-8
Почему не UTF-16 или UTF-32?
MTD>2. HTML, CSS, гуевые фреймворки на помоечку, вместо всего этого универсальный язык разметки с размерами в миллиметрах (отобразить правильно задача драйвера железки) для всего от принтеров, до экрана телефона. Все иконки строго векторные
Идея с универсальным языком для отображения на всех устройствах — хорошая. Каким он должен быть? Похожим на PostScript или попроще?
Здравствуйте, Pavel Dvorkin, Вы писали:
ARK>>Ну так а в чем разница с дырой в процессоре?
PD>Разница в том, что Meltdown заштопали вроде как. С накладными расходами, но заштопали. PD>Потому что это все же дыра на уровне процессора, а у процессора есть kernel mode и user mode, и в kernel mode пользовательские программы не пускают ни под каким видом, а у kernel mode есть хозяин (ОС) , в которую только и нужно внести изменения, что и было сделано.
Я говорю не о Meltdown, а о такой дыре, которую заштопать невозможно (и которая, вполне возможно, присутствует в современных процессорах).
PD>А вот что будут делать, если в алгоритме статической верификации обнаружилась ошибка, а программы уже прошли этап этой верификации, разошлись в миллионах копий и теперь рушат ОС или получают доступ к чужой памяти — объясни. Срочно патчить все выпущенные программы ? Как ? Фирма, выпустившая эту программу, давно закрылась, авторы разбрелись кто куда.
А что вы будете делать, если в процессоре найдут дыру, которую невозможно заштопать удаленными средствами? Процессоры разошлись в миллионах копий и теперь рушат ОС. Срочно менять все компьютеры?
Или вы считаете, что такой дыры в процессоре быть не может в принципе?
Если такой дыры в процессоре даже теоретически быть не может, то почему тогда вы считаете, что такая дыра может быть в верификаторе?
Если такая дыра в процессоре теоретически возможна, то чем подход с защитой в процессоре лучше подхода с защитой путем верификации?
Здравствуйте, AlexRK, Вы писали:
ARK>Угу, конечно. Ошибок в доказательстве быть не может.
Конечно не может. Его машина проверяет.
Единственный шанс ошибки проскочить это если верификатор сломается.
А он очень простой. И его не трудно доказать.
ARK>Запросто может быть что угодно, причем доказать доказательство будет на порядки сложнее, чем обычный код.
Ну попробуй написать код, который выходит за приделы массива.
Править предусловия массива то ты не можешь.
ARK>Все корректно проверяется, только вот программа будет выдавать совершеннейший мусор.
То, что ты сделал можно сделать проще. Достаточно просто выкинуть предикаты SortedRange и PremutateRange и всё.
В реальной жизни предикаты SortedRange и PremutateRange будут лежать в стандартной библиотеке. И эта баблиотека будет изучена и протестирована до дыр.
И изменить их ты не сможешь.
И маразм дафны с old(a[..]) тоже можно устранить.
А вот теперь попробуй, используя оригинальные предикаты и их правильное использование написать что-то кроме сортировки.
Ну и главное не забудь обратиться за приделы массива.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
Это просто курам на смех. Обновить ОС куда проще. После чего ОС перепроверит весь установленный софт.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну попробуй написать код, который выходит за приделы массива. WH>Править предусловия массива то ты не можешь.
Понятно, что я не смогу выйти за пределы массива. Речь о том, что само по себе доказательство может содержать логические ошибки и доказывать совсем не то, что имел в виду автор. Или вообще не доказывать (хотя автор уверен, что доказательство работает). Вот об этом речь. И такие вещи поймать будет ой как сложно.
WH>А вот теперь попробуй, используя оригинальные предикаты и их правильное использование написать что-то кроме сортировки. WH>Ну и главное не забудь обратиться за приделы массива.
Да и и в C# не могу выйти за пределы массива, без всяких предикатов.
Конечно, ошибка компиляции всегда лучше рантайм-ошибки, но в массы такие доказательства точно не пойдут.
Здравствуйте, AlexRK, Вы писали:
ARK>Понятно, что я не смогу выйти за пределы массива.
Теперь смотрим на что я отвечал:
Ну в смысле если в паре мест перепутать "<" и "<=" или "a" и "b" — компилятор гарантированно обнаружит ошибку? Или просто получится какое-то другое доказательсто — логически верное с т.з. компилятора, но иногда допускающее выход за границы массива, например?
ARK>Речь о том, что само по себе доказательство может содержать логические ошибки и доказывать совсем не то, что имел в виду автор. Или вообще не доказывать (хотя автор уверен, что доказательство работает). Вот об этом речь. И такие вещи поймать будет ой как сложно.
Доказательствами будет заниматься очень небольшой процент высококвалифицированных программистов.
ARK>Конечно, ошибка компиляции всегда лучше рантайм-ошибки, но в массы такие доказательства точно не пойдут.
И не надо.
Перечитай вторую половину вот этого сообщения
Здравствуйте, AlexRK, Вы писали:
ARK>Я говорю не о Meltdown, а о такой дыре, которую заштопать невозможно (и которая, вполне возможно, присутствует в современных процессорах). ARK>Или вы считаете, что такой дыры в процессоре быть не может в принципе? ARK>Если такой дыры в процессоре даже теоретически быть не может, то почему тогда вы считаете, что такая дыра может быть в верификаторе? ARK>Если такая дыра в процессоре теоретически возможна, то чем подход с защитой в процессоре лучше подхода с защитой путем верификации?
Мы тут уже в область абстракций переходим. Пока что дыры такой нет, и жизнь вполне себе идет. Если найдется — не знаю, что будет. Но пока что за 40 лет такого не оказалось.
Если будет реально сделана ОС с этой самой статической верификацией, если ее не взломают через полгода, если она пойдет по другим критерием — тогда видно будет.
В реальность этого я плохо верю.
Что-то мне интуиция подсказывает, что такое предложить рынку всерьез ни одна фирма не решится. Эксперименты — да, пожалуйста.
На этом предлагаю дискуссию и закончить, тем более, что через день я уезжаю, а там, где буду, Интернет крайне плохой, и не уверен, что я хоть что-то напишу. Да и не любитель я писать с телефона.
Здравствуйте, WolfHound, Вы писали:
WH>Не пойму ты со мной споришь или соглашаешься.
Спорю с тем, что натив не нужен.
WH>Компилятор дело техники. Если нет нативного кода, то его нужно написать один раз. И интел в конце концов написал. WH>А вот то что он тормозил в 10 раз на исполнении x86'ого кода его и убило.
Переписывая по сути с нуля ОС, субд и вот это вот все. Разумеется не взлетит.
Здравствуйте, WolfHound, Вы писали:
PD>>Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown. WH> WH>Это просто курам на смех. Обновить ОС куда проще. После чего ОС перепроверит весь установленный софт.
И сообщит пользователю, что его любимая программа, которая сейчас вылетает по access violaltion один раз в полгода, будет удалена с компьютера, так как она эту новую верификацию не прошла.
Куры плачут уже, а не смеются.
Пользователи говорят <censored> и сносят эту ОС.
Здравствуйте, MTD, Вы писали:
Z>>А задача армии дизайнеров и верстальщиков, сверстать дизайн в миллиметрах для каждого экрана. MTD>Вот смотри. Палец среднестатистического человека, допустим имеет пятно контакта 5 на 5 мм, из этого следует, что надо кнопочку сделать 10 на 10 мм, условно. Потом, есть текст, известно, что он хорошо читается размером 7 мм, тоже условно. Если задавать размеры в мм, то и выглядеть везде будет одинаково и взаимодействовать будет возможно одинаково. Еще раз — 1 раз задать, получить одно и тоже везде. Теперь переходим к условным попугаям в пикселах — в зависимости от плотности пикселов размер меняется в разы, так что твой комментарий актуален сейчас, если перейти на миллиметры жизнь серьезно упроститься.
В миллиметрах — это тоже не верно, потому что для человеческого взгляда важен угловой размер, а не линейный. Т.е. 7мм на смартфоне и на телевизоре — это очень разные вещи, из-за того, что их рассматривают с разного расстояния. Более того, есть ещё и различные особенности зрения (близорукость там и т.п.), из-за которых пользователи предпочитают менять под себя стандартный размер шрифтов. Так что жёсткое зашивание размеров элементов GUI в миллиметрах — это опять же пример плохой реализации GUI.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И сообщит пользователю, что его любимая программа, которая сейчас вылетает по access violaltion один раз в полгода, будет удалена с компьютера, так как она эту новую верификацию не прошла.
Есть и другой вариант.
ОС находит те места, которые не может верифицировать и добавляет туда проверку.
Сделать это можно полностью автоматически. Примерно так же как это делает ява и компания.
Приложение немного замедлится, но будет работать.
Пользователь скорее всего ничего даже не заметит.
PD>Куры плачут уже, а не смеются. PD>Пользователи говорят <censored> и сносят эту ОС.
Либо в клиническом случае пользователи качают патч на эту программу и всё.
Ты кстати в курсе что винда молча при запуске исправляет некоторые популярные программы чтобы они работали.
Так что тут опять нет ничего нерешаемого.
Ну и не забывай о том, что мы говорим о крайне гипотетической ситуации.
Ибо верификатор на несколько порядков проще чем процессор.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
WH>>Компилятор дело техники. Если нет нативного кода, то его нужно написать один раз. И интел в конце концов написал. WH>>А вот то что он тормозил в 10 раз на исполнении x86'ого кода его и убило. S>Переписывая по сути с нуля ОС, субд и вот это вот все. Разумеется не взлетит.
Это нужно исключительно из-за того код нативный.
Если бы код был под ВМ, то никакого переписывания было бы не нужно.
Всё просто бы заработало.
Объём переделок в случае с ВМ только бэкенд и очень маленькая часть ядра ОС.
Объём работы сопоставимый с адаптацией одного компилятора под новый процессор.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
— Другие сетевые протоколы в сети Internet. Помимо личного адреса каждой кофеварке, должны обеспечивать идентификацию, аутентификацию и шифрование для каждого каждого узла в сети. сетевой адрес должен быть прибит гвоздями к конкретной железке и провайдеру
— Стандартный байткод. Все языки высокого уровня, как со сборкой мусора, так и без неё, компилируются только в него. Компиляторы в нативный код стоят на машинах конечных пользователей и понимают только стандартный байткод. У стандартного байткода есть "безопасное" подмножество, программы на котором можно использовать в песочницах типа браузера.
— Полная aппаратная и программная поддержка изоляции процессов в ОС.
— Единый стандарт взаимодействия программ с ОС. POSIX был хорош, но недостаточен.
— Единый стандарт платформ для дистрибьюции софта, включая платный софт. Включая платные библиотеки, входящие в платный софт
— Компании, которые специализируются на разработке платных библиотек и рантаймов с монетизацией "0.1% с каждой проданной программы, которая использует нашу либу"
Здравствуйте, WolfHound, Вы писали:
WH>1)Запретить языки с динамической типизацией.
Даже для 3-ёх строчных скриптов? ) Вот буквально вчера у меня тут обнаружилось, что fb2 файлы скаченные с одного известного сайта имеют некорректную структуру (содержат html entities, хотя fb2 — это обычный xml) и из-за этого не читаются некоторым ПО. Проблема была решена (причём для целой папки таких fb2 файлов за раз) за минуту в три строчки на Питоне. На популярных статических языках я бы к этому времени успел бы разве что оборудовать инфраструктуру (настроить проект или скрипты сборки) и перешёл бы к написанию обязательного каркаса приложения...
WH>2)Запретить нативный код. WH>Проблема нативного кода в том, что он не даёт заменять систему команд процессоров. WH>Через пару лет после того как не станет нативного кода x86 сдохнет. WH>Исключение можно сделать только для совсем дохлых микропроцессоров где даже ОС нет.
Согласен (и кстати для МК не обязательно делать исключение). И думаю что идеальной заменой нативного кода должно быть что-то вроде LLVM IR. Согласен? )
Кстати индустрия постепенно движется в этом направление: если webassembly (которые внутри по сути и есть LLVM IR, с мелкими правками для облегчения организации песочницы) реально взлетит, то...
WH>3)За основу ОС берем мидори. http://joeduffyblog.com/2015/11/03/blogging-about-midori/
WH>mutable, readonly и immutable становятся атрибутами кластеров.
Ну про это я тебе уже говорил, что самая идея любопытная, но требуется хотя бы один реально работающий прототип, чтобы оценить эффективность на реальных тестах. А то из подобной теории совершенно не очевидны итоговые параметры производительности.
WH>в)Добавляем http://halide-lang.org/ для параллельного программирования.
Ну "параллельное программирование" — это громко сказано. Всё же в общем случае оно делится (на современном железе) на 3 совместно работающих уровня: SIMD, многоядерность (решения типа OpenMP), кластеры (решения типа MPI). И данный язык, насколько я помню, занимался решением только нижнего уровня параллельности (SIMD).
WH>г)Заменяем контракты на это: https://www.microsoft.com/en-us/research/project/dafny-a-language-and-program-verifier-for-functional-correctness/
Любопытная игрушка, но до реального применения ей ещё очень далеко. Но будем следить...
Здравствуйте, WolfHound, Вы писали:
PD>>Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown. WH> WH>Это просто курам на смех. Обновить ОС куда проще. После чего ОС перепроверит весь установленный софт.
Так ты хочешь верификатор, который работает не с исходным, а с исполняемым кодом? Хм хм хм...
Здравствуйте, WolfHound, Вы писали:
WH>ОС находит те места, которые не может верифицировать и добавляет туда проверку.
М-да... В общем, без проверок в рантайме ничего не выходит ни у тебя, ни у AlexRK. Если ОС или верификатор не может верифицировать, надо вставлять проверку в рантайме,
Кстати, не совсем понял, как ОС верифицировать-то будет ? Вроде в дискуссии с AlexRK мы исходили из того, что проверяет статический анализатор на этапе компиляции.
Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
WH>Либо в клиническом случае пользователи качают патч на эту программу и всё.
Фирма, выпустившая программу, давно не существует, программисты разбрелись. Ты в курсе, что программы иногда живут очень долго ?
WH>Ты кстати в курсе что винда молча при запуске исправляет некоторые популярные программы чтобы они работали.
WH>Ну и не забывай о том, что мы говорим о крайне гипотетической ситуации. WH>Ибо верификатор на несколько порядков проще чем процессор.
Вот только бы знать, насколько менее надежен.
По большому счету, за 35 лет существования защищенного режима (считая с 80286, 1982 год) критических (неисправляемых) ошибок в нем не оказалось. Вынесли эти процессоры все версии Windows, Unix-Linux, а потом и MacOS — ничего, все нормально.
Ладно. Появится эта самая верфицируемая ОС в реальном мире (не экспериментальная Singularuty, приказавшая долго жить, а то, что продается сотнями миллионов копий), подождем 35 лет — посмотрим.
Вот только скорее всего ее появление и есть крайне гипотетическая ситуация.
Здравствуйте, alex_public, Вы писали:
_>Так ты хочешь верификатор, который работает не с исходным, а с исполняемым кодом? Хм хм хм...
Не с исполняемым, а с промежуточным. Что-то типа MSIL только сделанный по-умному, а не как у МС.
И работать на этом уровне намного проще чем с исходным кодом.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
PD>А вот что будут делать, если в алгоритме статической верификации обнаружилась ошибка, а программы уже прошли этап этой верификации, разошлись в миллионах копий и теперь рушат ОС или получают доступ к чужой памяти — объясни. Срочно патчить все выпущенные программы ? Как ? Фирма, выпустившая эту программу, давно закрылась, авторы разбрелись кто куда.
(небольшая придирка) Фирмы, работающие в таких объемами так быстро не исчезают. Как минимум сотрудники на тех поддержку и саппорт отстаться должны.
ARK>Или вы считаете, что такой дыры в процессоре быть не может в принципе? ARK>Если такой дыры в процессоре даже теоретически быть не может, то почему тогда вы считаете, что такая дыра может быть в верификаторе?
Верфицировать железо, кмк, гораздо проще чем софт.
scf>- Другие сетевые протоколы в сети Internet. Помимо личного адреса каждой кофеварке, должны обеспечивать идентификацию, аутентификацию и шифрование для каждого каждого узла в сети. сетевой адрес должен быть прибит гвоздями к конкретной железке и провайдеру
Хм. Вообще-то он есть — MAC-адрес. Почти прибит. Но за пределы локалки не передается. Нужно ? Зачем ?
Купил я кофеварку, а к ней прибит адрес этот. И переехал в другую страну. И оказался я в ней со своим адресом, видным всей сети, как белая ворона. Никакой структуры у сети больше нет. Ни тебе маски подсети, ни нормальной маршрутизации. Ищи эту кофеварку где хочешь. Адрес прибит, а вот кофеварка уехала вместе с адресом.
scf>- Стандартный байткод. Все языки высокого уровня, как со сборкой мусора, так и без неё, компилируются только в него. Компиляторы в нативный код стоят на машинах конечных пользователей и понимают только стандартный байткод. У стандартного байткода есть "безопасное" подмножество, программы на котором можно использовать в песочницах типа браузера.
Хм. Я хочу выжать из процессора максимум того, что он может дать. Байткод все же медленее. Запрет натива ?
scf>- Полная aппаратная и программная поддержка изоляции процессов в ОС.
А разве ее нет ?
scf>- Единый стандарт взаимодействия программ с ОС. POSIX был хорош, но недостаточен.
Имеется в виду, чтобы не было зоопарка в виде WinAPI/OLE/RPC и т.д. ? Тогда согласен
scf>- Единый стандарт платформ для дистрибьюции софта, включая платный софт. Включая платные библиотеки, входящие в платный софт
+1
scf>- Компании, которые специализируются на разработке платных библиотек и рантаймов с монетизацией "0.1% с каждой проданной программы, которая использует нашу либу"
Здравствуйте, Sharov, Вы писали:
ARK>>Или вы считаете, что такой дыры в процессоре быть не может в принципе? ARK>>Если такой дыры в процессоре даже теоретически быть не может, то почему тогда вы считаете, что такая дыра может быть в верификаторе?
S>Верфицировать железо, кмк, гораздо проще чем софт.
Резко сложнее.
Гонки, иголки, наводки, неустойчивые состояния...
S>(небольшая придирка) Фирмы, работающие в таких объемами так быстро не исчезают. Как минимум сотрудники на тех поддержку и саппорт отстаться должны.
Я вроде ни о каких объемах ничего не говорил.
Ну а что касается исчезновения — да даже и исчезновение иногда не требуется. Просто прекращена поддержка.
Вот есть такая фирма — Microsoft. И была такая ОС — Windows 2000. И нет ее поддержки.
А между тем еще 5 лет назад (не знаю, как сейчас) именно на этой ОС работали табло для показа отправления в аэропорту Домодедово. Мне об этом одно табло само сказало, потому что на нем был какой-то экран с MessageBox (программа упала) и на нем было черным по белому — Windows 2000.
Здравствуйте, alex_public, Вы писали:
_>В миллиметрах — это тоже не верно, потому что для человеческого взгляда важен угловой размер, а не линейный. Т.е. 7мм на смартфоне и на телевизоре — это очень разные вещи, из-за того, что их рассматривают с разного расстояния.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм. Вообще-то он есть — MAC-адрес. Почти прибит. Но за пределы локалки не передается. Нужно ? Зачем ?
Чтобы после переезда в другую страну включаешь кофеварку, она лезет на сервер. И сервер знает, что а) это та же кофеварка б) она теперь в другой стране. Решает проблему аутентификации и локализации.
scf>>- Стандартный байткод. Все языки высокого уровня, как со сборкой мусора, так и без неё, компилируются только в него. Компиляторы в нативный код стоят на машинах конечных пользователей и понимают только стандартный байткод. У стандартного байткода есть "безопасное" подмножество, программы на котором можно использовать в песочницах типа браузера.
PD>Хм. Я хочу выжать из процессора максимум того, что он может дать. Байткод все же медленее. Запрет натива ?
Я же написал, что на конечной машине он компилируется . Да, запрет натива. Производители процессоров выпускают новую модель вместе с компилятором под нее.
scf>>- Полная aппаратная и программная поддержка изоляции процессов в ОС. PD>А разве ее нет ?
Нет. На телефонах что-то похожее, но можно и нужно лучше. Чтобы каждая программа была готова работать, когда ей отрубят сеть, воткнут лимиты на место на диске и ограничат цпу, память и пропускную способность диска.
Здравствуйте, Sharov, Вы писали:
ARK>>Или вы считаете, что такой дыры в процессоре быть не может в принципе? ARK>>Если такой дыры в процессоре даже теоретически быть не может, то почему тогда вы считаете, что такая дыра может быть в верификаторе?
S>Верфицировать железо, кмк, гораздо проще чем софт.
Не уверен. Просто существующие языки плохо подходят для верификации.
PD>А вот что будут делать, если в алгоритме статической верификации обнаружилась ошибка, а программы уже прошли этап этой верификации, разошлись в миллионах копий и теперь рушат ОС или получают доступ к чужой памяти — объясни. Срочно патчить все выпущенные программы ? Как ? Фирма, выпустившая эту программу, давно закрылась, авторы разбрелись кто куда.
PD>Ну а что касается исчезновения — да даже и исчезновение иногда не требуется. Просто прекращена поддержка. PD>Вот есть такая фирма — Microsoft. И была такая ОС — Windows 2000. И нет ее поддержки.
ms методично и спокойно переводила людей на более новые ОС. Т.е. это не так "хоп и исчезла". К тому же, если таже 2000 так критична, то наверняка можно договориться о доработке за деньги.
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>ОС находит те места, которые не может верифицировать и добавляет туда проверку. PD>М-да... В общем, без проверок в рантайме ничего не выходит ни у тебя, ни у AlexRK.
Демагогию не разводи.
Мы говорим про крайне гипотетический случай, когда нашли ошибку в верификаторе.
PD>Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
Верифицировать нужно всегда и только на машине пользователя.
Иначе что помешает хакеру заслать зловредный бинарник?
Не очень ясно о чём вы AlexRK говорите. Но я говорю про верификацию промежуточного кода. И компиляцию на этапе установки.
Но если уж на, то пошло, то нет никаких проблем верифицировать бинарный код. Всё что для этого нужно чтобы компилятор рядом с исполняемым файлом положил необходимую метаинформацию.
WH>>Либо в клиническом случае пользователи качают патч на эту программу и всё. PD>Фирма, выпустившая программу, давно не существует, программисты разбрелись. Ты в курсе, что программы иногда живут очень долго ?
Я в курсе. Но если программа так нужна, то для неё сделают неофициальный патч.
Например, Vampire: The Masquerade — Bloodlines до рабочего состояния довели энтузиасты.
И это нужно только если:
1)Нашли ошибку в верификаторе. Я в это не верю, но допустим.
2)Программа не прошла новую верификацию.
3)Автоматическое исправление не дало удовлетворительный результат.
Вероятность каждого из этих событий ничтожна.
WH>>Ибо верификатор на несколько порядков проще чем процессор. PD>Вот только бы знать, насколько менее надежен.
На 100% надёжен. Ибо математически доказан. В отличии от процессора.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А еще транзисторы могут отказывать -- температура, космос и т.д. Все это не касается логики работы процессора, которая вполне себе верифицируема.
Я не утверждаю, что это легко. Но это гораздо(!) проще верификации софта.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
Не, на машине пользователя некое промежуточное представление (высокоуровневый бинарник). Это промежуточное представление тоже верифицируется (при установке программы), но более упрощенным алгоритмом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Гибрид необязателен. Берем C++ и верификатор. Я не призываю его брать после пропажи всего софта, я просто показываю что выбор не ограничен двумя пунктами.
PD>Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
Очевидно что дыра может быть в чем угодно, хоть в верификаторе, хоть в железе. Очевидно, что при наличии дыры никакой 100% надежности быть не может вне зависимости от выбранного подхода. О чем мы вообще рассуждаем? Если закладываем вероятность дыры, то будет и вероятность ненадежности.
PD>Вот тут не понял. Писать с нуля, конечно, придется. Но в итоге хочу я одновременно иметь 2 работающих приложения. И вариант, что мы с одного на другое переключаемся так, что когда одно работает, другое работать не имеет права, не принимается — это уже не многопрограммный режим, а бог знает что. Одно приложение с недоказанной корректностью обращений к памяти (какой-то фоновый процесс, которому часами работать надо), другое — нужна гарантия недоступности их памяти. И что делать ?
а) соглашаться на бог знает что.
б) высаживать приложение с недоказанной корректностью на другую машину.
в) переходить на многопроцессорные машины и гонять программы с разным клеймом на физически разных процессорах.
Здравствуйте, scf, Вы писали:
scf>Чтобы после переезда в другую страну включаешь кофеварку, она лезет на сервер. И сервер знает, что а) это та же кофеварка б) она теперь в другой стране. Решает проблему аутентификации и локализации.
Чудно, а ее теперь как из внешнего мира искать ?
PD>>Хм. Я хочу выжать из процессора максимум того, что он может дать. Байткод все же медленее. Запрет натива ? scf>Я же написал, что на конечной машине он компилируется . Да, запрет натива. Производители процессоров выпускают новую модель вместе с компилятором под нее.
Хм. Я все же хочу пооптимизировать сам на уровне ассемблера. Запретишь ?
scf>>>- Полная aппаратная и программная поддержка изоляции процессов в ОС. PD>>А разве ее нет ? scf>Нет. На телефонах что-то похожее, но можно и нужно лучше. Чтобы каждая программа была готова работать, когда ей отрубят сеть, воткнут лимиты на место на диске и ограничат цпу, память и пропускную способность диска.
Связи между вырубанием сети, лимитами а диске и ограничением цпу (что имеется в виду, кстати?) и изоляцией процессов не вижу.
Здравствуйте, WolfHound, Вы писали:
PD>>М-да... В общем, без проверок в рантайме ничего не выходит ни у тебя, ни у AlexRK. WH>Демагогию не разводи. WH>Мы говорим про крайне гипотетический случай, когда нашли ошибку в верификаторе.
Произошло некоторое смешение терминов. Наверное, действительно лучше говорить о "верификации" на конечной машине.
Выше в обсуждении под термином "верификация" понималось "доказательство корректности программы в соответствии со спецификацией".
Здравствуйте, Sharov, Вы писали:
WH>>Если бы код был под ВМ, то никакого переписывания было бы не нужно. WH>>Всё просто бы заработало. S>А драйвера и их производительность? А real-time, как он без натива?
Замечательно.
Я надеюсь ты в курсе что при компиляции код проходит через машинно-независимое промежуточное представление.
Я просто предлагаю на этом этапе компиляцию остановить и сохранить результат.
После чего на машине пользователя после верификации продолжить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
S>Я же выделил: S>
PD>>А вот что будут делать, если в алгоритме статической верификации обнаружилась ошибка, а программы уже прошли этап этой верификации, разошлись в миллионах копий и теперь рушат ОС или получают доступ к чужой памяти — объясни. Срочно патчить все выпущенные программы ? Как ? Фирма, выпустившая эту программу, давно закрылась, авторы разбрелись кто куда.
А, вот что. Сорри. Забыл.
PD>>Ну а что касается исчезновения — да даже и исчезновение иногда не требуется. Просто прекращена поддержка. PD>>Вот есть такая фирма — Microsoft. И была такая ОС — Windows 2000. И нет ее поддержки.
S>ms методично и спокойно переводила людей на более новые ОС. Т.е. это не так "хоп и исчезла".
MS-то переводила, а вот другая фирма могла просто забить на свой продукт.
>К тому же, если таже 2000 так критична, то наверняка можно договориться о доработке за деньги.
Я не знаю, насколько она там критична (вряд ли), но сомневаюсь, что MS согласится за любые деньги ее дорабатывать.
Здравствуйте, WolfHound, Вы писали:
WH>Демагогию не разводи.
Да какая там демагогия! Просто рассмотрение одного из вариантов.
WH>Мы говорим про крайне гипотетический случай, когда нашли ошибку в верификаторе.
Что-то мне говорит, что ошибка в программе (даже если она и верификатор) — случай совсем не крайне гипотетичный
WH>Не очень ясно о чём вы AlexRK говорите. Но я говорю про верификацию промежуточного кода. И компиляцию на этапе установки.
Ну тогда я , видимо, не вполне верно твои соображения понял. С AlexRK речь шла о статической верификации на уровне исходного языка, после прохождения которой и компиляции там же программа признается корректной и выпускается в мир. О промежуточном коде там и речи не было, как и о компиляции на этапе установки.
Переизложи, пожалуйста, свою точку зрения, кто кого и когда верифицирует и компилирует, и какой у тебя код есть — исходный, промежуточный , нативный, и кто что где делает.
WH>Я в курсе. Но если программа так нужна, то для неё сделают неофициальный патч.
Да уж. Надеяться на то, что проблемы с программой, которая изначально рушит ОС, а потом перестает работать, так как ОС ее признада недостойной, решаются с помощью неофициальных патчей — это замечательный деловой подход для разработчиков Ос
WH>На 100% надёжен. Ибо математически доказан. В отличии от процессора.
Эхе-хе... Алгоритмы и методы компиляции тоже вроде как доказаны, а компиляторы порой падают.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>MS-то переводила, а вот другая фирма могла просто забить на свой продукт.
А у другой таких масштабов не будет. Тут обе стороны понимают, что нужны некие гарантии.
PD>Я не знаю, насколько она там критична (вряд ли), но сомневаюсь, что MS согласится за любые деньги ее дорабатывать.
Здравствуйте, WolfHound, Вы писали:
S>>А драйвера и их производительность? А real-time, как он без натива? WH>Замечательно. WH>Я надеюсь ты в курсе что при компиляции код проходит через машинно-независимое промежуточное представление. WH>Я просто предлагаю на этом этапе компиляцию остановить и сохранить результат. WH>После чего на машине пользователя после верификации продолжить.
Не уверен, что замечательно. Если для драйверов я еще могу представить промежуточное исполнение и всяческие jit-оптимизации. То для real-time уже не очень -- там надо сразу, быстро и гарантированно без задержек.
Здравствуйте, alex_public, Вы писали:
_>Даже для 3-ёх строчных скриптов? ) Вот буквально вчера у меня тут обнаружилось, что fb2 файлы скаченные с одного известного сайта имеют некорректную структуру (содержат html entities, хотя fb2 — это обычный xml) и из-за этого не читаются некоторым ПО. Проблема была решена (причём для целой папки таких fb2 файлов за раз) за минуту в три строчки на Питоне. На популярных статических языках я бы к этому времени успел бы разве что оборудовать инфраструктуру (настроить проект или скрипты сборки) и перешёл бы к написанию обязательного каркаса приложения...
1)Скриптам никто не мешает быть статически типизированными.
2)Создание консольного приложения на C# занимает несколько секунд.
_>Согласен (и кстати для МК не обязательно делать исключение).
Тут ИМХО нельзя всех под одну гребёнку.
_>И думаю что идеальной заменой нативного кода должно быть что-то вроде LLVM IR. Согласен? )
Формат промежуточного кода отдельный и большой разговор.
Туда как минимум нужно добавить дафну. Ну и стековая ВМ гораздо практичнее для такого применения.
WH>>3)За основу ОС берем мидори. http://joeduffyblog.com/2015/11/03/blogging-about-midori/ _>Крайне сомнительно.
Обоснуй.
WH>>в)Добавляем http://halide-lang.org/ для параллельного программирования. _>Ну "параллельное программирование" — это громко сказано. Всё же в общем случае оно делится (на современном железе) на 3 совместно работающих уровня: SIMD, многоядерность (решения типа OpenMP), кластеры (решения типа MPI). И данный язык, насколько я помню, занимался решением только нижнего уровня параллельности (SIMD).
Не правильно. В текущей реализации SMID и многоядерность. Но саму модель можно и на кластер натянуть. В данном случае между многоядерностью и кластером разницы никакой.
Но тут я имел в виду немного другое. Я делю многопоточное программирование на 2 типа.
Асинхронное. Это когда мы много ждём и мало считаем.
Параллельное. Это когда у нас есть пачка данных и нам её нужно очень быстро посчитать.
Асинхронное программирование в мидори сделано хорошо.
Параллельное тоже есть, но по сравнению с halide детский сад.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexRK, Вы писали:
PD>>Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
ARK>Не, на машине пользователя некое промежуточное представление (высокоуровневый бинарник). Это промежуточное представление тоже верифицируется (при установке программы), но более упрощенным алгоритмом.
Вчера ты мне приводил пример на С-подобном языке с этой самой верификацией, и говорил, что после того, как она прошла, программа признается готовой к употреблению. Предполагалась компиляция в нативный код. Теперь вдруг вылезло промежуточное представление, которое нужно еще раз верифицировать, уже на машине пользователя. Я что-то запутался. И зачем, ее , кстати, верифицировать на машине пользователя, если она уже один раз 100% надежно отверифицирована ?
Здравствуйте, Sharov, Вы писали:
S>Не уверен, что замечательно. Если для драйверов я еще могу представить промежуточное исполнение и всяческие jit-оптимизации. То для real-time уже не очень -- там надо сразу, быстро и гарантированно без задержек.
Зачем JIT? JIT не нужен. Кто мешает компилировать при установке приложения?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
PD>>Вот тут не понял. Писать с нуля, конечно, придется. Но в итоге хочу я одновременно иметь 2 работающих приложения. И вариант, что мы с одного на другое переключаемся так, что когда одно работает, другое работать не имеет права, не принимается — это уже не многопрограммный режим, а бог знает что. Одно приложение с недоказанной корректностью обращений к памяти (какой-то фоновый процесс, которому часами работать надо), другое — нужна гарантия недоступности их памяти. И что делать ? S>а) соглашаться на бог знает что.
Рухнет ведь.
S>б) высаживать приложение с недоказанной корректностью на другую машину.
Это ты пользователю скажи. Дескать, вот тебе одни программы, а вот другие. Купи 2 машины (заплати двойные деньги), ну а мы, так и быть, поможем тебе по сети организовать их взаимодействие. Если, конечно, при передаче по сети плохая машина не передаст что-то плохое хорошей машине . Зато будет статическая верификация.
S>в) переходить на многопроцессорные машины и гонять программы с разным клеймом на физически разных процессорах.
Хм, а в чем отличие от многоядерности на одном процессоре ? Только кеши изолированы, а память-то нет.
Ну и, пардон, но предлагать разработчику тех же материнок бросить все, что они сейчас делают, и делать только многопроцессорные машины — пошлют они тебя очень далеко.
Кстати, и стоить они будут несколько дороже. А во имя чего ?
Утопия.
Здравствуйте, Sharov, Вы писали:
PD>>Я не знаю, насколько она там критична (вряд ли), но сомневаюсь, что MS согласится за любые деньги ее дорабатывать.
S>Куда денутся.
Никуда не денутся. Пришлют вежливый ответ , который в переводе на нормальный язык означает — не будем, и все.
Заставить MS что-то делать, чего она делать не хочет — ну разве что господь бог может, а на Земле — никто.
Здравствуйте, Pavel Dvorkin, Вы писали:
scf>>Чтобы после переезда в другую страну включаешь кофеварку, она лезет на сервер. И сервер знает, что а) это та же кофеварка б) она теперь в другой стране. Решает проблему аутентификации и локализации.
PD>Чудно, а ее теперь как из внешнего мира искать ?
Она может сама себя найти, подключившись к серверу. Лучше каждой кофеварке знать свой сервер, чем серверу хранить список адресов всех кофеварок. Если не нравится — есть куча способов, от DNS до распределенных сетей.
PD>Хм. Я все же хочу пооптимизировать сам на уровне ассемблера. Запретишь ?
Да. Если вендор выпускает новое цпу с интересными командами, это его проблема, чтобы тесты и тяжелые программы компилировались в эффективный нейтив. Ну или продавливать расширение байткода для векторных операций к примеру.
PD>Связи между вырубанием сети, лимитами а диске и ограничением цпу (что имеется в виду, кстати?) и изоляцией процессов не вижу.
Под изоляцией процессов я понимаю в том числе разграничение разделяемых ресурсов (см. выше) и готовность процесса к тому, что ресурсы ему урежут.
Здравствуйте, scf, Вы писали:
PD>>Чудно, а ее теперь как из внешнего мира искать ? scf>Она может сама себя найти, подключившись к серверу. Лучше каждой кофеварке знать свой сервер, чем серверу хранить список адресов всех кофеварок.
Она-то себя и так найдет, еще бы, а мне из другой части света как к ней добраться ?
>Если не нравится — есть куча способов, от DNS до распределенных сетей.
Так, стоп. Во-первых, о DNS пока речи не было — к этой кофеварке был прибит ее адрес, а DNS имя вроде как не прибивали ? Если же предлагаешь дать ей DNS имя — оно тоже прибито или нет ? Если нет — ты получишь систему, в которой вместо IP адресов будут DNS-имена. Такое сделать в принципе можно — в конце концов IP-адреса это тоже "деревья", но с узлами в виде масок подсетей, а DNS имена — это деревья из текстовых строк. Но чем это лучше будет ?
PD>>Хм. Я все же хочу пооптимизировать сам на уровне ассемблера. Запретишь ? scf>Да. Если вендор выпускает новое цпу с интересными командами, это его проблема, чтобы тесты и тяжелые программы компилировались в эффективный нейтив. Ну или продавливать расширение байткода для векторных операций к примеру.
А я считаю, что я лучше вендора знаю, как именно этот код надо в машинные команды превратить. Потому что вендор неизбежно должен ориентироваться на общий случай, а я могу применительно к своему случаю.
PD>>Связи между вырубанием сети, лимитами а диске и ограничением цпу (что имеется в виду, кстати?) и изоляцией процессов не вижу. scf>Под изоляцией процессов я понимаю в том числе разграничение разделяемых ресурсов (см. выше) и готовность процесса к тому, что ресурсы ему урежут.
Я как-то под изоляцией процессов понимаю нечто иное. Ну ладно, оставим эту тему. Разграничение разделяемых ресурсов начнем обсуждать — далеко пойдем.
PD>Заставить MS что-то делать, чего она делать не хочет — ну разве что господь бог может, а на Земле — никто.
Я Вас умоляю... Как минимум правительство США, да и другой развитой страны тоже. Если оне хотят в этой стране получать прибыль без проблем. Вопрос выгоды, если надо будет и в 98 будут ковыряться.
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>Мы говорим про крайне гипотетический случай, когда нашли ошибку в верификаторе. PD>Что-то мне говорит, что ошибка в программе (даже если она и верификатор) — случай совсем не крайне гипотетичный
Верификатор — это не просто программа. Это критически важная программа. Он доказан математически.
Чтобы понять насколько это серьёзно попробуй, не трогая предикаты и сигнатуру SelectionSortRange написать внутри неё что-то кроме сортировки. https://rise4fun.com/Dafny/pX4N
PD>Ну тогда я , видимо, не вполне верно твои соображения понял. С AlexRK речь шла о статической верификации на уровне исходного языка, после прохождения которой и компиляции там же программа признается корректной и выпускается в мир. О промежуточном коде там и речи не было, как и о компиляции на этапе установки.
Как мы выяснили ты его не так понял.
PD>Переизложи, пожалуйста, свою точку зрения, кто кого и когда верифицирует и компилирует, и какой у тебя код есть — исходный, промежуточный , нативный, и кто что где делает.
На машине разработчика:
1)Компилируем исходный код в промежуточное представление. Что-то вроде MSIL только грамотно сделанное.
2)Верифицируем полученный промежуточный код. Для того чтобы убедиться, что компилятор не сгенерировал что-то бредовое.
3)Сохраняем промежуточный код в файл.
На машине пользователя:
1)Загружаем промежуточное представление из файла.
2)Верифицируем для того чтобы убедиться, что злобный хакер не сгенерировал что-то бредовое.
3)Из промежуточного представления генерируем нативный код.
4)Верифицируем машинный код. Чтобы убедиться, что генератор нативного кода бред не сгенерировал.
5)Сохраняем нативный код для последующей быстрой загрузки. Опционально добавляем контрольную сумму для того чтобы убедиться, что носитель информации не дурит.
В качестве оптимизации возможно генерация машинного кода на некотором доверенном сервере. И исполнение подписанного этим сервером кода. PD>Да уж. Надеяться на то, что проблемы с программой, которая изначально рушит ОС, а потом перестает работать, так как ОС ее признада недостойной, решаются с помощью неофициальных патчей — это замечательный деловой подход для разработчиков Ос
Чем больше ты рассказываешь про этот случай, тем больше он походит на неуловимого Джо.
Короче разработчик ОС просто пошлёт одного неудачника и всё.
PD>Эхе-хе... Алгоритмы и методы компиляции тоже вроде как доказаны, а компиляторы порой падают.
Современные компиляторы не имеют примерно никакого отношения к тем алгоритмам, которые доказаны. Ибо эти алгоритмы крайне непрактичны. Это я тебе как разработчик компиляторов говорю.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>Я Вас умоляю... Как минимум правительство США, да и другой развитой страны тоже.
Ну-ну. Впрочем, это уже в Политику.
>Если оне хотят в этой стране получать прибыль без проблем.
Сдается мне , что они ее уже 40 лет получают без проблем. И совсем неплохую получили
>Вопрос выгоды, если наЮдо будет и в 98 будут ковыряться.
И в какую же сумму ты оцениваешь затраты на то, чтобы превратить MS из фирмы, производящей ПО исключительно на продажу в фирму, которая делает что-то по заказу ?
Здравствуйте, scf, Вы писали:
scf>Ну или продавливать расширение байткода для векторных операций к примеру.
Не нужно. Из байткода вообще нужно убрать всё что можно. И если хорошо подумать убрать оттуда можно почти всё.
Достаточно положить эти операции в отдельную библиотеку. Реализация по умолчанию будет использовать базовые операции.
Компилятор родного процессора будет использовать соответствующие операции. А все остальные код из библиотеки.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>2)Запретить нативный код. WH>Проблема нативного кода в том, что он не даёт заменять систему команд процессоров.
Зачем может понадобиться заменять систему команд процессора?
У нас регулярно появляются принципиально новые процессорные архитектуры, которые в разы быстрее и лучше предыдущих?
Сложно скомпилировать программу под все нужные процессоры?
Лично я бы запретил распространять программы в промежуточных кодах, т.к. это усложняет и запутывает развертывание без значительной пользы.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
WH>Верификатор — это не просто программа. Это критически важная программа. Он доказан математически.
Ладно, пусть так.
PD>>Ну тогда я , видимо, не вполне верно твои соображения понял. С AlexRK речь шла о статической верификации на уровне исходного языка, после прохождения которой и компиляции там же программа признается корректной и выпускается в мир. О промежуточном коде там и речи не было, как и о компиляции на этапе установки. WH>Как мы выяснили ты его не так понял.
Ну насколько я его правильно понял — я его уже спросил, подождем его ответа. Вчера мое понимание того, что он писал, у него возражений не вызывало.
Утверждение же, что "мы выяснили" — пардон, но зрительская масса как будто ничего не заявляла. Я то есть. Я лишь выяснил, что тебя я неправильно понял.
PD>>Переизложи, пожалуйста, свою точку зрения, кто кого и когда верифицирует и компилирует, и какой у тебя код есть — исходный, промежуточный , нативный, и кто что где делает. WH>На машине разработчика: WH>1)Компилируем исходный код в промежуточное представление. Что-то вроде MSIL только грамотно сделанное. WH>2)Верифицируем полученный промежуточный код. Для того чтобы убедиться, что компилятор не сгенерировал что-то бредовое. WH>3)Сохраняем промежуточный код в файл.
WH>На машине пользователя: WH>1)Загружаем промежуточное представление из файла. WH>2)Верифицируем для того чтобы убедиться, что злобный хакер не сгенерировал что-то бредовое. WH>3)Из промежуточного представления генерируем нативный код. WH>4)Верифицируем машинный код. Чтобы убедиться, что генератор нативного кода бред не сгенерировал. WH>5)Сохраняем нативный код для последующей быстрой загрузки. Опционально добавляем контрольную сумму для того чтобы убедиться, что носитель информации не дурит.
Вот теперь понял. Все ясно. Правда, последнее едва ли нужно — контрольная сумма и так в секторе есть.
Ну что скажу... В общем, достаточно стройно и логично.
Я только не уверен в том, что этот алгоритм верификации действительно будет 100% надежным. То, что он , как ты говоришь, доказан — охотно готов поверить, но все равно не убеждает.
Дело в том, что ты тут привел идеальную схему. А вот что ты писал чуть раньше
>ОС находит те места, которые не может верифицировать и добавляет туда проверку.
Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме.
А вот строгого доказательства того, что таких случаев будет действительно исчезающе мало — я не вижу. И мне остается только верить тебе на слово, что это будет очень редко, настолько редко, что этим можно пренебречь.
А почему я обязан верить ? Ты же не сказал, что есть доказательство, что этот "остаточный член" пренебрежимо мал по сравнению с суммой ряда ?
После этого уверенность в 100% надежности и математической доказанности этой верификации у меня как-то пропадает.
Это все равно, как если бы кто-то сказал — доказано, что сумма углов треугольника в Евклидовой геометрии равно 180, но в 0.0000000000000001% случаев это все же не так.
Если это и впрямь не так в этом проценте случаев — значит, Евклидова геометрия неверна.
Понимаешь, в чем дело ? Законы физики, тем более химии (говорю как химик по образованию) никогда не обязаны выполняться 100%. Механика Ньютона верна, пока не вмешаются релятивистские поправки, а строго говоря, неверна вообще, но эта неверность исчезающе мала и несущественна. В химии теория, которая на 80% дает правильный ответ , а в остальных 20% совсем неверный — замечательная теория. А вот в аксиоматической теории один контр-случай ставит под сомнение всю теорию.
Здравствуйте, Pavel Dvorkin, Вы писали:
ARK>>Не, на машине пользователя некое промежуточное представление (высокоуровневый бинарник). Это промежуточное представление тоже верифицируется (при установке программы), но более упрощенным алгоритмом. PD>Вчера ты мне приводил пример на С-подобном языке с этой самой верификацией, и говорил, что после того, как она прошла, программа признается готовой к употреблению.
Да, готовой в том плане, что она гарантированно корректна и не содержит ошибок времени выполнения.
PD>Предполагалась компиляция в нативный код.
Приношу свои извинения, если я такое писал, то насчет нативного кода я погорячился.
PD>Теперь вдруг вылезло промежуточное представление, которое нужно еще раз верифицировать, уже на машине пользователя. Я что-то запутался. И зачем, ее , кстати, верифицировать на машине пользователя, если она уже один раз 100% надежно отверифицирована ?
Да, нужно, по той причине, что до пользователя может дойти искаженное (случайно или преднамеренно) представление. Но промежуточное представление гораздо проще исходной программы, и его верификация, соответственно, тоже.
ARK>Да, нужно, по той причине, что до пользователя может дойти искаженное (случайно или преднамеренно) представление.
Это не решается цифровой подписью или контрольной суммой ? Вроде как с этим особой проблемы и сейчас нет.
>Но промежуточное представление гораздо проще исходной программы, и его верификация, соответственно, тоже.
Если цифровая подпись в порядке, контрольная сумма md5 в порядке (потребовать их обязательную проверку ничего не стоит, демиург же!), то зачем еще верифицировать ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И в какую же сумму ты оцениваешь затраты на то, чтобы превратить MS из фирмы, производящей ПО исключительно на продажу в фирму, которая делает что-то по заказу ?
Придлагаю оффтоп закончить, а то мы уже совсем в дебри ушли.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>а) соглашаться на бог знает что.
PD>Рухнет ведь.
максимум — зависнет. Поначалу.
S>>б) высаживать приложение с недоказанной корректностью на другую машину.
PD>Это ты пользователю скажи. Дескать, вот тебе одни программы, а вот другие. Купи 2 машины (заплати двойные деньги), ну а мы, так и быть, поможем тебе по сети организовать их взаимодействие. Если, конечно, при передаче по сети плохая машина не передаст что-то плохое хорошей машине . Зато будет статическая верификация.
Лучше я скажу это, чем то, что никаких гарантий надежности нет и не закладывалось на уровне выбора ЯП в пользу мощности, и то что для выполнения программ, требующих надежности, нет вообще ни одного гарантированного способа их выполнить без утечки.
S>>в) переходить на многопроцессорные машины и гонять программы с разным клеймом на физически разных процессорах.
PD>Хм, а в чем отличие от многоядерности на одном процессоре ? Только кеши изолированы, а память-то нет.
Да, пардон, я думал что проблема с кэшами.
Здравствуйте, samius, Вы писали:
PD>>Рухнет ведь. S>максимум — зависнет. Поначалу.
Хрен редьки ...
S>>>б) высаживать приложение с недоказанной корректностью на другую машину.
PD>>Это ты пользователю скажи. Дескать, вот тебе одни программы, а вот другие. Купи 2 машины (заплати двойные деньги), ну а мы, так и быть, поможем тебе по сети организовать их взаимодействие. Если, конечно, при передаче по сети плохая машина не передаст что-то плохое хорошей машине . Зато будет статическая верификация. S>Лучше я скажу это, чем то, что никаких гарантий надежности нет и не закладывалось на уровне выбора ЯП в пользу мощности, и то что для выполнения программ, требующих надежности, нет вообще ни одного гарантированного способа их выполнить без утечки.
Да живем же как-то без всего этого. И 0 кольцо вполне изолировано, да и в 3 кольце определенная изоляция по UAC есть. А ты нагородил огород, заставил пользователя вторую машину покупать, а теперь заявляешь — никаких гарантий надежности нет. Что-то все это крайне сомнительно, чтобы могло взлететь.
Здравствуйте, lpd, Вы писали:
lpd>Зачем может понадобиться заменять систему команд процессора?
Чтобы процессор работал быстрее.
lpd>У нас регулярно появляются принципиально новые процессорные архитектуры, которые в разы быстрее и лучше предыдущих?
Так по тому и не появляются что невозможно перетащить на эти процессоры все программы.
lpd>Сложно скомпилировать программу под все нужные процессоры?
Одну нет.
А вот все программы невозможно.
lpd>Лично я бы запретил распространять программы в промежуточных кодах, т.к. это усложняет и запутывает развертывание без значительной пользы. Это просто противоречит вообще всему.
В случае с промежуточным кодом у тебя один бинарник который работает везде.
В случае с нативом у тебя процессор * ОС.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
WH>>Зачем JIT? JIT не нужен. Кто мешает компилировать при установке приложения? S>В натив ? А почему сразу нельзя?
По тому что:
1)Надо верифицировать.
2)Чтобы можно было поддержать новые процессоры.
3)Чтобы старые программы начинали работать быстрее после обновления бэкенда.
Ты что вообще не читаешь что тут пишут?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Лучше я скажу это, чем то, что никаких гарантий надежности нет и не закладывалось на уровне выбора ЯП в пользу мощности, и то что для выполнения программ, требующих надежности, нет вообще ни одного гарантированного способа их выполнить без утечки.
PD>Да живем же как-то без всего этого. И 0 кольцо вполне изолировано, да и в 3 кольце определенная изоляция по UAC есть. А ты нагородил огород, заставил пользователя вторую машину покупать, а теперь заявляешь — никаких гарантий надежности нет. Что-то все это крайне сомнительно, чтобы могло взлететь.
Я как раз заявляю что гарантии, обеспеченные таким способом лучше, чем отсутсвие и их.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Смайлик заметил, но если серьезно, то ни из чего не следует, что при нынешней элементной базе оно вообще возможно.
Наверняка возможно. Проблемы — в костыльно-заплаточной архитектуре процессоров, которая на такой рост вообще никогда не была рассчитана.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот теперь понял. Все ясно. Правда, последнее едва ли нужно — контрольная сумма и так в секторе есть.
Практика показывает, что этого не всегда достаточно.
PD>Ну что скажу... В общем, достаточно стройно и логично. PD>Я только не уверен в том, что этот алгоритм верификации действительно будет 100% надежным. То, что он , как ты говоришь, доказан — охотно готов поверить, но все равно не убеждает.
А вся современная математика тебя убеждает или нет?
PD>Дело в том, что ты тут привел идеальную схему. А вот что ты писал чуть раньше >>ОС находит те места, которые не может верифицировать и добавляет туда проверку. PD>Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме.
Мы тут обсуждали твоего сфероконя в которого я не верю.
Всё что я написал относится исключительно к крайне гипотетическому случаю если в доказательстве верификатора будет ошибка.
PD>А вот строгого доказательства того, что таких случаев будет действительно исчезающе мало — я не вижу. И мне остается только верить тебе на слово, что это будет очень редко, настолько редко, что этим можно пренебречь.
Если верификатор доказан их 0. Строго 0.
PD>Понимаешь, в чем дело ? Законы физики, тем более химии (говорю как химик по образованию) никогда не обязаны выполняться 100%.
Я понимаю, что ты путаешь математику и естественные науки.
В математике всё всегда определено на 100%
А тут у нас не физика и тем более не химия, а чистой воды математика.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>По тому что: WH>1)Надо верифицировать. WH>2)Чтобы можно было поддержать новые процессоры. WH>3)Чтобы старые программы начинали работать быстрее после обновления бэкенда. WH>Ты что вообще не читаешь что тут пишут?
Читаю. Но в начале мысль была, что натив не нужен. Потом, все-таки натив при установке приложения. В целом идея понятна.
PD>>Да живем же как-то без всего этого. И 0 кольцо вполне изолировано, да и в 3 кольце определенная изоляция по UAC есть. А ты нагородил огород, заставил пользователя вторую машину покупать, а теперь заявляешь — никаких гарантий надежности нет. Что-то все это крайне сомнительно, чтобы могло взлететь. S>Я как раз заявляю что гарантии, обеспеченные таким способом лучше, чем отсутсвие и их.
Гарантии , конечно, нынешняя система не дает.
Гарантию вообще никто не дает. То. что у нас называется гарантией, есть лишь заложенная в смету стоимость ремонта, если упадет, поделенная на всех покупателей
Но в целом нынешняя система достаточно надежна, доказательством чего является то, что она живет и работает.
Оснований менять на то, что ты предлагаешь — не вижу.
Здравствуйте, CoderMonkey, Вы писали:
CM>Наверняка возможно. Проблемы — в костыльно-заплаточной архитектуре процессоров, которая на такой рост вообще никогда не была рассчитана.
Если речь идет о x86/64 — согласен, костыль на костыле, но сделали же попытку создать Itanium, исходя из современных (тогда) принципов — и что ? Если бы он и впрямь дал прорыв в плане производительности — мы бы никакого x86/64 уже не имели.
Или ты что-то иное имеешь в виду ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>Но в целом нынешняя система достаточно надежна, доказательством чего является то, что она живет и работает.
Гомеопатия тоже живет и как бы работает.
PD>Оснований менять на то, что ты предлагаешь — не вижу.
Я не предлагал. Я показывал что кроме двух вариантов (иметь нэтив и не иметь) есть другие.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lpd, Вы писали:
lpd>>У нас регулярно появляются принципиально новые процессорные архитектуры, которые в разы быстрее и лучше предыдущих? WH>Так по тому и не появляются что невозможно перетащить на эти процессоры все программы.
Архитектур было предложено не так мало. Самые популярные x86 и arm. Про особенные преимущества других архитектур,
которым мешает совместимость, я ничего не слышал. Есть конкретные примеры в несколько раз более быстрых,
но незаслуженно редких архитектур, которые ты мог бы привести в обоснование своего утверждения?
Или, хотя бы, проекты таких процессоров?
Чем, вкратце, они принципиально лучше arm?
Если действительно появится процессор в два раза быстрее x86/arm, на него быстро спортируют ОС и перекомпилируют все программы.
Пока промежуточный код выглядит сложным решением несуществующих проблем.
lpd>>Сложно скомпилировать программу под все нужные процессоры? WH>Одну нет. WH>А вот все программы невозможно.
"Все" программы нужны только домашним пользователям, и вполне поддерживаются порты дистрибутивов Linux под разные процессоры.
lpd>>Лично я бы запретил распространять программы в промежуточных кодах, т.к. это усложняет и запутывает развертывание без значительной пользы. WH> Это просто противоречит вообще всему. WH>В случае с промежуточным кодом у тебя один бинарник который работает везде.
Чтобы бинарник работал везде, мне не надо; а если понадобиться, я его просто пересоберу.
В таком варианте в развертку и процесс отладки добавляются VM и хранение прекомпилированных исполняемых файлов.
Вот у тебя подпись про простоту. Почему не следуешь принципам, которые сам же декларируешь?
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
PD>>Я только не уверен в том, что этот алгоритм верификации действительно будет 100% надежным. То, что он , как ты говоришь, доказан — охотно готов поверить, но все равно не убеждает. WH>А вся современная математика тебя убеждает или нет?
Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180.
PD>>Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме. WH>Мы тут обсуждали твоего сфероконя в которого я не верю.
Имеешь право, но это не отменяет того факта, что тебе приходится к математическому доказательству хотя бы в теории допустить необходимость ручной проверки.
WH>Всё что я написал относится исключительно к крайне гипотетическому случаю если в доказательстве верификатора будет ошибка. PD>>А вот строгого доказательства того, что таких случаев будет действительно исчезающе мало — я не вижу. И мне остается только верить тебе на слово, что это будет очень редко, настолько редко, что этим можно пренебречь. WH>Если верификатор доказан их 0. Строго 0.
Это как-то противоречит утверждению о том, что возможна пусть даже гипотетически ситуация, когда "в доказательстве верификатора будет ошибка". Одно из двух — либо он доказал (в математическом смысле) — тогда ошибки быть не может, либо это не доказательство.
PD>>Понимаешь, в чем дело ? Законы физики, тем более химии (говорю как химик по образованию) никогда не обязаны выполняться 100%. WH>Я понимаю, что ты путаешь математику и естественные науки. WH>В математике всё всегда определено на 100%
Верно. Именно поэтому математическое доказательство не допускает ни в каком гипотетическом случае невыполнения того, что оно доказало. В естественных науках любой закон допускает , что при каких-то условиях он не выполняется. Так что ничего я не путаю.
Понимаешь, если хоть один раз на дециллион случаев сумма углов не будет равна 180 — надо пересматривать Евклидову геометрию. Больше ее доказательства не могут считаться верными. Даже если для получения следующего отклонения от 180 придется перебрать еще один дециллион треугольников.
А вот современная существующая архитектура основана не на доказательстве. Она в этом плане из естественного мира. И если она даст сбой даже не на дециллион, а лишь на гептиллион случаев — живем спокойно и не нервничаем.
Здравствуйте, samius, Вы писали:
PD>>Но в целом нынешняя система достаточно надежна, доказательством чего является то, что она живет и работает. S>Гомеопатия тоже живет и как бы работает.
-Моя программа работает в 10 раз быстрее твоей!
-Да, но моя работает.
Здравствуйте, lpd, Вы писали:
lpd>Архитектур было предложено не так мало. Самые популярные x86 и arm. Про особенные преимущества других архитектур, lpd>которым мешает совместимость, я ничего не слышал. Есть конкретные примеры в несколько раз более быстрых, lpd>но незаслуженно редких архитектур, которые ты мог бы привести в обоснование своего утверждения? lpd>Или, хотя бы, проекты таких процессоров?
Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд. Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов.
10% производительности на ровном месте тебе мало?
lpd>"Все" программы нужны только домашним пользователям, и вполне поддерживаются порты дистрибутивов Linux под разные процессоры.
Это просто не правда.
lpd>Чтобы бинарник работал везде, мне не надо; а если понадобиться, я его просто пересоберу.
А если это старая программа, исходники которой потеряны?
Вот я сейчас одну такую переписываю.
lpd>В таком варианте в развертку и процесс отладки добавляются VM и
О какой развёртке ты говоришь? Эта ВМ есть всегда.
Мы тут говорим про VM которая лежит в основе ОС. Вся ОС кроме микроскопических кусочков ядра написана под эту ВМ.
lpd>хранение прекомпилированных исполняемых файлов.
ОС делает это совершенно прозрачно для пользователей. Большинство пользователей об этом даже знать не будут. Большинство из тех, кто про это вообще в курсе будут знать об этом исключительно по тому что они про это где-то прочитали или им кто-то сказал.
И только разработчики ядра ОС будут иметь с этим дело.
lpd>Вот у тебя подпись про простоту. Почему не следуешь принципам, которые сам же декларируешь?
Я-то следую.
Я довольно долго писал код под платформы, которые распространяют промежуточный код.
Вот там всё просто. Скачал библиотеку и несколькими кликами подключил к проекту. Или ещё проще. Указал в настройках проекта что мне нужна вот такая библиотека. И она сама скачается.
А сейчас вынужден кое-что написать на С++. Вот тут АД. Без проблем встал только boost. Все остальные библиотеки требуют массы приседаний чтобы их вообще к проекту подключить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если речь идет о x86/64 — согласен, костыль на костыле, но сделали же попытку создать Itanium, исходя из современных (тогда) принципов — и что ? Если бы он и впрямь дал прорыв в плане производительности — мы бы никакого x86/64 уже не имели. PD>Или ты что-то иное имеешь в виду ?
Этого было недостаточно. Сейчас уже вполне очевидно, что росту частоты пришел конец и нужно намного больше ядер. Проблема в том, что для когерентного кэша накладные расходы растут полиномиально с ростом числа ядер. Значит — нужен некогерентный. А это значит — заодно переписывать все компиляторы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180.
А ты знаешь, что при переписывании доказательств математических теорем на верифицируемый машиной язык наши кучу ошибок в доказательствах? Ошибки конечно исправили, но сам факт.
Вот мы говорим ровно про такой случай.
PD>Это как-то противоречит утверждению о том, что возможна пусть даже гипотетически ситуация, когда "в доказательстве верификатора будет ошибка". Одно из двух — либо он доказал (в математическом смысле) — тогда ошибки быть не может, либо это не доказательство.
Либо доказательство с ошибкой.
Но учитывая то что верификатор маленький и простой как пень вероятность такой ошибки около нуля. И главное он тоже верифицирован машиной. Так что можно спать спокойно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд. Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов. WH>10% производительности на ровном месте тебе мало?
10% производительности роли не играют. Я бы даже пожертвовал 10% скорости ради упрощения процессора или ядра ОС, хотя это другой вопрос.
lpd>>В таком варианте в развертку и процесс отладки добавляются VM и WH>О какой развёртке ты говоришь? Эта ВМ есть всегда. WH>Мы тут говорим про VM которая лежит в основе ОС. Вся ОС кроме микроскопических кусочков ядра написана под эту ВМ.
Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.
WH>Я довольно долго писал код под платформы, которые распространяют промежуточный код. WH>Вот там всё просто. Скачал библиотеку и несколькими кликами подключил к проекту. Или ещё проще. Указал в настройках проекта что мне нужна вот такая библиотека. И она сама скачается. WH>А сейчас вынужден кое-что написать на С++. Вот тут АД. Без проблем встал только boost. Все остальные библиотеки требуют массы приседаний чтобы их вообще к проекту подключить.
Думаю, здесь дело в поддержке множества дистрибутивов, путей к стандартным библиотекам, заголовочных файлов, версий компиляторов и опций сборки. В Java/C# же вся инфраструктура в руках VM. С++ я не идеализирую, однако в данном случае проявляются недостатки устройства ОС, а не бинарного кода.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд.
Это верно не только для x86. Имплементации risc\cisc могут быть разные. Но да, cisc сложнее и требует больше приседаний.
WH>Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов.
Можно какое-либо подтверждение этому высказыванию? ПОчему десяток, а не пяток или сто процентов?
Здравствуйте, lpd, Вы писали:
lpd>10% производительности роли не играют. Я бы даже пожертвовал 10% скорости ради упрощения процессора или ядра ОС, хотя это другой вопрос.
А тут мы упрощаем и ОС, и процессор и прибавляем в скорости.
lpd>Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.
Тут ты просто что-то себе навыдумывал.
lpd>Думаю, здесь дело в поддержке множества дистрибутивов, путей к стандартным библиотекам, заголовочных файлов, версий компиляторов и опций сборки. В Java/C# же вся инфраструктура в руках VM. С++ я не идеализирую, однако в данном случае проявляются недостатки устройства ОС, а не бинарного кода.
И нативного кода тоже.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
S>Можно какое-либо подтверждение этому высказыванию? ПОчему десяток, а не пяток или сто процентов?
Это оценка человека который проектирует процессоры.
В любом случае перекодировщик совершенно точно не бесплатный.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот об URI я и говорю
PD>Мне вот этот формат
PD>https://www.google.ru/search?newwindow=1&ei=gfleWpawL8GcsgGSvIewBg&q=get+http+format+URI&oq=get+http+format+URI&gs_l=psy-ab.3..0i22i30k1.36647.38270.0.38847.4.4.0.0.0.0.141.508.1j3.4.0....0...1c.1.64.psy-ab..0.4.499...33i160k1.0.Wjec5wew_bo
PD>c упаковкой параметров через '&" и знаком вопроса не кажется особенно элегантным. Для 1990 года он был хорош, но сейчас все же можно и что-то лучше структурированное предложить.
В протоколе HTTP нет ничего про & и знаки вопроса.
Он вообще всё, что после hostname, не регламентирует никак — ну, кроме charset. PD>И вот тут я не уверен. Формат "список ключ:значение" можно было бы тоже на что-то более структурированное заменить.
И какую проблему это призвано решить?
Я просто знаю про людей (это авторы Microsoft Exchange), которым казалось, что хранить заголовки писем в текстовом виде — затратно.
(На всякий случай поясню, что вот эта часть HTTP — не его собственность, а MIME — несколько более общий формат; принятый, в том числе, и в email).
Они придумали классную вещь — каждый раз, когда встречался новый заголовок,его заносили в список заголовков,и присваивали ему 16битное число. В итоге они огребли в полный рост, и были вынуждены отказаться от этого решения.
Я не испытываю желания бегать по известным граблям.
PD>По существу, HTTP запрос — это же просто вызов некоторого метода клиентом через сеть на сервере. Своего рода RPC. И этому методу надо параметры передать.
Это плохой способ представлять себе работу HTTP. PD>Если бы ты (демиург) в момент, когда старое ПО уже уничтожено, а новое еще не создано, стал бы проектировать способ передачи параметров — ты точно сделал бы ее передачу в двух местах (а для POST/PUT и в 3 — json/xml в body) и в таком формате ?
Да, именно в двух местах.
Параметры в URL — это не часть HTTP. Это как если бы кто-то делал параметр частью имени метода. То есть вызываем не power(x, 2), а power2(x), power5(x), power435345(x).
Заголовки — это такая специальная штука с предопределённым значением. Благодаря им, между клиентом и сервером можно вклинить proxy, который умеет делать разные полезные штуки. Это не "параметры метода" — RPC это вообще плохая идея сама по себе, а уж тем более плохой способ думать о HTTP.
А структура body, которая, собственно, и является "параметром", в протоколе никак не закреплена.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lpd, Вы писали:
lpd>>Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему. WH>Тут ты просто что-то себе навыдумывал.
Это ты сводишь вопрос к сравнению своего опыта приложений Java/C# vs С++.
Непростая закулиса VM необходима, и у нее могут быть настройки, несовместимости и баги.
Так или иначе, VM добавляет еще один слой абстракции между процессором и высокоуровневым языком программирования. Это усложнение жизни ты предлагаешь провести ради весьма гипотетического облегчения жизни процессоростроителям. Я предлагаю сначала доказать существование проблемы, и только затем прилагать усилия для ее решения, объективно взвешивая все за и против. Лучшим вариантом я бы вообще считал отсутствие зоопарка процессоров.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, CoderMonkey, Вы писали:
CM>Этого было недостаточно. Сейчас уже вполне очевидно, что росту частоты пришел конец и нужно намного больше ядер. Проблема в том, что для когерентного кэша накладные расходы растут полиномиально с ростом числа ядер. Значит — нужен некогерентный. А это значит — заодно переписывать все компиляторы
Боюсь, что для NUMA новым компилятором не отделаешься.
Здравствуйте, Sharov, Вы писали: S>Если не правильно составил запрос -- логическая ошибка, как типизация поможет?
Точно так же, как она помогает в обычных языках. Это в K&R С можно было перепутать местами адрес строки и номер позиции в ней, и компилятор бы и бровью не повёл.
Современный C зачем-то отличает char* от int.
А вот жизнь всем разработчикам субд осложнила бы. Да и от диалектов это бы не спасло. S>Про декомпозицию вообще не понял.
Попробуйте написать функцию, которая возвращает список заказов, а в параметрах принимает список менеджеров.
Чтобы можно было, скажем, передать туда не XML (омг!), а, к примеру, select manager_id from managers where RegionCode = "LATAM"
А в другом месте — select manager_id from managers where director_id = 850.
Классика жанра — постройте мне table-valued функцию, которая возвращает список заказов по заданным параметрам.
При этом параметры могут быть NULL, что означает "не фильтровать по заданному параметру".
На строго типизированном linq это нефиг делать:
if (startDate.HasValue)
{
q = from s in q where s.Date >= startDate.Value select s
}
if (endDate.HasValue)
{
q = from s in q where s.Date <= endDate select s
}
На T-SQL вы либо убьёте производительность, написав длиннющюю простыню из OR startDate is NULL, либо будете мучительно клеить строки и вызывать EXEC, надеясь что в продакшне не стрельнет редкое сочетание параметров или что там не затешется SQL injection.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, lpd, Вы писали:
lpd>Это ты сводишь вопрос к сравнению своего опыта приложений Java/C# vs С++. lpd>Непростая закулиса VM необходима, и у нее могут быть настройки, несовместимости и баги.
И где всего этого добра нет?
lpd>Так или иначе, VM добавляет еще один слой абстракции между процессором и высокоуровневым языком программирования.
Это не правда. Все компиляторы имеют внутри себя некоторую ВМ. Или даже несколько. Просто они не сохраняют этот код, а сразу генерируют нативный код.
lpd>Это усложнение жизни ты предлагаешь провести ради весьма гипотетического облегчения жизни процессоростроителям.
Вполне реального. Ты вообще видел, как происходил переход с x86-32 на x86-64. Это же просто курам на смех. Процессор обновился куча софта работать перестала. Несколько лет прошло прежде чем всё снова заработало.
lpd>Я предлагаю сначала доказать существование проблемы, и только затем прилагать усилия для ее решения, объективно взвешивая все за и против.
Я её своими глазами видел. Итаниум вообще сдох из-за этого.
lpd>Лучшим вариантом я бы вообще считал отсутствие зоопарка процессоров.
Есть много разных задач. И для них нужны разные процессоры.
Так что лучшим решением является ОС на основе ВМ. В этом случае мы можем легко запустить главную задачу на наиболее подходящем процессоре и получить весь периферийный софт совершенно без усилий.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lpd, Вы писали:
lpd>>Лучшим вариантом я бы вообще считал отсутствие зоопарка процессоров. WH>Есть много разных задач. И для них нужны разные процессоры. WH>Так что лучшим решением является ОС на основе ВМ. В этом случае мы можем легко запустить главную задачу на наиболее подходящем процессоре и получить весь периферийный софт совершенно без усилий.
Embedded не считаем, т.к. там никто не будет для каждой прошивки городить VM. Остаются только универсальные PC, где рынок поделен между Intel и в некоторой степени ARM. Не вижу необходимости помогать в конкуренции ни одному из них.
За последние 15 лет принципиально новыми процессорами можно считать только разве что GPU. Поэтому я не думаю, что ситуация изменится без научных прорывов.
WH>Я её своими глазами видел. Итаниум вообще сдох из-за этого.
Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
PD>>Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180. WH>А ты знаешь, что при переписывании доказательств математических теорем на верифицируемый машиной язык наши кучу ошибок в доказательствах? Ошибки конечно исправили, но сам факт.
Эээ, минуту. В чем нашли-то ? В доказательствах или в теоремах ? Если первое — это на сами теоремы вообще-то никак не влияет. Ну нашли ошибку в доказательстве, но теорема-то верна ? Надо ее по-иному доказать, вот и все.
А вот если нашли случай неверности теоремы — это совсем иное.
WH>Вот мы говорим ровно про такой случай.
PD>>Это как-то противоречит утверждению о том, что возможна пусть даже гипотетически ситуация, когда "в доказательстве верификатора будет ошибка". Одно из двух — либо он доказал (в математическом смысле) — тогда ошибки быть не может, либо это не доказательство. WH>Либо доказательство с ошибкой.
WH>Но учитывая то что верификатор маленький и простой как пень вероятность такой ошибки около нуля. И главное он тоже верифицирован машиной. Так что можно спать спокойно.
Ладно, будем спать спокойно.
Подводя итог (со своей стороны).
Я вовсе не против этой идеи. Вполне возможно, что она имеет право на существование. Мой скепсис объясняется в основном интуитивным недоверием к аргументу "математически доказано" в применении к ИТ. Просто о доказательствах правильности программ я слышал еще во времена моей молодости, и, похоже, в плане практического применения этих доказательств дело обстоит примерно так же, как во времена моей молодости
Так что если и впрямь появится такая система, используемая в промышленных масштабах — посмотрим на нее и будем судить, насколько она надежнее существующих. Прототипы вроде Singularity меня не убеждают — на моей памяти было много хороших идей, которые на этапе прототипирования или даже создания альфа-версии казались перспективными, а в итоге никуда не пошли.
Впрочем, это неважно, мы не на заседании комитета стандартов. Назовем это не HTTP, а реальной практикой использования HTTP, а в ней эти ?& точно уж есть. Оставил бы их как есть ?
PD>>И вот тут я не уверен. Формат "список ключ:значение" можно было бы тоже на что-то более структурированное заменить. S>И какую проблему это призвано решить?
Да не в проблеме же дело, речь идет не о том, чтобы решить какую-то проблему, а о том, как это должно бы выглядеть при проектировании. Надо спроектировать новый протокол, и при этом ты знаешь, что это не однодневка будет, а нечто на годы, если не на века. И надо его сделать как можно более стройным и логичным.
Оставишь как есть или все же изменишь ?
PD>>По существу, HTTP запрос — это же просто вызов некоторого метода клиентом через сеть на сервере. Своего рода RPC. И этому методу надо параметры передать. S>Это плохой способ представлять себе работу HTTP. PD>>Если бы ты (демиург) в момент, когда старое ПО уже уничтожено, а новое еще не создано, стал бы проектировать способ передачи параметров — ты точно сделал бы ее передачу в двух местах (а для POST/PUT и в 3 — json/xml в body) и в таком формате ? S>Да, именно в двух местах. S>Параметры в URL — это не часть HTTP.
Да ладно, пусть не часть. Но практика такова, что это часть. Хорошо, не HTTP сам, а эту практику ты бы оставил как есть или все же поменял ?
S>Заголовки — это такая специальная штука с предопределённым значением. Благодаря им, между клиентом и сервером можно вклинить proxy, который умеет делать разные полезные штуки. Это не "параметры метода" — RPC это вообще плохая идея сама по себе, а уж тем более плохой способ думать о HTTP. S>А структура body, которая, собственно, и является "параметром", в протоколе никак не закреплена.
Хорошо, заголовки отложим. Пусть так. Но от того, что часть параметров де-факто передается через URL, а часть — через body, ты никуда не денешься. Оставил бы так же ?
Кстати, оставил бы де-факто существующий запрет в GET передавать body ?
Здравствуйте, Pavel Dvorkin, Вы писали: S>>В протоколе HTTP нет ничего про & и знаки вопроса. PD>Ну по крайней мере в версии RFC 2616 '?' есть PD>https://tools.ietf.org/html/rfc2616#section-3.2.2 PD>Впрочем, это неважно, мы не на заседании комитета стандартов. Назовем это не HTTP, а реальной практикой использования HTTP, а в ней эти ?& точно уж есть. Оставил бы их как есть ?
Упростил бы. В текущей спеке слишком много деталей про структуру URI — она заставляет людей думать, что надо делать именно так. Например,
Интерпретация URI — это уже дело user-agent. А в рамках протокола даже использование relative URI — уже плохая идея.
PD>Да не в проблеме же дело, речь идет не о том, чтобы решить какую-то проблему, а о том, как это должно бы выглядеть при проектировании. Надо спроектировать новый протокол, и при этом ты знаешь, что это не однодневка будет, а нечто на годы, если не на века. И надо его сделать как можно более стройным и логичным. PD>Оставишь как есть или все же изменишь ?
Саму схему бы оставил; конкретные особенности бы упростил. В частности, слишком много заголовков управляют сроками годности и кэшированием. Тут тебе и Cache-control:max-age, тут и Expires.
Всё это стоило бы ортогонализировать и ужесточить требования к серверам.
PD>Да ладно, пусть не часть. Но практика такова, что это часть. Хорошо, не HTTP сам, а эту практику ты бы оставил как есть или все же поменял ?
Оставил бы конечно. На её основе работают крайне полезные механизмы.
PD>Хорошо, заголовки отложим. Пусть так. Но от того, что часть параметров де-факто передается через URL, а часть — через body, ты никуда не денешься. Оставил бы так же ?
Да. PD>Кстати, оставил бы де-факто существующий запрет в GET передавать body ?
Да. Без этого невозможно построить корректное кэширование ответов на GET.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Одним махом уничтожается весь существующий нативный код.
Ну ты же сам просил именно об этом. Выкидываем весь этот ужасный нативный код на помойку, и пишем уже на нормальных, статически-верифицированных платформах. PD>Далее. Представь себе, что это программа линейной алгебры. Там этих a[i][j] в каждой строке может быть по нескольку штук. Если заставлять каждое такое описание верифицировать по твоему механизму — код за этими верификациями видно уже не будет, а отладка превратится в ад.
Ничего подобного. Мы же пишем не на K&R C, а на полноценном языке программирования, созданном с нуля.
В нём компилятор с верфикатором видят, что i и j заведомо ограничены размерами обрабатываемых массивов, поэтому никаких проверок внутри циклов нет.
PD>А не запретишь. И управляемые языки не помогут. Ты же ОС собрался делать, и что, ты мне скажешь, что в этой ОС писать "тяжелый" код можно только на управляемых языках?
Конечно. PD> Он и без того тяжелый, там O(N^3), например, а мне, выходит, его оптимально написать нельзя ?
Почему нельзя? Можно. PD>Кроме того, почему ты решил, что массив отведен в стеке ? Для него относительно просто написать stack_available. А если в куче ? Да еще двумерный и при этом jagged ? И при этом еще и не прямоугольный, а хорошо если только треугольный ? Тебе не кажется, что такая "статическая" проверка просто не получится ? А еще realloc (в С) есть. А еще union в нем же есть.
Ну мы же выкинули язык C за ненадобностью. Вместе с union. И вместо realloc у нас операция, которая "сбрасывает" результаты проверок, и верификатор потребует повторной проверки.
PD>Что-то у меня такое ощущение, что это лекарство хуже болезни. Сейчас мне как программисту по крайней мере все ясно — я могу делать (в нативе) что хочу, за свои безобразия в юзермодной части АП я отвечаю сам (кстати, и тут мне помогают, доступ к невыделенным адресам блокируется), а за попытку безобразия в системной части АП будут бить со 100% гарантией. И код я при этом пишу, как его всегда писали. А тут предлагается писать его совсем по-другому, с массой накладных расходов, а успех не гарантирован.
Павел, ты уже реши — хочется "пишу, как его всегда писали", или какого-то прогресса. Если хочется того же самого, что есть сейчас — ну так оно и сейчас есть. Со всеми его недостатками — ограниченным быстродействием процессоров, и дырами в "абсолютной защите" сверху донизу. А если хочется реально изменить мир, без оглядки на существующий код, то надо идти в правильных направлениях.
Убираем все эти неэффективные кольца защиты, и сразу получаем ускорение на вызовах системного кода. А потом можно уже и процессор поменять — раз нету кода, который бы прыгал между разными кольцами, то все эти аппаратные проверки можно просто выкинуть, и наиграть ещё производительности и энергоэффективности на ровном месте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PD>>Да ладно, пусть не часть. Но практика такова, что это часть. Хорошо, не HTTP сам, а эту практику ты бы оставил как есть или все же поменял ? S>Оставил бы конечно. На её основе работают крайне полезные механизмы.
Не забудь, ты демиург. Существующие, пусть и полезные, механизмы тебя не ограничивают. Если можно сделать по-другому при том, что, конечно, эти механизмы можно будет иплементировать — имеешь право.
PD>>Хорошо, заголовки отложим. Пусть так. Но от того, что часть параметров де-факто передается через URL, а часть — через body, ты никуда не денешься. Оставил бы так же ? S>Да.
Почему ? Твой аргумент насчет того, что хедер — это не параметр, я могу относительно принять. Относительно потому, что через header часто передают и user-defined values. Может, это опять же не стандарт, но де-факто такая практика есть.
А вот насчет того, что часть параметров передается через URL, а часть через body — я аргументов от тебя не услышал.
Так что в итоге все же 3 места (для POST/PUT). URL, header user defined, body
PD>>Кстати, оставил бы де-факто существующий запрет в GET передавать body ? S>Да. Без этого невозможно построить корректное кэширование ответов на GET.
Хм. Почему при передаче параметров через URL можно, а через body — нельзя ? В любом случае это R/O информация для запроса. В ответе ее нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WolfHound, Вы писали:
WH>>ОС находит те места, которые не может верифицировать и добавляет туда проверку.
PD>М-да... В общем, без проверок в рантайме ничего не выходит ни у тебя, ни у AlexRK. Если ОС или верификатор не может верифицировать, надо вставлять проверку в рантайме, PD>Кстати, не совсем понял, как ОС верифицировать-то будет ? Вроде в дискуссии с AlexRK мы исходили из того, что проверяет статический анализатор на этапе компиляции. PD>Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
Павел, у меня такое ощущение, что последние 10 лет прошли мимо. Я бы понял, если бы мы обсуждали какую-то новую, гипотетическую идею.
Но ведь мы говорим о вещах, проверенных на практике.
В частности, Singularity была выпущена чёрти когда. И "не пошла" она не потому, что там дыра в верификаторе, или что программы под неё невозможно написать.
А тупо потому, что нет волшебной палочки, способной выбросить на помойку весь существующий код. PD>Вот только бы знать, насколько менее надежен.
Он намного более надёжен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну ты же сам просил именно об этом. Выкидываем весь этот ужасный нативный код на помойку, и пишем уже на нормальных, статически-верифицированных платформах.
Если бы ты пораньше ответил, я бы с тобой подискутировал на тему статической верификации. А так мы уже с AlexRK, WolfHound и samius вчера столько понаписали, что повторяться не буду.
PD>>А не запретишь. И управляемые языки не помогут. Ты же ОС собрался делать, и что, ты мне скажешь, что в этой ОС писать "тяжелый" код можно только на управляемых языках? S>Конечно.
Жестко. Ты лишаешь в принципе возможности писать на нативе, за исключением чего-то, что пишут особо доверенные лица и компании. Я не уверен, что это будет принято.
PD>> Он и без того тяжелый, там O(N^3), например, а мне, выходит, его оптимально написать нельзя ? S>Почему нельзя? Можно.
Я не думаю, что стоит еще раз начинать флейм на тему : можно ли на управляемом коде написать столь же эффективно, как на нативе. Мою позицию ты знаешь.
PD>>Кроме того, почему ты решил, что массив отведен в стеке ? Для него относительно просто написать stack_available. А если в куче ? Да еще двумерный и при этом jagged ? И при этом еще и не прямоугольный, а хорошо если только треугольный ? Тебе не кажется, что такая "статическая" проверка просто не получится ? А еще realloc (в С) есть. А еще union в нем же есть. S>Ну мы же выкинули язык C за ненадобностью. Вместе с union. И вместо realloc у нас операция, которая "сбрасывает" результаты проверок, и верификатор потребует повторной проверки.
Вот это поясни. Верификатор, что, в рантайме работает ? Тогда это уж никак не статический верификатор, а просто динамический контроль индексов в стиле Java/C#
PD>>Что-то у меня такое ощущение, что это лекарство хуже болезни. Сейчас мне как программисту по крайней мере все ясно — я могу делать (в нативе) что хочу, за свои безобразия в юзермодной части АП я отвечаю сам (кстати, и тут мне помогают, доступ к невыделенным адресам блокируется), а за попытку безобразия в системной части АП будут бить со 100% гарантией. И код я при этом пишу, как его всегда писали. А тут предлагается писать его совсем по-другому, с массой накладных расходов, а успех не гарантирован. S>Павел, ты уже реши — хочется "пишу, как его всегда писали", или какого-то прогресса. Если хочется того же самого, что есть сейчас — ну так оно и сейчас есть. Со всеми его недостатками — ограниченным быстродействием процессоров, и дырами в "абсолютной защите" сверху донизу. А если хочется реально изменить мир, без оглядки на существующий код, то надо идти в правильных направлениях.
Я хочу идти в правильном направлении, но я не уверен, что это направление правильное.
Здравствуйте, Sinclair, Вы писали:
S>Но ведь мы говорим о вещах, проверенных на практике. S>В частности, Singularity была выпущена чёрти когда. И "не пошла" она не потому, что там дыра в верификаторе, или что программы под неё невозможно написать. S>А тупо потому, что нет волшебной палочки, способной выбросить на помойку весь существующий код.
Это, несомненно, так, да вот только не доказано, что ее эксплуатация не выявила бы серьезные проблемы, даже при наличии волшебной палочки.
PD>>Вот только бы знать, насколько менее надежен. S>Он намного более надёжен.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме.
Ты не понимаешь, что такое верификация, и что такое "верифицировать не удастся".
Полноценная верификация произвольного кода эквивалентна проблеме останова.
Поэтому в реальных системах верификация делается "скептической".
Это означает, что иногда верификатор "не видит" корректности кода. Условно:
InfinitePrecision Fail()
{
var a = GetInputFromUser();
var b = sin(a)*sin(a)+cos(a)*cos(a);
return sqrt(b - 1.0); // верификатор: possible negative!
}
Такая программа не пройдёт верификацию, если нам запрещено вычислять квадратный корень из отрицательных аргументов. Автор знает, что b всегда равно 1, но верификатор неспособен это доказать.
Чтобы программа заработала, программисту придётся обложить вызов sqrt в _данном месте_ проверкой:
InfinitePrecision Fail()
{
var a = GetInputFromUser();
var b = sin(a)*sin(a)+cos(a)*cos(a);
if (b>=0)
return sqrt(b - 1.0); // верификатор: ok!else
return 42;
}
Совершенно необязательно для этого замусоривать весь код такими проверками. В тех местах, где вывод можно сделать автоматически, он делается автоматически.
Опять же, никто не мешает обернуть нашу sqrt в safe_sqrt(), которая прячет внутри проверку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, WolfHound, Вы писали:
PD>>>Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown. WH>> WH>>Это просто курам на смех. Обновить ОС куда проще. После чего ОС перепроверит весь установленный софт.
_>Так ты хочешь верификатор, который работает не с исходным, а с исполняемым кодом? Хм хм хм...
Именно такой верификатор встроен в Singularity. Не вижу никакого смысла цепляться за идею поставки сырого кода x86 на машину пользователя.
Если нас не беспокоит время старта приложения — то тупо делаем верификацию непосредственно перед JIT.
Если беспокоит — то выполняем верификацию перед ngen.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, lpd, Вы писали: lpd>Embedded не считаем, т.к. там никто не будет для каждой прошивки городить VM. Остаются только универсальные PC, где рынок поделен между Intel и в некоторой степени ARM. Не вижу необходимости помогать в конкуренции ни одному из них. lpd>За последние 15 лет принципиально новыми процессорами можно считать только разве что GPU. Поэтому я не думаю, что ситуация изменится без научных прорывов.
Вы путаете причину и следствие. Отсутствие новых процессоров — это последствия огромного багажа несовместимого кода.
Вывести новую архитектуру на рынок — это титанические инвестиции. А вот если бы основные современные платформы были бы построены на промежуточном коде, то новые процессоры бы выходили ежеквартально.
pd>Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.
Это проблема курицы и яйца. Вот есть итаниум — он дорогой, потому что его мало выпускают.
Выпускают мало потому, что его мало покупают.
Покупают мало потому, что он дорогой, и под него нет софта.
Софта под него нет потому, что его очень мало, и производителям тупо невыгодно заниматься поддержкой ещё одной платформы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот это поясни. Верификатор, что, в рантайме работает ? Тогда это уж никак не статический верификатор, а просто динамический контроль индексов в стиле Java/C#
Вы никак не поймете простую вещь. Верификатор работает на этапе компиляции (ну, еще на этапе инсталляции происходит верификация промежуточного кода, но речь не об этом). Компилятор заставляет вставить рантайм-проверки в тех местах, где они нужны. Но это совершенно не эквивалентно тому, что есть в C#/Java! В управляемых языках проверки вставляются во всех местах, а в статически верифицированном коде — только там, где надо. Таких мест может быть на порядок меньше.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Ziaw, Вы писали:
Z>>А задача армии дизайнеров и верстальщиков, сверстать дизайн в миллиметрах для каждого экрана.
MTD>Вот смотри. Палец среднестатистического человека, допустим имеет пятно контакта 5 на 5 мм, из этого следует, что надо кнопочку сделать 10 на 10 мм, условно. Потом, есть текст, известно, что он хорошо читается размером 7 мм, тоже условно. Если задавать размеры в мм, то и выглядеть везде будет одинаково и взаимодействовать будет возможно одинаково.
На одном экране помещается три кнопочки по 5мм в одну строку, на другом 50, в промежуточных — разное количество с разными полями между ними. Каждый интерфейс надо будет адаптировать под каждый экран.
MTD>Еще раз — 1 раз задать, получить одно и тоже везде. Теперь переходим к условным попугаям в пикселах — в зависимости от плотности пикселов размер меняется в разы, так что твой комментарий актуален сейчас, если перейти на миллиметры жизнь серьезно упроститься.
Не понимаю как получится. Можешь нарисовать любой простой интерфейс с размерами в мм для телефона , планшет и монитора и рассказать, как можно будет организовать показ их же в промежуточных размерах? Те же мониторы имеют большой диапазон размеров.
Сейчас например можно любой монитор отобразить на телевизоре или проекторе, как предлагаешь поступать в этих случаях?
Здравствуйте, Sinclair, Вы писали:
S>Вы путаете причину и следствие. Отсутствие новых процессоров — это последствия огромного багажа несовместимого кода.
В таком случае были бы патенты на эти технологии. Я ничего не слышал. Можно одну ссылку на что-то действительно полезное,
чего нет в популярных современных процессорах?
S>Вывести новую архитектуру на рынок — это титанические инвестиции. А вот если бы основные современные платформы были бы построены на промежуточном коде, то новые процессоры бы выходили ежеквартально.
В Windows отсутствие софта действительно проблема. У Debian же есть порт и для Itanium. Пакетов поддерживается много — 9 dvd.
Перевести пользователей на новую архитектуру, конечно, трудно. Однако, софт не выглядит основной причиной этого. Высокоуровневые языки программирования(С++) и без того достаточно портабельные.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, AleksandrN, Вы писали:
MTD>>>1. Никаких кодировок кроме utf-8
AN>>Почему не UTF-16 или UTF-32?
MTD>Потому что у них нет никаких достоинств перед utf-8, а недостатки есть, например:
Ну как минимум одно достоинство у них всё-таки есть. В utf-8 cимвол по номеру в строке ищется за константное время,только если он английский. C utf-16 это распространяется на большинство языков, а с utf-32 — вообще на всё.
Здравствуйте, lpd, Вы писали:
S>>Вы путаете причину и следствие. Отсутствие новых процессоров — это последствия огромного багажа несовместимого кода. lpd>В таком случае были бы патенты на эти технологии. Я ничего не слышал. Можно одну ссылку на что-то действительно полезное, lpd>чего нет в популярных современных процессорах?
Не так смотрите. Вопрос не в том, что что-то принципиально новое. Вопрос в том, что это всё уже давно есть, но используется сильно меньше, чем надо.
Например, x86 и ARM одинаково требуют трансляции команд (переименование регистров и т.п.), отслеживания зависимостей, но энергопотребление этих блоков у x86 в разы больше.
Если бы переход на стиль ARM был прозрачен, Intel не цеплялась бы за совместимость с тараканами 8080. И даже если бы они сохранили свой CISC, им было бы значительно проще выкинуть кучу неактуального.
S>>Вывести новую архитектуру на рынок — это титанические инвестиции. А вот если бы основные современные платформы были бы построены на промежуточном коде, то новые процессоры бы выходили ежеквартально.
lpd>В Windows отсутствие софта действительно проблема. У Debian же есть порт и для Itanium. Пакетов поддерживается много — 9 dvd. lpd>Перевести пользователей на новую архитектуру, конечно, трудно. Однако, софт не выглядит основной причиной этого. Высокоуровневые языки программирования(С++) и без того достаточно портабельные.
Софт именно что выглядит проблемой. В Debian фактически живёт только то, что поставляется в исходниках. Исключений мало и они, даже если принципиальны в своих узких областях, не делают общей погоды.
Портабельность на C++ — расскажите это тем, кто мучался с портированием на 64 бита, а сейчас мучается от несовместимости в пределах этого (например, разный long).
Здравствуйте, WolfHound, Вы писали:
lpd>>Я предлагаю сначала доказать существование проблемы, и только затем прилагать усилия для ее решения, объективно взвешивая все за и против. WH>Я её своими глазами видел. Итаниум вообще сдох из-за этого.
Не из-за этого, а из-за своей изначальной инвалидности. Впрочем, ты прав в том, что если бы софт был весь на п-коде/IL (не важно, какой реализации), на него было бы легче взгромоздить столько софта, что он помучался бы не пять лет, а 20.
Но остаётся вопрос принципиально разных архитектур (CPU vs. GPU) и оптимизаций под конкретное железо. А вот тут большая загвоздка — те, кто для конкуренции вылизывает даже 1%, не пойдут на тотальный AOT, потому что в нём всегда будет меньше гибкости. А таких достаточно много.
Здравствуйте, Terix, Вы писали:
MTD>>>>1. Никаких кодировок кроме utf-8
AN>>>Почему не UTF-16 или UTF-32?
MTD>>Потому что у них нет никаких достоинств перед utf-8, а недостатки есть, например:
T>Ну как минимум одно достоинство у них всё-таки есть. В utf-8 cимвол по номеру в строке ищется за константное время,только если он английский. C utf-16 это распространяется на большинство языков, а с utf-32 — вообще на всё.
Стандартная и грубая ошибка. Символ ты так не найдёшь. Ты найдёшь кодовый пункт. Символ может иметь модификаторы. Чтобы их достоверно подключить, всё равно надо вызывать умную читалку, которая по таблице свойств будет проверять, что идёт за первым пунктом. Если ты этого не делаешь, твой код тупо некорректен.
Ну а если он работает только для английского — utf-8 снова полезнее, бо компактнее.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, lpd, Вы писали:
N>Если бы переход на стиль ARM был прозрачен, Intel не цеплялась бы за совместимость с тараканами 8080. И даже если бы они сохранили свой CISC, им было бы значительно проще выкинуть кучу неактуального.
Не факт, что это legacy в Intel значительно замедляет процессор. Да, процессоростроители прилагают дополнительные усилия для поддержки 32-бит, потому что хотят иметь это конкурентное преимущество. Не считаю, что программисты и пользователи должны возиться с VM ради облегчения жизни Intel.
При большем числе конкурентов Intel процессоры могли бы подешеветь. Но вряд ли появились бы процессоры в разы быстрее.
У ARM есть как значительные плюсы, так и некоторые минусы на мой взгляд неспециалиста(сложности с инициализацией констант и длиной branch). Не думаю, что популярности ARM на серверах мешает отсутствие софта.
N>Софт именно что выглядит проблемой. В Debian фактически живёт только то, что поставляется в исходниках. Исключений мало и они, даже если принципиальны в своих узких областях, не делают общей погоды.
Еще раз: для Itanium 9 DVD Debian-пакетов. Для Linux все поставляется в исходниках, кроме отдельных исключений, не являющихся уникальными.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, WolfHound, Вы писали:
_>>Даже для 3-ёх строчных скриптов? ) Вот буквально вчера у меня тут обнаружилось, что fb2 файлы скаченные с одного известного сайта имеют некорректную структуру (содержат html entities, хотя fb2 — это обычный xml) и из-за этого не читаются некоторым ПО. Проблема была решена (причём для целой папки таких fb2 файлов за раз) за минуту в три строчки на Питоне. На популярных статических языках я бы к этому времени успел бы разве что оборудовать инфраструктуру (настроить проект или скрипты сборки) и перешёл бы к написанию обязательного каркаса приложения... WH>1)Скриптам никто не мешает быть статически типизированными.
А что ты называешь скриптами? Факт наличия интерпретатора на мой взгляд вообще ни о чём не говорит (он даже у C++ есть, а у Питона наоборот есть свой JIT вариант), да и выполнял я вышеописанные команды не в REPL, а набросав скрипт в Notepad++ и запустив в командной строке. Чаще всего скриптами называют как раз короткие фрагменты на языках с динамической типизацией. Ну и помимо этого весьма актуально отсутствие в языке всяческих обязательных каркасов приложения (типа main в C++ или вообще никчемного класса в Java/C#).
WH>2)Создание консольного приложения на C# занимает несколько секунд.
Угу, в фантазиях. )
_>>Согласен (и кстати для МК не обязательно делать исключение). WH>Тут ИМХО нельзя всех под одну гребёнку.
Ну скажем тот же LLVM это вполне может. Правда там возникают вопросы с заменой стандартной библиотеки языка (под МК обычно используется специализированная версия)...
_>>И думаю что идеальной заменой нативного кода должно быть что-то вроде LLVM IR. Согласен? ) WH>Формат промежуточного кода отдельный и большой разговор. WH>Туда как минимум нужно добавить дафну. Ну и стековая ВМ гораздо практичнее для такого применения.
Ну если проектировать с нуля (как хотел автор изначальной темки) непосредственно для этой задачи, то конечно можно сделать намного лучше существующих вариантов. Я имел в виду, что из всех уже готовых решений на данный момент, это выглядит наиболее подходящим вариантом. И кстати выбор команды WebAssembly это подтверждает.
WH>>>3)За основу ОС берем мидори. http://joeduffyblog.com/2015/11/03/blogging-about-midori/ _>>Крайне сомнительно. WH>Обоснуй.
Проблема таких систем (кстати Midori/Singularity далеко не первые в этой области, намного раньше было например такое http://www4.cs.fau.de/Projects/JX/index.html решение), что они очень ультимативные: или всё прикладное ПО написано на соответствующем управляемом языке или система просто не работает (нельзя написать один критичный кусочек на голом ассемблере). Ну и соответственно пока я не увижу реализацию например кодека h.264 на управляемом языке, не уступающую по эффективности классическим нативным реализациям, то в нормальное будущее подобной ОС не поверю.
WH>>>в)Добавляем http://halide-lang.org/ для параллельного программирования. _>>Ну "параллельное программирование" — это громко сказано. Всё же в общем случае оно делится (на современном железе) на 3 совместно работающих уровня: SIMD, многоядерность (решения типа OpenMP), кластеры (решения типа MPI). И данный язык, насколько я помню, занимался решением только нижнего уровня параллельности (SIMD). WH>Не правильно. В текущей реализации SMID и многоядерность. Но саму модель можно и на кластер натянуть. В данном случае между многоядерностью и кластером разницы никакой.
Хы, ну возможно. Я с самим языком подробно не возился, помню только что мы обсуждали нюансы с SIMD векторами... )
WH>Но тут я имел в виду немного другое. Я делю многопоточное программирование на 2 типа. WH>Асинхронное. Это когда мы много ждём и мало считаем. WH>Параллельное. Это когда у нас есть пачка данных и нам её нужно очень быстро посчитать.
Да, это известное деление и я считаю очень правильное. Что касается асинхронного варианта (в данной терминологии), то на мой взгляд самым лучшим решением для него является модель акторов.
WH>Асинхронное программирование в мидори сделано хорошо. WH>Параллельное тоже есть, но по сравнению с halide детский сад.
В целом правильная платформа/язык из идеального мира конечно же должна обеспечивать распараллеливание на всех 3-ёх уровня сразу, а не как мы сейчас стыкуем разные технологии. Но то идеальный мир... )))
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>М-да... В общем, без проверок в рантайме ничего не выходит ни у тебя, ни у AlexRK. Если ОС или верификатор не может верифицировать, надо вставлять проверку в рантайме, PD>Кстати, не совсем понял, как ОС верифицировать-то будет ? Вроде в дискуссии с AlexRK мы исходили из того, что проверяет статический анализатор на этапе компиляции. PD>Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
На машине пользователя должно оставаться исходное IL-представление. Скомпилированный код будет лежать рядом и проверяться при старте, так же как сейчас Python ищет и проверяет pyc-файлы.
WH>>Либо в клиническом случае пользователи качают патч на эту программу и всё. PD>Фирма, выпустившая программу, давно не существует, программисты разбрелись. Ты в курсе, что программы иногда живут очень долго ?
Если IL не менялся, проблем нет — всё пересобирается не имея исходников.
Разумеется, для этого IL должен быть уже адекватного дизайна (например, пусть переход с 64 на 128 бит адреса — код, который впихивает указатели в int64, не должен пройти верификацию; а в языке должна быть явная пометка о конверсии указателя).
WH>>Ты кстати в курсе что винда молча при запуске исправляет некоторые популярные программы чтобы они работали.
WH>>Ну и не забывай о том, что мы говорим о крайне гипотетической ситуации. WH>>Ибо верификатор на несколько порядков проще чем процессор.
PD>Вот только бы знать, насколько менее надежен. PD>По большому счету, за 35 лет существования защищенного режима (считая с 80286, 1982 год) критических (неисправляемых) ошибок в нем не оказалось. Вынесли эти процессоры все версии Windows, Unix-Linux, а потом и MacOS — ничего, все нормально.
Агащазз. Тот же Spectre это как раз один из методов реализации одной из критических и неустранимых ошибок: возможности эксплуатации побочного канала за счёт кэширования. И в криптографии таких побочных каналов находили уже несколько штук, Spectre только самая шумная история из них.
PD>Ладно. Появится эта самая верфицируемая ОС в реальном мире (не экспериментальная Singularuty, приказавшая долго жить, а то, что продается сотнями миллионов копий), подождем 35 лет — посмотрим. PD>Вот только скорее всего ее появление и есть крайне гипотетическая ситуация.
Ну почему. Реализации с AOT уже существуют, тот же Android. Да, защита там "по старинке". Если будет следующий шаг в виде всовывания в него чего-то вроде WebAssembly для всего, что не совсем уж критично по скорости — то получим то, что будет удовлетворять в том числе и большинство быстрых графических приблуд. А там можно и к следующему этапу переходить...
Здравствуйте, scf, Вы писали:
scf>Чтобы после переезда в другую страну включаешь кофеварку, она лезет на сервер. И сервер знает, что а) это та же кофеварка б) она теперь в другой стране.
в) понаехало тут, кофе на себя не хватает, а тут ещё кто-то подключился, валил бы в свой шитстейт по-хорошему...
scf>Решает проблему аутентификации и локализации.
Здравствуйте, MTD, Вы писали:
MTD>3. С на помоечку, вместо него простой, непротиворечивый и логичный язык заточенный (как сделать правильно можно спросить меня)
Спрашиваю
MTD>4. POSIX на помоечку вслед за С, пусть интерфейсы напишут люди умеющие программировать
Здравствуйте, Sharov, Вы писали:
WH>>Зачем JIT? JIT не нужен. Кто мешает компилировать при установке приложения? S>В натив ? А почему сразу нельзя?
Если говорить про коробочные продукты, то при компиляции "сразу" оптимизация чаще всего идёт под некую "минимальную распространённую на рынке" архитектуру (ну например сейчас это может быть Core2Duo, для десктопов). Соответственно такое ПО не раскрывает всю мощь современных процессоров. Причём тут проигрывает как раз закрытое ПО (какая-нибудь там Gentoo благодаря распространению в исходниках может использовать полноценную оптимизацию), так что именно ему актуально введение распространения через промежуточное представление (типа LLVM IR).
Здравствуйте, Sinclair, Вы писали:
_>>Так ты хочешь верификатор, который работает не с исходным, а с исполняемым кодом? Хм хм хм... S>Именно такой верификатор встроен в Singularity. Не вижу никакого смысла цепляться за идею поставки сырого кода x86 на машину пользователя. S>Если нас не беспокоит время старта приложения — то тупо делаем верификацию непосредственно перед JIT. S>Если беспокоит — то выполняем верификацию перед ngen.
Так я как бы вполне одобряю идею распространения байткода (ну естественно не такого как в .net, а скорее такого как llvm, но это не суть). Только вот с фактом и возможностью верификации подобное распространение ПО никак не связано. И вот как раз на счёт возможности такой верификации у меня есть сомнения. Правда так сказать теоретические (сам я как-то ни одного подобного верификатора пока не писал).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
PD>P.P.S. У меня сложилось впечатление, что некоторые участники дискуссии не против бы и мир переделать (десятичную систему заменить, время по иному измерять, даже число pi ревизовать). Просьба все же оставаться в рамках темы. Ни железо, ни тем более внешний мир этому демиургу возможности изменять я не давал
Ничего не мешает этим всем заняться самостоятельно. Написать свою ОС, компилятор, редактор. Раньше люди этим чаще занимались.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>По сети не выскажешься ?
Давай я выскажусь.
1. Сеть должна быть децентрализована
2. Любое сетевое устройство должно быть готовым корректно и осмысленно работать в условиях временной недоступности сети. Поэтому основным примитивом должна быть синхронизация коллекции структурированных объектов, а не сливание струей чего-то монолитного к клиенту от сервера. Кстати, с учетом пункта 1 серверов, как таковых, быть не должно
3. Идея о том, что в сети может быть что-то постоянное (например, постоянный выделенный адрес) идет с тех времен, когда сети были проводными и прокладывались на века. В реальной сети все меняется и все может измениться в любой момент. Правильный низкоуровневый сетевой софтварий рассчитан на получение потока асинхронных событий, а не на установление долгосрочных соединений с фиксированными адресами
4. DNS не нужен, нужен поиск и возможность сослаться на контент по короткому идентификатору, типа UUID'а, если хочешь повторно найти уже известное
5. TCP не нужен и UDP не нужен. Нужен низкоуровневый протокол, в котором можно регулировать гарантии доставки.
6. Вопросы о взаимной авторизации сторон и защиты трафика от подделки и подслушивания должны стоять с самого начала. Сеть без криптографии не нужна
7. Certification Authorities не нужны, нужны механизмы для построения сети доверия
8. Пароли не нужны, они ненадежны и их невозможно запомнить
9. Firewall не нужен. Но право пользоваться сетью должно быть привязано к каждой программе, которой это нужно, и выдаваться ей путем явного запроса разрешения у человека
10. IP-адреса нужны в такой же мере, в какой нужны MAC-адреса. Т.е., они относятся к богатой внутренней жизни сетевого стека. Поэтому нет разницы, IPv4 или IPv6, лишь бы адресов хватало. Если они сольются в MAC-адресами, станет совсем хорошо. Статические сетевые адреса не нужны, и NAT тоже не нужен.
11. Адресоваться должен конкретный контент, конкретный сервис (не обязательно локализованный на одном устройстве), конкретный терминал с конкретным человеком перед ним, конкретное физическое устройство (принтер или стиральная машина, а не ихний внутренний контроллер, до которого никому нет дела) и т.п. И эта адресация должна сохраняться постоянной, даже если человек переехал, принтер переставили а файл переложили в другое хранилище.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Просто предлагаю обсудить только софт, чтобы не уходить в сторону. PD>От железа не так уж сильно софт в наше время зависит. Появись сейчас для десктопов новый процессор, принятый миром — и очень скоро Linux вместе с Windows для компьютеров на этом процессоре будут готовы. Практически с тем же API и теми же средствами.
Сейчас разработчики процессоров отдают себе отчет, что большая часть программ будет написана на Си и работать будет под управлением ОС с монолитным ядром. А разработчики софтвария ориентируются на соответствующие процессора.
К примеру, микроядерные архитектуры ОС не слишком популярны, в том числе, и потому, что переключения контекста на современных процессорах — дорогое удовольствие.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во-первых, архитектуру x86/x64 предложили бы переделать все, тут сомнения нет, нечего обсуждать.А какую именно нужно — на эту тему и без того обсуждений немало
Ты под архитекторуй имеешь ввиду ее, так сказать, фасад с определенным набором регистров, способов адресации и уродских команд. А есть еще и более глубокие архитектурные решения. Например, как ведет себе кэш и TLB при переключении между процессами — на таком уровне разница между x86 и ARM гораздо менее заметна. А вот влияние на архитектуру софта такие решения оказывают гораздо более существенное.
PD>А все, что выше ОС — так это совсем слабо от процессора зависит
Очень сильно зависит. Например, такие решения, как выбор способа управления памятью, или выбор между однопоточной архитектурой, архитектурой с миллионом потоков и архитектурой с небольшим количеством потоков — это все довольно высокоуровневые решения, операционной системе-то все равно. Но какое из них лучше, сильно зависит от организации кешей и памяти процессора, т.е. от очень низкоуровневых вещей.
Здравствуйте, CoderMonkey, Вы писали:
CM>Этого было недостаточно. Сейчас уже вполне очевидно, что росту частоты пришел конец и нужно намного больше ядер. Проблема в том, что для когерентного кэша накладные расходы растут полиномиально с ростом числа ядер. Значит — нужен некогерентный. А это значит — заодно переписывать все компиляторы
У ARM'а всю жизнь был некогерентный кеш, что не мешало gcc на нем прекрасно работать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не забудь, ты демиург. Существующие, пусть и полезные, механизмы тебя не ограничивают. Если можно сделать по-другому при том, что, конечно, эти механизмы можно будет иплементировать — имеешь право.
Ну я же не такой демиург, чтобы отменить ошибки при доставке и ограничения на латентность и ширину полосы.
А для того, чтобы эти ограничения обходить, нам нужны механизмы репликации распределённого состояния. HTTP — как раз такой механизм.
PD>Хм. Почему при передаче параметров через URL можно, а через body — нельзя ? В любом случае это R/O информация для запроса. В ответе ее нет.
Ну вот давайте придумаем такой прокси, который может ответить клиенту вместо сервера. Для того, чтобы понять, можно ли отдавать закэшированную реплику, ему нужно как-то проанализировать пришедший запрос.
Сейчас он хранит только URL, для которого чётко определены правила сравнения на эквивалентность.
Плюс те хидеры, которые влияют на содержимое ответа.
Если мы разрешим передавать какое-то тело в GET, то прокси придётся учить сравнивать эти body.
С учётом content-encoding, content-transfer-encoding, и ещё кучи всего. В итоге у нас шансы отдать ответ из кэша становятся близки к нулю, а шансы отдать его быстро — вообще нулевыми.
Зачем мы будем портить хорошую вещь?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexRK, Вы писали:
ARK>Так что сама идея довольно простая. Там, где верификатор не знает, корректная операция или нет — он заставляет программиста вставить рантайм-проверку.
А чё б ему самому не вставить проверку там, где он не уверен?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, извини, давай уточним. Если бы речь шла о том, что при существующей архитектуре процессора и ОС предлагается добавить эту статическую верификацию — это одно. Ты же предлагаешь существующую архитектуру заменить такой, в которой не будет аппаратной защиты вообще. А значит, все приложения смогут делать что им вздумается, если только не помешает статическая верификация.
И непонятно, ради чего так трахадзе.
Ошибки типе Spectre в софтварии известны уже давно — все эти подборы паролей/криптоключей, основанные на том, что верификация правильного и частично неправильного ключа может различаться по времени, это как раз оно. Статический верификатор, который заставляет программиста вставлять проверки, и считает на этом свою работу завершенной, от таких ошибок не спасает.
При всем при том, аппаратная проверка работает эффективнее и логически качественно проще. В ней не хватает лишь одного: она работает большими кусками, страницами и сегментами, а было бы клево, если бы ее можно было на пользовательский массив или строку натравить.
Просто нышешние процессора рассчитаны на то, что их аппаратные способы защиты будут использовать, как это делалось еще во времена VAX и System/370. Ну а системный софтварий пишется в рассчете на то, что процессора со времен VAX принципиально не изменились. Но это все меняется постепенно, по мере увеличения интереса к managed средам.
Здравствуйте, Pzz, Вы писали:
ARK>>Так что сама идея довольно простая. Там, где верификатор не знает, корректная операция или нет — он заставляет программиста вставить рантайм-проверку.
Pzz>А чё б ему самому не вставить проверку там, где он не уверен?
Да ради бога, пусть вставляет. Просто если он сам не вставит, а проверка в этом месте необходима, то программа не скомпилируется.
Пардон, неправильно понял. В смысле, почему бы самому компилятору не вставить?
Да, можно, почему нет. Если мы допускаем рантайм-ошибки и исключения, это самый простой выход — если проверка провалилась, генерим ошибку.
Там, где рантайм-ошибки и исключения не допускаются — например, в ядре ОС — там придется программисту самому вставлять проверки и реагировать на ошибки.
Здравствуйте, AlexRK, Вы писали:
ARK>Вы забываете про переключения контекста, которые очень сильно снижают производительность и выполняются в стстемах с аппаратной защитой _постоянно_. Статическая верификация позволяет выполнять весь код в одном «кольце» (да, собственно, кольца вообще не нужны).
Они снижают производительность лишь потому, что никто не заморачивался заоптимизировать их в процессоре так, чтобы они не снижали производительность. Но это постепенно меняется. В более-менее свежих интеловских процессорах кэш (и TLB?) стал привязан к "процессу", и при переключении процессов нет уже нужды инвалидировать весь кэш. Достаточно сказать процессору, что PID поменялся, а дальше оно само.
Здравствуйте, netch80, Вы писали:
T>>Ну как минимум одно достоинство у них всё-таки есть. В utf-8 cимвол по номеру в строке ищется за константное время,только если он английский. C utf-16 это распространяется на большинство языков, а с utf-32 — вообще на всё.
N>Стандартная и грубая ошибка. Символ ты так не найдёшь. Ты найдёшь кодовый пункт. Символ может иметь модификаторы. Чтобы их достоверно подключить, всё равно надо вызывать умную читалку, которая по таблице свойств будет проверять, что идёт за первым пунктом. Если ты этого не делаешь, твой код тупо некорректен.
Для utf-16 есть вроде набор языков символы которых ложатся в 2 байта, как latin1 в utf-8. То есть если знаешь точно, что у тебя в строке символы одного из этих языков — можно за константу выбирать. И я думал, что в utf-32 всё лезет в 4 байта, кроме всякой нечисти типа эмодзи, но похоже это неправда.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и еще один момент. Переключение процессов в настольной системе — это (не всегда, конечно) следствие того, что пользователь выбрал иное окно. По той причине, что потоки оконных приложений, пока пользователь с их окнами не работает, в Windows обычно спят и процессор не загружают. А активация окна спящего GUI — потока — это такое количество всяких действий, на фоне которого переключение контекста есть всего лишь мелочь. Одна отрисовка окна чего стоит.
Ну нет, конечно. Там же еще куча всякой фоновой активности. Часто вообще не связанной с отрисовкой чего бы то ни было.
Здравствуйте, netch80, Вы писали:
N>Не из-за этого, а из-за своей изначальной инвалидности.
А инвалидность заключалась в том, что он исполнял х86ой код в 10 раз медленнее конкурентов.
Все остальные проблемы интел бы решил в течении пары лет.
N>Но остаётся вопрос принципиально разных архитектур (CPU vs. GPU) и оптимизаций под конкретное железо. А вот тут большая загвоздка — те, кто для конкуренции вылизывает даже 1%, не пойдут на тотальный AOT, потому что в нём всегда будет меньше гибкости. А таких достаточно много.
1)И все они сливают вот этой штуке http://halide-lang.org/
Программист из adobe убил 3 месяца на оптимизацию фильтра. Авторы halide за один день написали реализацию, которая работает в 2 раза быстрее. Изменив несколько строк сделали реализацию, для ГПУ которая работает в 7 раз быстрее.
2)Если очень хочется, то код можно заточить под конкретный процессор.
Создаём библиотеку примитивов процессора. И учим ВМ для этого процессора транслировать эти примитивы в соответствующие машинные коды.
Можно даже научить ВМ прозрачно подменять референсную реализацию на реализацию для конкретного процессора.
Можно даже сделать так чтобы было доказательство эквивалентности референсной реализации и реализации под конкретный процессор.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>А что ты называешь скриптами? Факт наличия интерпретатора на мой взгляд вообще ни о чём не говорит (он даже у C++ есть, а у Питона наоборот есть свой JIT вариант), да и выполнял я вышеописанные команды не в REPL, а набросав скрипт в Notepad++ и запустив в командной строке. Чаще всего скриптами называют как раз короткие фрагменты на языках с динамической типизацией. Ну и помимо этого весьма актуально отсутствие в языке всяческих обязательных каркасов приложения (типа main в C++ или вообще никчемного класса в Java/C#).
Ну вот собственно таким микропрограммам никто не мешает быть статически типизированными.
Более того писать их можно не в блокноте, а в полноценной ИДЕ которая если делать правильно будет запускаться за доли секунды.
Sublime запускается мгновенно. Когда нитра станет нативной она тоже будет стартовать доли секунды. Сейчас при старте .НЕТ тормозит.
WH>>2)Создание консольного приложения на C# занимает несколько секунд. _>Угу, в фантазиях. )
На практике.
_>Ну скажем тот же LLVM это вполне может. Правда там возникают вопросы с заменой стандартной библиотеки языка (под МК обычно используется специализированная версия)...
Там ещё много вопросов возникает.
_>Ну если проектировать с нуля (как хотел автор изначальной темки) непосредственно для этой задачи, то конечно можно сделать намного лучше существующих вариантов. Я имел в виду, что из всех уже готовых решений на данный момент, это выглядит наиболее подходящим вариантом. И кстати выбор команды WebAssembly это подтверждает.
Команду WebAssembly нужно разогнать за феерический идиотизм.
У них в низкоуровневом языке нет goto. Как они вообще до этого додумались?
И я знаю про релупер. Всё равно решение идиотское.
_>Проблема таких систем (кстати Midori/Singularity далеко не первые в этой области, намного раньше было например такое http://www4.cs.fau.de/Projects/JX/index.html решение), что они очень ультимативные: или всё прикладное ПО написано на соответствующем управляемом языке или система просто не работает (нельзя написать один критичный кусочек на голом ассемблере). Ну и соответственно пока я не увижу реализацию например кодека h.264 на управляемом языке, не уступающую по эффективности классическим нативным реализациям, то в нормальное будущее подобной ОС не поверю.
С этим проблем нет.
Дафна может доказывать любой императивный код включая ассемблер.
Ну и опять же halide полностью безопасный. И обгонять его озвереешь.
_>Хы, ну возможно. Я с самим языком подробно не возился, помню только что мы обсуждали нюансы с SIMD векторами... )
Я тоже. Просто внимательно документацию изучил.
_>Да, это известное деление и я считаю очень правильное. Что касается асинхронного варианта (в данной терминологии), то на мой взгляд самым лучшим решением для него является модель акторов.
1)Акторы и асинхронная модель в мидори друг другу не противоречат.
2)Акторы нужно делать правильно. Чтобы не получилось как в эрланге в котором получение сообщений из очереди О(размер очереди). И как следствие непредсказуемый уход в астрал если нагрузка кратковременно превысит некоторый порог.
3)В любом случае акторы отлаживать труднее чем то что есть в мидори. У них там есть отладчик, который прозрачно ходит между процессами.
_>В целом правильная платформа/язык из идеального мира конечно же должна обеспечивать распараллеливание на всех 3-ёх уровня сразу, а не как мы сейчас стыкуем разные технологии. Но то идеальный мир... )))
Так мы тут про идеальный мир и говорим.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>2. Либо запретить нативный язык как минимум для пользовательских программ. В ОС не запретишь — кто этим управляемым кодом управлять-то будет ?
Совершенно не обязательно. Представь себе конструкцию, в которой все нужные проверки вставляет компилятор, когда генерирует для твоей программы код на ассемблере, но если проверка сработает, то он (компилятор) вполне может сконструировать вызов библиотечной функции, которая написана на том же самом managed языке.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот что будут делать, если в алгоритме статической верификации обнаружилась ошибка, а программы уже прошли этап этой верификации, разошлись в миллионах копий и теперь рушат ОС или получают доступ к чужой памяти — объясни. Срочно патчить все выпущенные программы ? Как ? Фирма, выпустившая эту программу, давно закрылась, авторы разбрелись кто куда.
Ну в принципе, организационно это лечится. Например так:
1. Чтобы программа в принципе запускалась, необходимо получить сертификат соответствия — электрическую подпись, которую выдают после прохождения верификации
2. Одним из условий является предоставление исходников, которые на возмездной основе хранятся в доверенном центре
3. Если в верификаторе обнаружилась дыра, то все программы переверифицируются
4. Если исправленный верификатор обнаружил в существующей программе ошибку, ее сертификат отзывается, и программа перестает запускаться
Большой бизнес, поди, был бы рад такому способу жизни. Я — не очень
Здравствуйте, AlexRK, Вы писали:
ARK>Вы никак не поймете простую вещь. Верификатор работает на этапе компиляции (ну, еще на этапе инсталляции происходит верификация промежуточного кода, но речь не об этом). Компилятор заставляет вставить рантайм-проверки в тех местах, где они нужны. Но это совершенно не эквивалентно тому, что есть в C#/Java! В управляемых языках проверки вставляются во всех местах, а в статически верифицированном коде — только там, где надо. Таких мест может быть на порядок меньше.
И находиться они будут исключительно в местах ввода внешних данных.
А внешние данные нужно проверять всегда.
Но если подумать всё ещё интереснее. На практике проверок будет намного меньше чем в нативном коде. Просто по тому что в нативном коде народ ставит кучу проверок чтобы ничего не упало. А в верифицируемом коде все эти проверки делает компилятор на этапе компиляции.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Эээ, минуту. В чем нашли-то ? В доказательствах или в теоремах ? Если первое — это на сами теоремы вообще-то никак не влияет. Ну нашли ошибку в доказательстве, но теорема-то верна ? Надо ее по-иному доказать, вот и все. PD>А вот если нашли случай неверности теоремы — это совсем иное.
В доказательствах некоторые из которых считались верными столетиями.
Но если в доказательстве есть ошибка, то откуда мы знаем, что теорема верна?
Собственно, мы обсуждаем крайне маловероятную цепочку событий, когда все пропустили ошибку в теореме и в доказательстве.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexRK, Вы писали:
ARK>Вы никак не поймете простую вещь. Верификатор работает на этапе компиляции (ну, еще на этапе инсталляции происходит верификация промежуточного кода, но речь не об этом). Компилятор заставляет вставить рантайм-проверки в тех местах, где они нужны. Но это совершенно не эквивалентно тому, что есть в C#/Java! В управляемых языках проверки вставляются во всех местах, а в статически верифицированном коде — только там, где надо. Таких мест может быть на порядок меньше.
Если существует алгоритм, позволяющий более-менее правдоподобно сказать, где надо вставлять проверки, а где не надо, то никто не мешает применить этот алгоритм в компиляторе C#. Логически получившийся код будет работать так, словно проверки есть везде, но физически они будут присутствовать только в ключевых местах. Это называется оптимизация.
Здравствуйте, neFormal, Вы писали:
WH>>1)Запретить языки с динамической типизацией. WH>>в)Не ловят ошибки программистов. F>так никто не ловит
Это не правда. Даже C# очень много что ловит. А дафна ловит почти всё.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Вывести новую архитектуру на рынок — это титанические инвестиции. А вот если бы основные современные платформы были бы построены на промежуточном коде, то новые процессоры бы выходили ежеквартально.
Оне и так регулярно выходят, у интела например. Со всяческими расширениями типа векторных операций и проч. CISC процессоры можно оптимизировать прозрачно для пользователя.
Здравствуйте, Pzz, Вы писали:
Pzz>Если существует алгоритм, позволяющий более-менее правдоподобно сказать, где надо вставлять проверки, а где не надо, то никто не мешает применить этот алгоритм в компиляторе C#.
Существует. Но без аннотаций в стиле дафны он ужасающи медленный.
Хуже того он тупо вставит проверки, но не исправит ошибки, которые найдёт и заставит исправить дафна.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
Pzz>Если существует алгоритм, позволяющий более-менее правдоподобно сказать, где надо вставлять проверки, а где не надо, то никто не мешает применить этот алгоритм в компиляторе C#. Логически получившийся код будет работать так, словно проверки есть везде, но физически они будут присутствовать только в ключевых местах.
В теории да. На практике написать статический анализатор для языка, специально не заточенного под это, весьма сложно. Все известные мне статические анализаторы написаны для очень простых языков.
Pzz>Это называется оптимизация.
Призывы к использованию других ОС приравнять к оправданию терроризма. Оправдывающих терроризм — расстрелять.
WH>Учим компилятор вставлять рантайм проверки в тех местах где он не смог статически доказать корректность. WH>Если проверка провалилась, то молча прибиваем процесс.
И молча же выписываем постановление автора программы — расстрелять.
Здравствуйте, Pzz, Вы писали:
Pzz>9. Firewall не нужен. Но право пользоваться сетью должно быть привязано к каждой программе, которой это нужно, и выдаваться ей путем явного запроса разрешения у человека
Здравствуйте, WolfHound, Вы писали:
WH>Ты знаешь, что внутри всех х86 процессоров живёт процессор с совершенно иной системой команд. Если выкинуть прослойку, которая конвертирует х86тые команды во внутренние команды то можно разогнать процессоры на десяток другой процентов. WH>10% производительности на ровном месте тебе мало?
Я слышал в пересказе через общего знакомого мнение мужика, работающего в Интеле, что frontend, который переваривает внешне видимую систему команд в реальную внутреннюю, штука довольно простая, кто угодно ее может сделать, и вообще, на результат она особо не влияет. Реальная разница как раз в исполнителе этих внутренних "настоящих" команд, и там искусство заключается в том, чтобы изучить, как реальный софтварий процессором пользуется, и сделать именно те оптимизации, которые требуются. И это очень трудоемко и денежно именно потому, что софтвария изучать приходится много. И именно поэтому разработка настоящих процессоров — это игра большого бизнеса, а изобретение очередной гениальной системы команд к победе в этой игре вообще не имеет отношения.
Здравствуйте, Sharov, Вы писали:
Pzz>>9. Firewall не нужен. Но право пользоваться сетью должно быть привязано к каждой программе, которой это нужно, и выдаваться ей путем явного запроса разрешения у человека
S>От эксплойтов как будете защищаться?
Firewall не пропускает пришедшие пакеты на какой-то порт, или не выпускает их наружу. Однако если нет никакой программы, которая слушала бы на этом порту, firewall не делает ничего.
Поэтому просто не надо выпускать в сеть программы, для этого не предназначенные. А предназначенные все равно должны внутренне защищаться, firewall им ничем не помогает.
Здравствуйте, Sinclair, Вы писали:
S>>Если не правильно составил запрос -- логическая ошибка, как типизация поможет? S>Точно так же, как она помогает в обычных языках. Это в K&R С можно было перепутать местами адрес строки и номер позиции в ней, и компилятор бы и бровью не повёл. S>Современный C зачем-то отличает char* от int.
Как это поможет в случае когда я умножил на 2, а надо было на 5? Если ошибся с условием запроса и выбрал не то? А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится.
Здравствуйте, lpd, Вы писали:
WH>>Я её своими глазами видел. Итаниум вообще сдох из-за этого. lpd>Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.
Линух для итаниума, насколько я помню, был. Потом поддержку викинули за ненадобностью.
Здравствуйте, lpd, Вы писали:
lpd>У ARM есть как значительные плюсы, так и некоторые минусы на мой взгляд неспециалиста(сложности с инициализацией констант и длиной branch). Не думаю, что популярности ARM на серверах мешает отсутствие софта.
У ARM'а основной рынок — смартфоны и т.п., и соответствующие решения при проектировании: экономить электричество, теряя в производительности. В частности, у ARM'а довольно маленькие кэши, на что в телефоне начхать, а на сервере может быть и не начпать, в зависимости от того, что делает этот сервер.
Именно это мешает популярности ARM на серверах: то, что он не под них разрабатывался.
Здравствуйте, Terix, Вы писали:
T>>>Ну как минимум одно достоинство у них всё-таки есть. В utf-8 cимвол по номеру в строке ищется за константное время,только если он английский. C utf-16 это распространяется на большинство языков, а с utf-32 — вообще на всё.
N>>Стандартная и грубая ошибка. Символ ты так не найдёшь. Ты найдёшь кодовый пункт. Символ может иметь модификаторы. Чтобы их достоверно подключить, всё равно надо вызывать умную читалку, которая по таблице свойств будет проверять, что идёт за первым пунктом. Если ты этого не делаешь, твой код тупо некорректен.
T>Для utf-16 есть вроде набор языков символы которых ложатся в 2 байта, как latin1 в utf-8. То есть если знаешь точно, что у тебя в строке символы одного из этих языков — можно за константу выбирать.
Увы, нет. Например, É (U+00C9) vs. É (U+0045 U+0301). Это таки злобный привнос Unicode по сравнению с 8-битками. Даже в английском есть слова, которые принято писать с такими символами (типа, fiancé).
Ты можешь попытаться нормализовать это, но нормализация полезна только для сравнения (она убивает многие характеристики символов), но не для неразрушающего анализа.
T> И я думал, что в utf-32 всё лезет в 4 байта, кроме всякой нечисти типа эмодзи, но похоже это неправда.
Эмодзи как раз большинство лезет (хотя к ним есть модификаторы для смены фона... )
Здравствуйте, WolfHound, Вы писали:
WH>Это не правда. Даже C# очень много что ловит. А дафна ловит почти всё.
А я слышал, что хаскель ловит вообще все, и проще уговорить жену соседа сделать минет, чем уговорить хаскельный компилятор скомпилировать программу с ошибками.
Здравствуйте, Pzz, Вы писали:
Pzz>У ARM'а основной рынок — смартфоны и т.п., и соответствующие решения при проектировании: экономить электричество, теряя в производительности. В частности, у ARM'а довольно маленькие кэши, на что в телефоне начхать, а на сервере может быть и не начпать, в зависимости от того, что делает этот сервер. Pzz>Именно это мешает популярности ARM на серверах: то, что он не под них разрабатывался.
Это постепенно меняется, ещё пару лет и перестанет быть критичным.
Здравствуйте, Pzz, Вы писали:
WH>>>Я её своими глазами видел. Итаниум вообще сдох из-за этого. lpd>>Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.
Pzz>Линух для итаниума, насколько я помню, был. Потом поддержку викинули за ненадобностью.
Не выкинули.
[code]
$ du -sk arch/ia64/
3912 arch/ia64/
$ grep -A2 ^VERSION Makefile
VERSION = 4
PATCHLEVEL = 15
SUBLEVEL = 0
[/url]
Здравствуйте, Pzz, Вы писали:
Pzz>Поэтому просто не надо выпускать в сеть программы, для этого не предназначенные. А предназначенные все равно должны внутренне защищаться, firewall им ничем не помогает.
fw может же детектировать подозрительную активность и вроде даже немного траффик анализировать(сигнатуры эксплойта и проч.). Так вот, нашли уязвимость, патча нет. Не вырубать же бд для всех пользователей из-за потенциального взлома?
Здравствуйте, netch80, Вы писали:
N>Это постепенно меняется, ещё пару лет и перестанет быть критичным.
Какая красивая плиточка!
Я так понимаю, такой камень интересно ставить туда, где сверхвысокая вычислительная производительность не столь уж и нужна, а вот вопросы охлаждения/энергопотребления и общей цены изделия играют роль. Не зря в статье говорится про облака — как известно, облака нынче живут не в небе, а в плотно набитых дата центрах.
Здравствуйте, Pzz, Вы писали:
Pzz>А я слышал, что хаскель ловит вообще все, и проще уговорить жену соседа сделать минет, чем уговорить хаскельный компилятор скомпилировать программу с ошибками. Pzz>Что, врут?
Врут. Совсем всё не ловит никто.
Дафна ловит намного больше чем хаскель.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
S>fw может же детектировать подозрительную активность и вроде даже немного траффик анализировать(сигнатуры эксплойта и проч.). Так вот, нашли уязвимость, патча нет. Не вырубать же бд для всех пользователей из-за потенциального взлома?
OK, убедил. Давай введем понятие домена, логически напоминающее понятие локальной сети, но с той разницей, что членство в домене зависит не от случайного соседства по сетевому проводу, а от того, приняли ли люди данное устройство в домен, или не приняли.
Так вот, я не понимаю, зачем бд вообще иметь доступ к сети за пределами своего более-менее локального домена. В котором врагов нет.
Здравствуйте, Pzz, Вы писали:
S>>fw может же детектировать подозрительную активность и вроде даже немного траффик анализировать(сигнатуры эксплойта и проч.). Так вот, нашли уязвимость, патча нет. Не вырубать же бд для всех пользователей из-за потенциального взлома?
Pzz>Так вот, я не понимаю, зачем бд вообще иметь доступ к сети за пределами своего более-менее локального домена. В котором врагов нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Купил я кофеварку, а к ней прибит адрес этот. И переехал в другую страну. И оказался я в ней со своим адресом, видным всей сети, как белая ворона. Никакой структуры у сети больше нет. Ни тебе маски подсети, ни нормальной маршрутизации. Ищи эту кофеварку где хочешь. Адрес прибит, а вот кофеварка уехала вместе с адресом.
У твоей кофеварки должен быть логический адрес. не 05:ff:45:88:9a:e7, а "моя белая кофеварка".
Каким образом твоя стиральная машина познакомится с твоей кофеваркой (а кому еще с ней общаться по сети, как не стиральной машине?), это отдельный вопрос. Ну, например, ты поставишь один раз свою кофеварку на стиральную машину, и скажешь, "ребята, надо познакомиться", и они там между собой через какой-то условный NFC обменяются своими криптографическими идентификаторами — как эти идентификаторы выглядят, вообще не твое дело, они не для тебя предназначены. Ну или может кофеварку надо будет даже один раз постирать в стиральной машине, не суть. Но очевидно, что приемлимый способ знакомства зависит от физической природы вещей, которые надо познакомить между собой.
Когда ты подключаешь кофеварку и стиральную машину в сети, вероятно, они получат какой-то временный транспортный адрес, до которого тебе нет дела. И кроме того, они должны уметь находить друг друга в сети, причем независимо от того, кто из них каким образом включен в интернет в данный момент.
Вот этот вот временный транспортный адрес, наверное, должен выдаваться с учетом удобства иерархического роутинга. Только это все — богатая внутренняя жизнь сетевого стека, до которой тебе нет дела, если ты, конечно, не разработчик этого самого сетевого стека. А тебя интересует лишь, как одному физическому устройству показать пальцем на другое физическое устройство, чтобы они могли начать между собой коммуницировать.
Здравствуйте, Sharov, Вы писали:
Pzz>>Так вот, я не понимаю, зачем бд вообще иметь доступ к сети за пределами своего более-менее локального домена. В котором врагов нет.
S>Это просто пример сервиса, выведенного наружу.
И чем тебе фаирвол-то поможет, если ты выводишь сервис наружу?
Либо сервис умеет жить в условиях страшного дикого мира, либо его держат в песочнице.
Здравствуйте, lpd, Вы писали:
N>>Если бы переход на стиль ARM был прозрачен, Intel не цеплялась бы за совместимость с тараканами 8080. И даже если бы они сохранили свой CISC, им было бы значительно проще выкинуть кучу неактуального. lpd>Не факт, что это legacy в Intel значительно замедляет процессор. Да, процессоростроители прилагают дополнительные усилия для поддержки 32-бит, потому что хотят иметь это конкурентное преимущество.
А 32 бита тут при чём? Как раз 32 бита в 64 не мешает. Мешают 16- и 8-битные команды, тем, что создают зависимости по регистрам. Мешают команды, которые требуют генерации длинных цепочек RISC-команд (как модификация аргумента в памяти). Мешают команды, которые не генерируются компиляторами (вроде rcl и xchg), но которые надо поддерживать ради чёртовой совместимости. Мешают целые устаревающие на глазах блоки вроде FPU.
lpd> Не считаю, что программисты и пользователи должны возиться с VM ради облегчения жизни Intel. lpd>При большем числе конкурентов Intel процессоры могли бы подешеветь. Но вряд ли появились бы процессоры в разы быстрее.
Так и я не про скорость. Скорость сильно не разгонится. А вот цена операции в ваттах могла бы заметно сократиться.
lpd>У ARM есть как значительные плюсы, так и некоторые минусы на мой взгляд неспециалиста(сложности с инициализацией констант и длиной branch).
Длина условных переходов? Пары мегабайт недостаточно?
И что там такого особенного с константой, если это вполне удобно решалось даже на arm32 хранением константы рядом с функцией, а для arm64 ещё и альтернативно есть movk?
Эти две причины никак не противодействуют применению на серверах.
lpd> Не думаю, что популярности ARM на серверах мешает отсутствие софта.
N>>Софт именно что выглядит проблемой. В Debian фактически живёт только то, что поставляется в исходниках. Исключений мало и они, даже если принципиальны в своих узких областях, не делают общей погоды. lpd>Еще раз: для Itanium 9 DVD Debian-пакетов. Для Linux все поставляется в исходниках, кроме отдельных исключений, не являющихся уникальными.
Какой смысл говорить "ещё раз...", если это то же самое, что я сказал? Вы вообще читаете, на что возражаете?
И что это меняет, если доля заранее скомпилированного минимальна?
Здравствуйте, Pzz, Вы писали:
N>>Это постепенно меняется, ещё пару лет и перестанет быть критичным.
Pzz>Какая красивая плиточка!
Pzz>Я так понимаю, такой камень интересно ставить туда, где сверхвысокая вычислительная производительность не столь уж и нужна, а вот вопросы охлаждения/энергопотребления и общей цены изделия играют роль. Не зря в статье говорится про облака — как известно, облака нынче живут не в небе, а в плотно набитых дата центрах.
Так это типа первая долетевшая ласточка. Получат денег, ещё оптимизируют и уже сравняются с x86.
Здравствуйте, netch80, Вы писали:
N>Так это типа первая долетевшая ласточка. Получат денег, ещё оптимизируют и уже сравняются с x86.
Да это, заметь, не факт, что им надо. У них с интелом разные ниши. Причем заметь, что интелу в евонной нише "молотилки чисел" существенно угрожают всякие там программируемые логические матрицы и прочие видеокарты, а вот арму в его нише "дешево, сердито и липестричества много не жрет" никто особо не угрожает.
Здравствуйте, WolfHound, Вы писали:
N>>Не из-за этого, а из-за своей изначальной инвалидности. WH>А инвалидность заключалась в том, что он исполнял х86ой код в 10 раз медленнее конкурентов. WH>Все остальные проблемы интел бы решил в течении пары лет.
Не-а. Он и за прошедшие 20 лет не решил эти проблемы, и не решил бы их и тогда.
Проблемы Itanium в том, что EPIC не работает с современной памятью и кэшами в мультипроцессорной системе.
То, что при этом Intel ещё и был настолько самонадеян, что вместо нормального x86 засунул туда слабый эмулятор — заслуга облаковитателей, поддержанная маркетолухами. Сколько их тогда было — видно по историям с Rambus и NetBurst. Ну да, время такое — если бы пузырь доткомов не схлопнулся, они могли бы и проскочить ещё лет пять. Но не больше.
Фактически, они нащупали работающий подход к этим вопросам только в SandyBridge.
N>>Но остаётся вопрос принципиально разных архитектур (CPU vs. GPU) и оптимизаций под конкретное железо. А вот тут большая загвоздка — те, кто для конкуренции вылизывает даже 1%, не пойдут на тотальный AOT, потому что в нём всегда будет меньше гибкости. А таких достаточно много. WH>1)И все они сливают вот этой штуке http://halide-lang.org/
Посмотрю, но не сегодня.
WH>2)Если очень хочется, то код можно заточить под конкретный процессор.
Можно.
WH>Создаём библиотеку примитивов процессора. И учим ВМ для этого процессора транслировать эти примитивы в соответствующие машинные коды.
А вот именно примитивы процессора могут быть перебором. Скорее тут надо точить под общий подход и конкретные количественные особенности, типа "любой векторный кратный 128 битам".
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, lpd, Вы писали:
N>Длина условных переходов? Пары мегабайт недостаточно? N>И что там такого особенного с константой, если это вполне удобно решалось даже на arm32 хранением константы рядом с функцией, а для arm64 ещё и альтернативно есть movk? N>Эти две причины никак не противодействуют применению на серверах.
Решения, конечно, есть: также можно загружать константы результатом вычисления нескольких инструкций, а для переходов делают несколько branch один на другой. Я не говорю, что это значительные недостатки — для программиста плюсы ARM перевешивают минусы, на мой взгляд.
Однако для повсевместного использования вместо Intel я не могу назвать у системы построенной на ARM больших преимуществ, кроме меньшего энергопотребления. Это не оказалось достаточным для перехода на ARM на серверах, и дело не в отсутствии софта(его достаточно). Видимо, дело в инертности нежелании менять то, что нормально работает и всем знакомо. Кроме того, в ARM шина AMBA больше подходит для embedded, чем для PC, насколько я понимаю.
N>Какой смысл говорить "ещё раз...", если это то же самое, что я сказал? Вы вообще читаете, на что возражаете? N>И что это меняет, если доля заранее скомпилированного минимальна?
Я не понимаю, что ты имеешь ввиду: почему доля заранее скомпилированного минимальна?
Если ты имеешь ввиду бинарные пакеты, то в Debian мы видим 9+ DVD уже скомпилированого софта под каждую процессорную архитектуру.
Если ты подразумеваешь closed-source софт, то его вообще для Linux мало и он не уникален — есть open-source аналоги.
Это подтверждает, что софт в данном вопросе не является большим ограничением.
Вот если бы сделали процессор, который не просто архитектурно содержит меньше legacy, а еще и быстрее хотя бы на 50% и значительно дешевле, то под него вскоре появился бы софт — open source точно.
Думаю, VM vs native — скорее вопрос предпочтений. Кому-то идея VM нравится, кому-то нет. Лично я привык к ассемблеру x86/arm, и скорее предпочту переучиться на программирование под новую архитектуру процессоров, чем возиться с VM, даже если бы последнее помогло процессоростроителям создать немного лучший процессор.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Решения, конечно, есть: также можно загружать константы результатом вычисления нескольких инструкций, а для переходов делают несколько branch один на другой. Я не говорю, что это значительные недостатки — для программиста плюсы ARM перевешивают минусы, на мой взгляд. lpd>Однако для повсевместного использования вместо Intel я не могу назвать у системы построенной на ARM больших преимуществ, кроме меньшего энергопотребления. Это не оказалось достаточным для перехода на ARM на серверах, и дело не в отсутствии софта(его достаточно). Видимо, дело в инертности нежелании менять то, что нормально работает и всем знакомо. Кроме того, в ARM шина AMBA больше подходит для embedded, чем для PC, насколько я понимаю.
Я рядом уже кидал ссылку о том, что ARM активно выходит на серверный рынок. Шина с системой команд никак не связана. Ориентация на embedded привела к соответствующим оптимизациям, но если есть нужда, то идёт работа в сторону проработки серверного построения — и мы видим уже реальные результаты в эту сторону. Дальше будет больше — не думаю, что ARM захочет потерять лакомый кусочек.
lpd>Я не понимаю, что ты имеешь ввиду: почему доля заранее скомпилированного минимальна? lpd>Если ты имеешь ввиду бинарные пакеты, то в Debian мы видим 9+ DVD уже скомпилированого софта под каждую процессорную архитектуру. lpd>Если ты подразумеваешь closed-source софт, то его вообще для Linux мало и он не уникален — есть open-source аналоги. lpd>Это подтверждает, что софт в данном вопросе не является большим ограничением.
Это говорит, что доля софта под Linux ничего не подтверждает именно из-за наличия исходников. Ты не перенесёшь так просто софт для Windows из-за того, что он уже скомпилирован под x86, ни под IA-64 (его внутренний эмулятор не в счёт), ни под ARM. То есть аргумент о количестве софта тут просто ни о чём.
А вот действительно промежуточный ассемблероподобный язык привёл бы к тому, что закрытый софт вообще перенёсся бы без рассмотрения, какая целевая архитектура, пока она соответствует общим условиям (типа: двоичная, размеры — степени двойки, дополнительный код для целых и IEEE754 для плавающих). И мы бы уже видели какой-нибудь 1С, VisualStudio и тому подобные. (Хотя для последней надо вначале таки осилить 64-битный режим)
lpd>Вот если бы сделали процессор, который не просто архитектурно содержит меньше legacy, а еще и быстрее хотя бы на 50% и значительно дешевле, то под него вскоре появился бы софт — open source точно. lpd>Думаю, VM vs native — скорее вопрос предпочтений. Кому-то идея VM нравится, кому-то нет. Лично я привык к ассемблеру x86/arm, и скорее предпочту переучиться на программирование под новую архитектуру процессоров, чем возиться с VM, даже если бы последнее помогло процессоростроителям создать немного лучший процессор.
99% народа пишет на языках уровня выше ассемблера. Им всё это по барабану. Разве что отметят шатание в скорости.
Но я вот очень задумчиво себе представляю AOT компиляцию какой-нибудь новой мозиллы при её установке
Здравствуйте, WolfHound, Вы писали:
WH>>>1)Запретить языки с динамической типизацией. WH>>>в)Не ловят ошибки программистов. F>>так никто не ловит WH>Это не правда. Даже C# очень много что ловит. А дафна ловит почти всё.
где мне ошибку в логике поймают?
а сношаться с компилятором из-за того, что он не умеет int в long кастовать — это к извращенцам.
Здравствуйте, WolfHound, Вы писали:
PD>>Понимаешь, в чем дело ? Законы физики, тем более химии (говорю как химик по образованию) никогда не обязаны выполняться 100%. WH>Я понимаю, что ты путаешь математику и естественные науки. WH>В математике всё всегда определено на 100% WH>А тут у нас не физика и тем более не химия, а чистой воды математика.
Ну да, пока мы верим, что все уложенные в основание расчёта постулаты верны. Например, что если процессору сказали сложить 2 и 2, то он выдаст 4.
А когда это не сферический в вакууме компьютер, а реальное железо с реальными цифрами "наработки на отказ", то внезапно™ оказывается, что иногда оно таки 5, а иногда вообще -32764. И с этого момента математика вдруг превращается в химию.
Именно поэтому концепция плоского процессора и проверяемого кода не будет работать: если сейчас большинство подобных ошибок железа приводят максимум к гибели одного процесса, то в подобном плоском режиме деградация наступит во всей системе.
И даже без подобных ситуаций любую верификацию подкрепляют реальными тестами именно затем, чтобы проверить корректность постулатов о среде исполнения, заложенных в верификационную теорию. А то мало ли что вы там написали — может, у вас log(-1)==0...
Здравствуйте, Pzz, Вы писали:
Pzz>4. Если исправленный верификатор обнаружил в существующей программе ошибку, ее сертификат отзывается, и программа перестает запускаться
Pzz>Большой бизнес, поди, был бы рад такому способу жизни. Я — не очень
Так уже подошли к этому в плотную, на мобильниках и планшетах.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Жестко. Ты лишаешь в принципе возможности писать на нативе, за исключением чего-то, что пишут особо доверенные лица и компании. Я не уверен, что это будет принято.
Нет. На нативе запрещено писать вообще всем. В Singularity размер верификатора — 2кб. И он верифицируется "внешним верификатором", который проверяет не только безопасность, но и корректность.
Для остального кода нам доказывать корректность не надо. Достаточно более слабых гарантий — вроде отсутствия обращений к чужой памяти и реинтерпретации данных. PD>Я не думаю, что стоит еще раз начинать флейм на тему : можно ли на управляемом коде написать столь же эффективно, как на нативе. Мою позицию ты знаешь.
Тут есть ещё вопрос, что такое "управляемый код".
PD>Вот это поясни. Верификатор, что, в рантайме работает ? Тогда это уж никак не статический верификатор, а просто динамический контроль индексов в стиле Java/C#
Верификатор проверяет, что код не пытается обращаться за пределы массива. Это обеспечивается путём статического анализа кода. После верификации верификатор не нужен.
Можно заниматься оптимизацией — в частности, устранять излишние проверки или выполнять спекулятивную оптимизацию. В отличие от аппаратной защиты, meltdown в такой системе невозможен.
PD>Я хочу идти в правильном направлении, но я не уверен, что это направление правильное. Я считаю что да.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, lpd, Вы писали:
lpd>В таком случае были бы патенты на эти технологии. Я ничего не слышал. Можно одну ссылку на что-то действительно полезное, lpd>чего нет в популярных современных процессорах?
На какие технологии? Которые никто не разрабатывает, потому что их невозможно монетизировать? lpd>В Windows отсутствие софта действительно проблема. У Debian же есть порт и для Itanium. Пакетов поддерживается много — 9 dvd.
В винде проблема как раз наличие софта. Его много и его жалко — в том смысле, что никто не станет брать платформу, где не работает его XXXXX. lpd>Перевести пользователей на новую архитектуру, конечно, трудно. Однако, софт не выглядит основной причиной этого. Высокоуровневые языки программирования(С++) и без того достаточно портабельные.
Именно софт и именно выглядит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Так я как бы вполне одобряю идею распространения байткода (ну естественно не такого как в .net, а скорее такого как llvm, но это не суть). Только вот с фактом и возможностью верификации подобное распространение ПО никак не связано. И вот как раз на счёт возможности такой верификации у меня есть сомнения. Правда так сказать теоретические (сам я как-то ни одного подобного верификатора пока не писал).
Не очень понял, в чём именно сомнения. "Такая верификация" вполне себе встроена во вполне себе реально существующие системы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали: S>Как это поможет в случае когда я умножил на 2, а надо было на 5?Если ошибся с условием запроса и выбрал не то?
Никак. И программу за вас он не напишет.
А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится.
Да как нефиг делать. Вы посмотрите на таблицу implicit преобразований в T-SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>Как это поможет в случае когда я умножил на 2, а надо было на 5?Если ошибся с условием запроса и выбрал не то? S>Никак. И программу за вас он не напишет.
А кастыдей из-за типизации там где не надо понаставит.
S>>А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится. S>Да как нефиг делать. Вы посмотрите на таблицу implicit преобразований в T-SQL.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>В таком случае были бы патенты на эти технологии. Я ничего не слышал. Можно одну ссылку на что-то действительно полезное, lpd>>чего нет в популярных современных процессорах? S>На какие технологии? Которые никто не разрабатывает, потому что их невозможно монетизировать?
Фирм, разрабатывающих процессоры немало.
lpd>>В Windows отсутствие софта действительно проблема. У Debian же есть порт и для Itanium. Пакетов поддерживается много — 9 dvd. S>В винде проблема как раз наличие софта. Его много и его жалко — в том смысле, что никто не станет брать платформу, где не работает его XXXXX.
Из-за проблем авторов софта под винду я страдаю еще меньше, чем из-за проблем процессоростроителей. Я не против платного closed-source, однако по факту он оказывается ненужным из-за большого количества open-source софта. Поэтому на эту тему мне сказать нечего, кроме того, что нужна новая ОС с кастомизабельностью Linux и удобством Windows. Ядро я бы взял Linux...
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Sharov, Вы писали:
Pzz>>И чем тебе фаирвол-то поможет, если ты выводишь сервис наружу?
S>Какая-никакая, а защита. Выше же написал -- простейшая защита от вкрипткидис. А как быть если кто-то сеть сканирует, уже можно насторожиться.
Потребность в фаирволах возникла потому, что сначала появились локальные сети, в которых не было никакой защиты за ненадобностью, потом появилось некоторое количество сетевого софтвария, рассчитанного жить в этих стерильных условиях, а потом все это подключили к глобальному интернету. И чтобы все это безобразие хоть как-то защитить, потребовались фаирволы.
Если сетевых сервисов нет, фаирвол не нужен. Если сетевой сервис снаружи не виден, фаирвол не нужен. Если сетевой сервис должен быть виден снаружи, то он должен быть рассчитан на такую жизнь, и фаирвол тоже не нужен. Единственная польза фаирвола проявляется в ситуации, когда не рассчитаный на внешний доступ сетевой сервис, тем не менее, такой доступ получает, и нет другого способа это выключить.
Если проектировать все заново, по-уму, то у сетевого сервиса должно быть два параметра: его максимально допустимая степень сетевой видимости (задаваемая разработчиком) и его актуальная степень видимости, задаваемая администратором (по умолчанию — "localhost"). И этот второй параметр не может быть больше первого (или его значения больше первого игнорируются, это вопрос вкуса).
Ответственностью разработчика является не указывать максимально допустимую степень сетевой видимости выше, чем его софтварий может перенести. Возможно так же, у глобально видимого сетевого сервиса операционная система должна изрядно ограничивать его права доступа к локальным файлам и ресурсам.
Здравствуйте, Sinclair, Вы писали:
S>Можно заниматься оптимизацией — в частности, устранять излишние проверки или выполнять спекулятивную оптимизацию. В отличие от аппаратной защиты, meltdown в такой системе невозможен.
Еще как возможен.
Meltdown происходит из-за того, что процессор грузит в кэш то, что не положено.
При софтверной проверке он может сделать то же самое, спекулятивно, если предсказатель переходов не угадает. А он почти наверняка не угадает, потому что 99% проверок не срабатывают, и спекулятивный исполнитель может смело топать в направлении "все хорошо".
Причем железный meldown лечится, если проверка прав происходит (в железе) то запуска загрузки в кэш. Это простой и ясный критерий, который легко можно реализовать в железе. А вот при софтверной проверке даже непонятно, что делать.
Здравствуйте, Pzz, Вы писали:
Pzz>Если проектировать все заново, по-уму, то у сетевого сервиса должно быть два параметра: его максимально допустимая степень сетевой видимости (задаваемая разработчиком) и его актуальная степень видимости, задаваемая администратором (по умолчанию — "localhost"). И этот второй параметр не может быть больше первого (или его значения больше первого игнорируются, это вопрос вкуса).
И всё это в итоге окажется просто интеллектуальной оболочкой вокруг того же пакетного фильтра.
ИЧ(С)Х, такие реализации давно есть — например, firewalld из RHEL/CentOS.
Pzz>А фаирвол, как фильтр пакетов, нет, не нужен.
Здравствуйте, Pzz, Вы писали:
N>>Но я вот очень задумчиво себе представляю AOT компиляцию какой-нибудь новой мозиллы при её установке Pzz>Знаешь, если ты поиграешься с golang, то ты поймешь, что компилятор может быть быстрым.
Это грубо некорректное сравнение:
1. У Go простой синтаксис (вот тут им сильно в плюс, они обошли стандартные грабли C-с-компанией), и убраны все возможности, которые тормозят компиляторы всяких C++.
2. У Go очень слабая оптимизация — она зарезана как кучей правил типа "выражение всегда вычисляется слева направо", "арифметика целых чисел по модулю", "аргументы функции гарантированно вычисляются слева направо" и т.п., так и организацией исполнения — например, сейчас внутреннее ABI требует сохранять при вызове другой функции все промежуточные данные на стеке (callee-saved регистров нет вообще, если не считать служебные вроде SP. Поэтому он на неё толком не тратится.
3. Проектов размера Firefox у него не существует. Как поведёт себя на этом компилятор, не сдохнет ли под нагрузкой — насколько мне известно, никто не проверял. А здесь я как раз предполагаю максимум граблей. Например, неявное наследование класса интерфейсу только по факту совместимости методов — то, что при сотнях тысяч классов может превратиться в кошмар при поиске соответствия.
Pzz>Насколько я понимаю, у go линкер делает примерно то, что здесь предлагают делать при установке.
Я что-то не видел, чтобы у него различались компилятор и линкер как разные сущности. В 99.9% случаев просто кидают его компилировать всю свалку исходников вместе. Компилятор же не делает ничего существенно хитрого (см. выше). Промежуточного языка тоже у него нет, всё идёт сразу в свой ассемблер. И что же тут общего?
Здравствуйте, CoderMonkey, Вы писали:
Pzz>>У ARM'а всю жизнь был некогерентный кеш, что не мешало gcc на нем прекрасно работать.
CM>Вот именно что был. Видимо, не осилили до конца.
А я просто не знаю, какой он сейчас. Казалось бы, некогерентный кэш проявляет себя в двух случаях: когда имеется bus mastering (это проблема драйверов), и когда имеется SMP.
Я имел дело с ARM'ом, когда SMP там еще не было. Как сейчас, я просто не в курсе.
Здравствуйте, netch80, Вы писали:
N>Это грубо некорректное сравнение:
N>1. У Go простой синтаксис (вот тут им сильно в плюс, они обошли стандартные грабли C-с-компанией), и убраны все возможности, которые тормозят компиляторы всяких C++.
Ну мы говорим о стадии, которая уже после синтаксического анализа.
N>2. У Go очень слабая оптимизация — она зарезана как кучей правил типа "выражение всегда вычисляется слева направо", "арифметика целых чисел по модулю", "аргументы функции гарантированно вычисляются слева направо" и т.п., так и организацией исполнения — например, сейчас внутреннее ABI требует сохранять при вызове другой функции все промежуточные данные на стеке (callee-saved регистров нет вообще, если не считать служебные вроде SP. Поэтому он на неё толком не тратится.
Это да. Но тут по-моему дело не только в правилах, а и в том, что в плане оптимизации никто пока особенно и не напрягался, так что оптимизатор там довольно наивный.
Он, правда, легко и не напрягаясь умеет делать некоторые штучки, которые в Си сделать невозможно или очень сложно. Например, евонный инлайнер и escape analyser работает даже для вызовов из одного пакета в другой. И линковка у него всегда smart, если функция не нужна, ее никто не влинкует. Это вот преимущество того, что у него не #include, а import, и компилятор всегда видит, что импортируется, а не только прототипы функций.
Кроме того, у него компилятор умеет выделять идеоматические конструкции в тексте, и компилировать специальным образом. Это, вообще, по-моему, богатая мысль, вместо того, чтобы потратить жизнь на создание полноценного статического анализатора, просто научиться выделять стандартные конструкции, которыми все пользуются, и придумать, как именно их можно оптимизировать. Правда, пока он таких конструкций выделяет немного.
Но в общем и целом, с твоим утверждением, что у него оптимизация паршивая, я соглашусь.
N>3. Проектов размера Firefox у него не существует. Как поведёт себя на этом компилятор, не сдохнет ли под нагрузкой — насколько мне известно, никто не проверял. А здесь я как раз предполагаю максимум граблей. Например, неявное наследование класса интерфейсу только по факту совместимости методов — то, что при сотнях тысяч классов может превратиться в кошмар при поиске соответствия.
А ему и не надо ничего искать. У него есть значение конкретного типа, и интерфейсный тип, в который его надо преобразовать. Ему надо лишь проверить совместимость.
Другой вопрос, что эти вот переходнички от конкретного типа к интерфейсу, не знаю, как они у него называются, он их старается не дублировать, поэтому ему надо убедиться, что такого еще нет. Я, кстати, не уверен, что он это делает статически. Ему точно совершенно приходится делать это в рантайме (например, если мы преобразуем тип T сначала в интерфейс I1, а потом в его подмножество, интерфейс I2, то переходничок будет I2->T, а не I2->I1->T, и выяснится это только в рантайме). Но вот делает ли он это статически там, где можно, я просто даже не знаю
Pzz>>Насколько я понимаю, у go линкер делает примерно то, что здесь предлагают делать при установке.
N>Я что-то не видел, чтобы у него различались компилятор и линкер как разные сущности. В 99.9% случаев просто кидают его компилировать всю свалку исходников вместе. Компилятор же не делает ничего существенно хитрого (см. выше). Промежуточного языка тоже у него нет, всё идёт сразу в свой ассемблер. И что же тут общего?
Различаются, различаются, еще как различаются. У него компилятор оставляет по себе файлики .a, с парой загадочных файлов внутри. И насколько я понимаю, там лежит не код, а результат синтаксического анализа (со всеми проверками, конечно). И если в проекте один и тот же пакет используется несколько раз, его только один раз скомпилируют. А вот уже линкер свинчивает все это вместе.
Заметь, что евонный дизассемблер умеет дизассемблировать уже свинченный исполняемый файл, а не эти промежуточные непойми-что-за-штучки.
Здравствуйте, lpd, Вы писали:
lpd>Из-за проблем авторов софта под винду я страдаю еще меньше, чем из-за проблем процессоростроителей. Я не против платного closed-source, однако по факту он оказывается ненужным из-за большого количества open-source софта.
Это лично вам он оказывается не нужен. А вот всем остальным внезапно оказывается нужен платный софт с закрытыми исходниками.
Ну, то есть я не против того, что таки существует бесплатный open-source, но он не может вытеснить платный софт из соответствующих ниш.
И я не вижу перспективы, чтобы он когда-то смог.
Если посмотреть на успехи внедрения новых платформ за последние десятилетия, то внезапно окажется, что успех напрямую связан с возможностями монетизации.
iOS взлетел не потому, что в нём были какие-то передовые идеи, а потому что APPL построил экосистему разработки так, что простые пацаны смогли зарабатывать на этой платформе. И сразу — мотивация, конкуренция, совершенствование, прогресс.
А если я завтра выпущу свою бесплатную ОС, рассчитанную на бесплатный софт, то в неё тупо не пойдут разработчики, т.к. им за это не платят. А, следовательно, не пойдут и пользователи, потому что там нет софта.
Ну и всё — проблема решена; аудитории нет, проект закрыт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали: S>А кастыдей из-за типизации там где не надо понаставит.
Чего???
S>>>А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится. S>>Да как нефиг делать. Вы посмотрите на таблицу implicit преобразований в T-SQL.
S>Я про ansi sql, а не диалекты.
Я за вами не успеваю — только что был T-Sql
Ничего, ANSI ещё хуже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хм. Вообще-то он есть — MAC-адрес. Почти прибит. Но за пределы локалки не передается. Нужно ? Зачем ? scf>Чтобы после переезда в другую страну включаешь кофеварку, она лезет на сервер. И сервер знает, что а) это та же кофеварка б) она теперь в другой стране. Решает проблему аутентификации и локализации.
На самом деле вместо "адреса" тут нужна вшитая в каждую кастрюлю пара ключей — публичный/приватный.
Ну, как в современных IP-телефонах. Удивительно, как производители в этой отрасли протрахались 15 с абсолютно дырявыми реализациями вроде "делаем запрос по FTP и открытым текстом качаем файлик настроек для аппарата, вместе с именем/паролем пользователя на SIP сервере". Три поколения костылей сменилось, пока они не допетрили использовать SSL и PKI.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А если я завтра выпущу свою бесплатную ОС, рассчитанную на бесплатный софт, то в неё тупо не пойдут разработчики, т.к. им за это не платят. А, следовательно, не пойдут и пользователи, потому что там нет софта.
То, что ты говоришь, верно для некоторых ниш: например, open source игр, действительно, меньше, чем платных. В меньшей степени это верно и для приложений с графическим интерфейсом.
Open source разработчики по большей части пишут то, что им самим интересно и нужно. При этом получается софт 'для программистов и админов', что оказалось востребованым на серверах и на рабочих станциях программистов. В результате на серверах open source софт вытеснил коммерческий.
Возвращаясь к теме native vs VM:
Соглашусь, что при большом числе процессорных архитектур распространять программы в промежуточных кодах имеет смысл.
С другой стороны, польза от зоопарка процессорных архитектур неочевидна — это только бы усложнило жизнь программистам, т.к. по сути эти архитектуры мало чем отличались бы.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Возвращаясь к теме native vs VM: lpd>Соглашусь, что при большом числе процессорных архитектур распространять программы в промежуточных кодах имеет смысл. lpd>С другой стороны, польза от зоопарка процессорных архитектур неочевидна — это только бы усложнило жизнь программистам, т.к. по сути эти архитектуры мало чем отличались бы.
Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?
А насчёт усложнения есть некоторые сомнения — например, тот же Intel спокойно бы выкинул FPU, который устарел сразу по нескольким параметрам, и стало бы легче чуть менее, чем всем.
Здравствуйте, netch80, Вы писали:
N>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?
Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.
N>А насчёт усложнения есть некоторые сомнения — например, тот же Intel спокойно бы выкинул FPU, который устарел сразу по нескольким параметрам, и стало бы легче чуть менее, чем всем.
Понадобилось бы стандартизировать промежуточный код и его динамическую линковку(если ее оставлять). Хотелось бы, чтобы все это было оправдано существенными улучшениями процессоров, а не просто отключением поддержки legacy-инструкций.
Процессоры, выпускаемые разными фирмами по одной архитектуре(Intel и особенно Arm) и без того отличаются между собой, оставаясь совместимыми. Не исключено, что этого достаточно для развития технологий процессоров.
Это раньше у всех был Windows, и для него shareware программы, которые, действительно, кто-то мог не перекомпилировать под новую архитектуру. Вот это настоящий legacy.
А сейчас:
— офисным пользователями нужен ограниченный круг программ, которые производители пересоберут под новый процессор, да и нет у офисных пользователей потребности в новых процессорах быстрее 3Гц.
— домашним пользователем нужны только браузер и видеокарта с поддержкой видео и 3d графики.
— на серверах у всех Linux и программы из open-source репозиториев, которые быстро пересобираются сообществом.
Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>А кастыдей из-за типизации там где не надо понаставит. S>Чего???
Я имел в виду , что типизация не бесплатна. И привело бы к усложнению ansi sql, которое бы пришлось обплясывать разным вендорам.
S>Я за вами не успеваю — только что был T-Sql S>Ничего, ANSI ещё хуже.
Я же изначально говорил про sql (ansi) и его диалекты типа t-sql. Для своих задач он вполне годится, и минимальная типизация присутствует.
Здравствуйте, WolfHound, Вы писали:
WH>Ну вот собственно таким микропрограммам никто не мешает быть статически типизированными. WH>Более того писать их можно не в блокноте, а в полноценной ИДЕ которая если делать правильно будет запускаться за доли секунды. WH>Sublime запускается мгновенно. Когда нитра станет нативной она тоже будет стартовать доли секунды. Сейчас при старте .НЕТ тормозит.
В теории ты вроде бы прав... Но смотрим на практику (на существующие в данный момент языки и инструменты) и видим, что все подобные задачи решаются исключительно на динамических языка. Может мы что-то не учитываем в наших рассуждениях? )))
WH>>>2)Создание консольного приложения на C# занимает несколько секунд. _>>Угу, в фантазиях. ) WH>На практике.
Ну давай посмотрим на конкретику. Вот реальный пример из жизни, про который я писал выше. Значит скрипт должен для каждого fb2 файла в текущем каталоге выполнить преобразование его содержимого (преобразовать все html entities в их юникод-представление) и засунуть файл в zip архив с именем name.fb2.zip. Плюс к этому исходный файл должен быть на всякий случай сохранён под именем name.fb2.bak (чтобы программы анализа fb2 файлов его больше не видели). Реализующий всё это Питон скрипт занял у меня ровно 9 строчек лаконичного кода, который я писал порядка 3-ёх минут, из которых одну потратил на поиск в гугле имени функции и модуля из стандартной библиотеки для преобразования html entities. Запуск Notepad++ и потом скрипта естественно мгновенные. А за какое время ты с нуля напишешь на C# аналогичное решение и сколько строчек кода оно будет занимать?
_>>Проблема таких систем (кстати Midori/Singularity далеко не первые в этой области, намного раньше было например такое http://www4.cs.fau.de/Projects/JX/index.html решение), что они очень ультимативные: или всё прикладное ПО написано на соответствующем управляемом языке или система просто не работает (нельзя написать один критичный кусочек на голом ассемблере). Ну и соответственно пока я не увижу реализацию например кодека h.264 на управляемом языке, не уступающую по эффективности классическим нативным реализациям, то в нормальное будущее подобной ОС не поверю. WH>С этим проблем нет. WH>Дафна может доказывать любой императивный код включая ассемблер.
Ну в такой вариант я уже могу поверить, но это будет уже весьма далеко от Mirodi и им подобным... Кстати, а где-нибудь можно взглянуть на:
— примеры применения Дафны в каких-то реальных проектах (не важно на каких языках)
— хоть один пример для других языков (пускай и не такую экзотику, как ассемблер)?
Здравствуйте, Sinclair, Вы писали:
_>>Так я как бы вполне одобряю идею распространения байткода (ну естественно не такого как в .net, а скорее такого как llvm, но это не суть). Только вот с фактом и возможностью верификации подобное распространение ПО никак не связано. И вот как раз на счёт возможности такой верификации у меня есть сомнения. Правда так сказать теоретические (сам я как-то ни одного подобного верификатора пока не писал). S>Не очень понял, в чём именно сомнения. "Такая верификация" вполне себе встроена во вполне себе реально существующие системы.
Здравствуйте, alex_public, Вы писали:
_>В теории ты вроде бы прав... Но смотрим на практику (на существующие в данный момент языки и инструменты) и видим, что все подобные задачи решаются исключительно на динамических языка. Может мы что-то не учитываем в наших рассуждениях? )))
Интерпретатор динамически типизированного языка может написать школота.
Статически типизированный язык с выводом типов может написать далеко не каждый.
И большинство из тех, кто может оторванные от реальности учёные у которых всегда получается хаскель.
А остальным платят большие деньги за другую работу.
_>Ну давай посмотрим на конкретику. Вот реальный пример из жизни, про который я писал выше. Значит скрипт должен для каждого fb2 файла в текущем каталоге выполнить преобразование его содержимого (преобразовать все html entities в их юникод-представление) и засунуть файл в zip архив с именем name.fb2.zip. Плюс к этому исходный файл должен быть на всякий случай сохранён под именем name.fb2.bak (чтобы программы анализа fb2 файлов его больше не видели). Реализующий всё это Питон скрипт занял у меня ровно 9 строчек лаконичного кода, который я писал порядка 3-ёх минут, из которых одну потратил на поиск в гугле имени функции и модуля из стандартной библиотеки для преобразования html entities. Запуск Notepad++ и потом скрипта естественно мгновенные. А за какое время ты с нуля напишешь на C# аналогичное решение и сколько строчек кода оно будет занимать?
Если в C# будут нужные библиотеки всё будет примерно так же.
_>Ну в такой вариант я уже могу поверить, но это будет уже весьма далеко от Mirodi и им подобным... Кстати, а где-нибудь можно взглянуть на:
Mirodi это продолжение работы на тему Singularity и Verve.
Because of their complexity, a holy grail of software verification has been to verify properties of operating systems. Operating systems are usually written in low-level languages, such as C, that provide very few guarantees. The Singularity project took the approach of writing an operating system in C#, a type-safe, memory-safe language. A weakness of this approach is that operating systems necessarily need to call lower-level code to, for instance, move the stack pointer. Verve addresses this problem by partitioning the operating system into verified assembly that is required to be low-level and a trusted interface to rest of the operating system, written in C#. There is a trusted specification that guarantees the low-level assembly code does not mess with the heap and that the high-level C# code does not mess with the stacks.
В данном подходе ничто не запрещает иметь пользовательский верифицированный ассемблерный код.
Более того я сомневаюсь, что он вообще нужен при наличии halide.
_>- примеры применения Дафны в каких-то реальных проектах (не важно на каких языках)
Не интересовался.
1)Дафна императивный ОО язык. Соответственно натянуть её на любой из популярных языков дело техники.
2)Дафна анализирует каждую функцию независимо от других. А значит анализ можно распараллелить и результат закешировать.
Те не будет проблем даже терабайтом исходников.
_>- хоть один пример для других языков (пускай и не такую экзотику, как ассемблер)?
А какая разница что доказывать императивный код, который меняет локальные переменные или ассемблерный код, который меняет регистры?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lpd, Вы писали:
N>>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам? lpd>Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.
Ты это усложнение и не заметишь. Поставил продукт в виде бинарников IL, файлов данных и т.п. — а старт бинарника по любому исполняет RTLD. Он и сейчас везде достаточно нетривиальный — чтение ELF/COFF/etc., определение сегментов для загрузки, расчёт перемещений, линковка автоподключаемых SO/DLL — если к этому добавится конверсия прочтённого IL кода в команды местного процессора, это лишь замедлит старт. Прозрачность для автора программы сохранится по полной.
N>>А насчёт усложнения есть некоторые сомнения — например, тот же Intel спокойно бы выкинул FPU, который устарел сразу по нескольким параметрам, и стало бы легче чуть менее, чем всем. lpd>Понадобилось бы стандартизировать промежуточный код и его динамическую линковку(если ее оставлять). Хотелось бы, чтобы все это было оправдано существенными улучшениями процессоров, а не просто отключением поддержки legacy-инструкций.
Ну примеры Java/.NET/etc. показывают, что преимущество в виде пресловутого "write once, run anywhere" таки есть — а где его нет, проблема почти всегда не в процессоре. Исключения идут на случаи типа "мы тут ничего векторного не можем завести => FPS <= 10".
lpd>Процессоры, выпускаемые разными фирмами по одной архитектуре(Intel и особенно Arm) и без того отличаются между собой, оставаясь совместимыми. Не исключено, что этого достаточно для развития технологий процессоров. lpd>Это раньше у всех был Windows, и для него shareware программы, которые, действительно, кто-то мог не перекомпилировать под новую архитектуру. Вот это настоящий legacy. lpd>А сейчас: lpd>- офисным пользователями нужен ограниченный круг программ, которые производители пересоберут под новый процессор, да и нет у офисных пользователей потребности в новых процессорах быстрее 3Гц.
Даже есть так, офисные это далеко не все, и необязательно самый денежный сегмент.
lpd>- домашним пользователем нужны только браузер и видеокарта с поддержкой видео и 3d графики.
И производителям игр вечно не хватает скорости.
lpd>- на серверах у всех Linux и программы из open-source репозиториев, которые быстро пересобираются сообществом.
Тоже не у всех... на прошлой работе у нас было много знакомств с HPC пакетами расчёта чего-то хитрого, за которые их авторы дрожали, даже сдавая в аренду на настроенных ими серверах.
Но я согласен, что это нишевый случай.
lpd>Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.
Здравствуйте, WolfHound, Вы писали:
_>>В теории ты вроде бы прав... Но смотрим на практику (на существующие в данный момент языки и инструменты) и видим, что все подобные задачи решаются исключительно на динамических языка. Может мы что-то не учитываем в наших рассуждениях? ))) WH>Интерпретатор динамически типизированного языка может написать школота. WH>Статически типизированный язык с выводом типов может написать далеко не каждый. WH>И большинство из тех, кто может оторванные от реальности учёные у которых всегда получается хаскель. WH>А остальным платят большие деньги за другую работу.
Т.е. ты хочешь сказать, что просто пока никто не осилил сделать правильный статически типизированный язык, подходящий под скриптовой стиль использования? )
_>>Ну давай посмотрим на конкретику. Вот реальный пример из жизни, про который я писал выше. Значит скрипт должен для каждого fb2 файла в текущем каталоге выполнить преобразование его содержимого (преобразовать все html entities в их юникод-представление) и засунуть файл в zip архив с именем name.fb2.zip. Плюс к этому исходный файл должен быть на всякий случай сохранён под именем name.fb2.bak (чтобы программы анализа fb2 файлов его больше не видели). Реализующий всё это Питон скрипт занял у меня ровно 9 строчек лаконичного кода, который я писал порядка 3-ёх минут, из которых одну потратил на поиск в гугле имени функции и модуля из стандартной библиотеки для преобразования html entities. Запуск Notepad++ и потом скрипта естественно мгновенные. А за какое время ты с нуля напишешь на C# аналогичное решение и сколько строчек кода оно будет занимать? WH>Если в C# будут нужные библиотеки всё будет примерно так же.
Все библиотечки имеются (во всяком случае судя по документации): https://msdn.microsoft.com/ru-ru/library/7c5fyk1k(v=vs.110).aspx и https://msdn.microsoft.com/ru-ru/library/system.io.compression.zipfile(v=vs.110).aspx. Но при этом я всё равно крайне сомневаюсь в 9-и строчка и 2-ух минутах на C#.
_>>Ну в такой вариант я уже могу поверить, но это будет уже весьма далеко от Mirodi и им подобным... Кстати, а где-нибудь можно взглянуть на: WH>Mirodi это продолжение работы на тему Singularity и Verve. WH>В данном подходе ничто не запрещает иметь пользовательский верифицированный ассемблерный код.
Я в курсе. Но Mirodi и Singularity — это опять же не реальные проекты. В том смысле что не используемые где-то в реальной работе.
WH>Более того я сомневаюсь, что он вообще нужен при наличии halide.
Ну SIMD — это не единственное применение низкоуровневого кода. К примеру написание какой-нибудь VM на языке типа Java или safe C# кажется крайне сомнительным.
_>>- примеры применения Дафны в каких-то реальных проектах (не важно на каких языках) WH>Не интересовался. WH>1)Дафна императивный ОО язык. Соответственно натянуть её на любой из популярных языков дело техники. WH>2)Дафна анализирует каждую функцию независимо от других. А значит анализ можно распараллелить и результат закешировать. WH>Те не будет проблем даже терабайтом исходников. _>>- хоть один пример для других языков (пускай и не такую экзотику, как ассемблер)? WH>А какая разница что доказывать императивный код, который меняет локальные переменные или ассемблерный код, который меняет регистры?
Меня вот интересуют конкретные реальные примеры использования. Я практик, а не теоретик. )
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, lpd, Вы писали:
N>>>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам? lpd>>Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.
N>Ты это усложнение и не заметишь. Поставил продукт в виде бинарников IL, файлов данных и т.п. — а старт бинарника по любому исполняет RTLD.
Мне больше всего не нравится отладка при JIT-компиляции. В нативном коде есть только исходник и бинарный код, причем второе легко сопоставить с первым. При JIT-компиляции добавляется промежуточный код, и уже не так просто понять что к чему без помощи VM, просто посмотрев и дизассемблировав память процесса.
Вроде как Linux потому и нравится программистам, что его можно разобрать на составляющие и отладить или заменить их. Промежуточный код же отдаляет низкоуровневые операции от пользователя. Хотя при написании высокоуровневых программ разница не столь значительна.
lpd>>Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.
N>Да, частично она решена. Но далеко не полностью.
Процессоры достигли хорошего уровня(если не максимума), и дальнейшее увеличение скорости нужно только на серверах, для процесса разработки(инженеров и дизайнеров) и для игр + для javascript. Причем игры все равно оптимизируют векторными инструкциями. Получается, промежуточный код решает только нишевые проблемы (софт для дизайнеров/проектировщиков).
Я же рассматриваю вопрос с позиций Linux, и для open source промежуточный код нужен как машине пятое колесо, решающее достаточно гипотетические проблемы процессоростроителей. Вот с компиляцией промежуточного кода в бинарный в момент установки приложения я бы не спорил, если бы разнообразие процессоров привело к необходимости распространения программ таким способом.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>Т.е. ты хочешь сказать, что просто пока никто не осилил сделать правильный статически типизированный язык, подходящий под скриптовой стиль использования? )
Может и сделал. Но его ещё и распространить нужно.
Ну и любителей писать скрипты на хаскеле тоже забывать не стоит. http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
_>Все библиотечки имеются (во всяком случае судя по документации): https://msdn.microsoft.com/ru-ru/library/7c5fyk1k(v=vs.110).aspx и https://msdn.microsoft.com/ru-ru/library/system.io.compression.zipfile(v=vs.110).aspx. Но при этом я всё равно крайне сомневаюсь в 9-и строчка и 2-ух минутах на C#.
А ты можешь показать код на питоне?
Чтобы понять, что конкретно он делает.
_>Я в курсе. Но Mirodi и Singularity — это опять же не реальные проекты. В том смысле что не используемые где-то в реальной работе.
1)Ты сказал, что этот подход далёк от мидори. Я тебе показал, что это нет так.
2)Joe Duffy говорит, что мидори убили по политическим причинам. И если бы проект был опенсорс, то всё было бы несколько иначе.
Похоже он бросил микрософт и начал заниматься чем-то другим. http://joeduffyblog.com/2017/06/01/an-update-on-me-pulumi/
Судя по этой фразе дело мидори продолжается.
Since then, I’ve been having the time of my life spelunking at the intersection of distributed cloud systems, programming languages, and machine intelligence.
WH>>Более того я сомневаюсь, что он вообще нужен при наличии halide. _>Ну SIMD — это не единственное применение низкоуровневого кода. К примеру написание какой-нибудь VM на языке типа Java или safe C# кажется крайне сомнительным.
1)Тут разговор про язык, намного более совершенный чем Java или safe C#.
2)Всё что тебе нужно это генерировать верифицируемый ассемблер. И ОС его радостно запустит.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lpd, Вы писали:
lpd>Мне больше всего не нравится отладка при JIT-компиляции. В нативном коде есть только исходник и бинарный код, причем второе легко сопоставить с первым. При JIT-компиляции добавляется промежуточный код, и уже не так просто понять что к чему без помощи VM, просто посмотрев и дизассемблировав память процесса.
Зачем такие сложности?
lpd>Вроде как Linux потому и нравится программистам, что его можно разобрать на составляющие и отладить или заменить их. Промежуточный код же отдаляет низкоуровневые операции от пользователя. Хотя при написании высокоуровневых программ разница не столь значительна.
Ещё раз. Все компиляторы имеют внутри себя промежуточный код. Просто тебе его не показывают.
lpd>Вот с компиляцией промежуточного кода в бинарный в момент установки приложения я бы не спорил, если бы разнообразие процессоров привело к необходимости распространения программ таким способом.
Так тут про этот вариант и говорят. Про то что промежуточный код может работать только через JIT ты сам себе напридумывал.
А разнообразию процессоров мешает только отсутствие софта под новые архитектуры.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А разнообразию процессоров мешает только отсутствие софта под новые архитектуры.
Осталось только пояснить, зачем нужны отличающиеся на +-10% скорости, однако несовместимые процессоры, либо доказать значительное отставание Intel/Arm от теоретически возможных процессоров. Выпиливание legacy-инструкций из Intel, о котором говорил netch80, не выглядит достаточной причиной для добавления промежуточного кода. Я, конечно, понимаю, что монополизм затрудняет технический прогресс, однако хотелось бы посмотреть хотя бы на прототип нового супер-процессора, прежде чем менять инфраструктуру инсталляции приложений на миллиарде компьютеров.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Осталось только пояснить, зачем нужны отличающиеся на +-10% скорости, однако несовместимые процессоры,
Чего тебя вообще так это волнует?
Система команд процессора будет заботить только производителя процессора. И больше никого.
lpd>либо доказать значительное отставание Intel/Arm от теоретически возможных процессоров.
А мы не знаем. Дело в том, что разработка процессора дело не дешёвое.
А если его нельзя выпустить на массовый рынок, то он не окупится.
А без софта его на массовый рынок не выпустить.
А если весь софт прибит гвоздями к одной архитектуре...
И нет. Опенсорса не достаточно. Он вообще является микроскопической частью всего софта.
lpd>Выпиливание legacy-инструкций из Intel, о котором говорил netch80, не выглядит достаточной причиной для добавления промежуточного кода.
Есть много других причин.
1)Надёжность и безопасность софта. Верифицируемый код хакать намного сложнее.
2)Удобство разработчиков. Если иметь промежуточный код то не нужно думать о том что там за процессор.
Не нужно собирать кучу версий софта.
Пользователю не нужно думать какой из инсталляторов скачать.
3)Более быстрые и отзывчивые программы. Когда нам не нужно бояться многопоточности, ибо компилятор проверяет что там всё хорошо можно очень агрессивно всё распараллеливать.
4)Значительное упрощение программ. С++ это ад. И это при том что я очень хорошо знаю С++. Но кроме него я знаю ещё много чего. И поэтому могу сравнивать.
5)Выпуск новых версий ВМ с новым оптимизатором ускорит все программы. А не только те которые разработчики не поленились перекомпилировать.
6)Возможность создавать пару процессор и хитровывернутый оптимизатор под него. Какой прирост производительности это даст трудно сказать. Может быть и в разы.
lpd>Я, конечно, понимаю, что монополизм затрудняет технический прогресс, однако хотелось бы посмотреть хотя бы на прототип нового супер-процессора, прежде чем менять инфраструктуру инсталляции приложений на миллиарде компьютеров.
Мы тут рассматриваем ситуацию "весь софт исчез". Нужно писать с чистого листа.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И нет. Опенсорса не достаточно. Он вообще является микроскопической частью всего софта.
Слышу слова прожженного виндузятника. Переубеждать не буду, т.к. это обычно бесполезно.
lpd>>Выпиливание legacy-инструкций из Intel, о котором говорил netch80, не выглядит достаточной причиной для добавления промежуточного кода. WH>Есть много других причин. WH>1)Надёжность и безопасность софта. Верифицируемый код хакать намного сложнее. WH>2)Удобство разработчиков. Если иметь промежуточный код то не нужно думать о том что там за процессор. WH>Не нужно собирать кучу версий софта. WH>Пользователю не нужно думать какой из инсталляторов скачать. WH>3)Более быстрые и отзывчивые программы. Когда нам не нужно бояться многопоточности, ибо компилятор проверяет что там всё хорошо можно очень агрессивно всё распараллеливать. WH>4)Значительное упрощение программ. С++ это ад. И это при том что я очень хорошо знаю С++. Но кроме него я знаю ещё много чего. И поэтому могу сравнивать. WH>5)Выпуск новых версий ВМ с новым оптимизатором ускорит все программы. А не только те которые разработчики не поленились перекомпилировать. WH>6)Возможность создавать пару процессор и хитровывернутый оптимизатор под него. Какой прирост производительности это даст трудно сказать. Может быть и в разы.
Пункты 1,3 и 4 довольно теоретичны, и ничего не мешает их воплотить жизнь сейчас на этапе сборки софта(в clang), поэтому они нерелевантны.
Остальное имеет смысл, только ты преувеличиваешь роль нового процессора и оптимизации под процессор в конечном user-experience пользователя, который и имеет решающее значение. А между тем все это потребовало бы еще стандартизации промежуточного кода. Кроме того, анализировать присланный пользователем core-dump было бы сложнее.
Получается, если посмотреть теоретически на этот вопрос, то это выглядит красиво. На практике миры софта и процессоров устроены так, что при значительном количестве усилий пользы было бы немного: не грузился бы компьютер в разы быстрее, не отзывчевее были бы приложения, не быстрее бы грузились страницы в браузере, а игры бы оптимизировали все равно вручную. Могу представить заметный выигрыш только в приложениях обработки видео.
Вот в 1990-е и 2000-ные когда каждый год частота процессора увеличивалась на 50%, это бы выглядело полезно.
lpd>>Я, конечно, понимаю, что монополизм затрудняет технический прогресс, однако хотелось бы посмотреть хотя бы на прототип нового супер-процессора, прежде чем менять инфраструктуру инсталляции приложений на миллиарде компьютеров. WH>Мы тут рассматриваем ситуацию "весь софт исчез". Нужно писать с чистого листа.
В принципе, поезд не ушел, и систему установки/компиляции распространять можно и сейчас — вопрос в спросе.
Хотите — делайте Linux с поддержкой любых процессоров и оптимизацией при инсталляции. Только у современных ОС есть недостатки и серьезнее.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
WH>>И нет. Опенсорса не достаточно. Он вообще является микроскопической частью всего софта. lpd>Слышу слова прожженного виндузятника. Переубеждать не буду, т.к. это обычно бесполезно.
Просто по тому что я знаю сколько софта делается за пределами опенсорс мирка.
Например, то что я сейчас делаю не опенсорс. И оно никогда не будет опенсорс. Просто по тому что оно заказчику не нужно.
И такого софта на порядки больше чем опенсорса.
Он просто для линуксойдов невидим.
lpd>Пункты 1,3 и 4 довольно теоретичны, и ничего не мешает их воплотить жизнь сейчас на этапе сборки софта(в clang), поэтому они нерелевантны. clang это С++. А С++ идёт лесом от слова совсем.
lpd>Остальное имеет смысл, только ты преувеличиваешь роль нового процессора и оптимизации под процессор в конечном user-experience пользователя, который и имеет решающее значение.
Юзеры разные бывают.
lpd>А между тем все это потребовало бы еще стандартизации промежуточного кода.
Ты так говоришь, как будто это что-то сложное.
lpd>Кроме того, анализировать присланный пользователем core-dump было бы сложнее.
Наоборот проще. Ибо разбитой памяти не будет. Гонок не будет.
Будет абсолютно предсказуемое завершение процесса.
После которого можно сохранить дамп данных процесса в платформонезависимом формате. Обрати внимание дамп данных, а не сырой памяти.
Ты пойми простую вещь: Архитектура процессора вообще нигде отсвечивать не будет. С ней соприкасаться будут только разработчики процессора. Ну и те, кому просто интересно с этим поиграть.
lpd>Получается, если посмотреть теоретически на этот вопрос, то это выглядит красиво. На практике миры софта и процессоров устроены так, что при значительном количестве усилий пользы было бы немного:
Ох. Усилий в этом случае нужно намного меньше чем сейчас. Причём вообще всем.
lpd>Хотите — делайте Linux с поддержкой любых процессоров и оптимизацией при инсталляции. Только у современных ОС есть недостатки и серьезнее.
Ага. Они все на С написаны.
А нужно делать что-то вроде мидори.
И писать на верифицируемом языке.
Проблема в текущий момент в том, что под эту систему нет софта. Без софта эта система никому не нужна. А под не нужную систему никто не будет писать софт.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Т.е. ты хочешь сказать, что просто пока никто не осилил сделать правильный статически типизированный язык, подходящий под скриптовой стиль использования? ) WH>Может и сделал. Но его ещё и распространить нужно.
Ну, как я уже говорил, лично я практик, и поэтому меня как раз не интересуют какие-то там неизвестные (и соответственно не имеющие развитой инфраструктуры), пусть даже и замечательные инструменты. А вот среди известных в данной области кругом одни динамические языки...
WH>Ну и любителей писать скрипты на хаскеле тоже забывать не стоит. WH>http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
С Хаскелем двойственная ситуация. С одной стороны он весьма лаконичный (частенько даже лучше Питона), а с другой стоит хоть немного выйти за рамки парадигмы ФП (например банально захотеть мутабельную переменную), как начинается такой ад, в сравнение с которым PHP и VB начинают казаться замечательными языками. )))
_>>Все библиотечки имеются (во всяком случае судя по документации): https://msdn.microsoft.com/ru-ru/library/7c5fyk1k(v=vs.110).aspx и https://msdn.microsoft.com/ru-ru/library/system.io.compression.zipfile(v=vs.110).aspx. Но при этом я всё равно крайне сомневаюсь в 9-и строчка и 2-ух минутах на C#. WH>А ты можешь показать код на питоне? WH>Чтобы понять, что конкретно он делает.
Да вроде очевидно объяснил же. Хотя и с кодом проблем нет:
import os, HTMLParser, zipfile
for name in os.listdir('.'):
if name.endswith('.fb2'):
data=open(name).read().decode('UTF-8')
data=HTMLParser.HTMLParser().unescape(data)
zipfile.ZipFile(name+'.zip', 'w', zipfile.ZIP_DEFLATED).writestr(name, data.encode('UTF-8'))
os.rename(name, name+'.bak')
Кстати, я что-то обсчитался тогда: по факту оказалось 7 строк всего (и то из-за моего логического разбиения для удобства понимания — так то первые три строки внутри if по сути являются одной строкой).
_>>Я в курсе. Но Mirodi и Singularity — это опять же не реальные проекты. В том смысле что не используемые где-то в реальной работе. WH>1)Ты сказал, что этот подход далёк от мидори. Я тебе показал, что это нет так. WH>2)Joe Duffy говорит, что мидори убили по политическим причинам. И если бы проект был опенсорс, то всё было бы несколько иначе. WH>Похоже он бросил микрософт и начал заниматься чем-то другим. WH>http://joeduffyblog.com/2017/06/01/an-update-on-me-pulumi/ WH>Судя по этой фразе дело мидори продолжается. WH>
WH>Since then, I’ve been having the time of my life spelunking at the intersection of distributed cloud systems, programming languages, and machine intelligence.
Хы, товарищ наконец то созрел для организации своего стартапчика... Это позитивно, хотя офис у них конечно весёлый сейчас (http://pulumi.com/contact). Однако не пойму откуда ты взял, что это будет продолжением дела Midori. Я например после прочтения этого его сообщения и изучения их сайта по прежнему не имею ни малейшего представления об их идеях. Облака, ИИ и т.п. — это всё просто текущие относительно хайповые темы...
WH>>>Более того я сомневаюсь, что он вообще нужен при наличии halide. _>>Ну SIMD — это не единственное применение низкоуровневого кода. К примеру написание какой-нибудь VM на языке типа Java или safe C# кажется крайне сомнительным. WH>1)Тут разговор про язык, намного более совершенный чем Java или safe C#. WH>2)Всё что тебе нужно это генерировать верифицируемый ассемблер. И ОС его радостно запустит.
Опять же: в теории — конечно, а на практике — не видел пока ничего подобного. ) И да, я понимаю, что в данной темке обсуждается "альтернативная история", а не реальность. Но это тоже можно обсуждать по разному. К примеру есть определённые решения, эффективность которых уже проверена прямо сейчас и они пока не "захватили мир" только в силу различных "политических" и экономических причин. А вот твои предложения чаще всего имеют ещё и не проверенную на практике эффективность. При этом они мне чаще всего тоже нравятся, но я всегда хочу реальных примеров...
Здравствуйте, alex_public, Вы писали:
_>С Хаскелем двойственная ситуация. С одной стороны он весьма лаконичный (частенько даже лучше Питона), а с другой стоит хоть немного выйти за рамки парадигмы ФП (например банально захотеть мутабельную переменную), как начинается такой ад, в сравнение с которым PHP и VB начинают казаться замечательными языками. )))
Зачем тебе изменяемая переменная в скрипте, написанном на хаскеле?
Изменяемые переменные нужны только для оптимизации.
_>Да вроде очевидно объяснил же. Хотя и с кодом проблем нет:
foreach (var name in Directory.EnumerateFiles(".", "*.fb2"))
{
var data = File.ReadAllText(name, Encoding.UTF8);
data = HttpUtility.HtmlDecode(data);
using (var zip = ZipFile.Open(name + ".zip", ZipArchiveMode.Create))
using (var file = zip.CreateEntry(name).Open())
using (var writer = new StreamWriter(file, Encoding.UTF8))
writer.Write(data);
File.Move(name, name + ".bak");
}
_>Хы, товарищ наконец то созрел для организации своего стартапчика... Это позитивно, хотя офис у них конечно весёлый сейчас (http://pulumi.com/contact). Однако не пойму откуда ты взял, что это будет продолжением дела Midori. Я например после прочтения этого его сообщения и изучения их сайта по прежнему не имею ни малейшего представления об их идеях. Облака, ИИ и т.п. — это всё просто текущие относительно хайповые темы...
Он в своих статьях говорил, что мидори может работать на кластере. Те ОС живёт не на одной машине, а сразу на нескольких.
_>Опять же: в теории — конечно, а на практике — не видел пока ничего подобного. ) И да, я понимаю, что в данной темке обсуждается "альтернативная история", а не реальность. Но это тоже можно обсуждать по разному. К примеру есть определённые решения, эффективность которых уже проверена прямо сейчас и они пока не "захватили мир" только в силу различных "политических" и экономических причин. А вот твои предложения чаще всего имеют ещё и не проверенную на практике эффективность. При этом они мне чаще всего тоже нравятся, но я всегда хочу реальных примеров...
Почти все мои предложения как раз имеют прототипы в виде работающего кода.
Только описанное мной управление памятью не проверено на практике.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Pzz>>>У ARM'а всю жизнь был некогерентный кеш, что не мешало gcc на нем прекрасно работать.
CM>>Вот именно что был. Видимо, не осилили до конца.
Pzz>А я просто не знаю, какой он сейчас. Казалось бы, некогерентный кэш проявляет себя в двух случаях: когда имеется bus mastering (это проблема драйверов), и когда имеется SMP.
Pzz>Я имел дело с ARM'ом, когда SMP там еще не было. Как сейчас, я просто не в курсе.
И когерентные, и некогерентные решения есть. Это еще тот конструктор.
Здравствуйте, Sharov, Вы писали:
S>Я имел в виду , что типизация не бесплатна. И привело бы к усложнению ansi sql, которое бы пришлось обплясывать разным вендорам.
Практически бесплатна. Ровно на этом форуме несколько лет назад один участник упоминал, что они реализовывали своё типизированное подмножество SQL.
Ничего военного. S>Я же изначально говорил про sql (ansi) и его диалекты типа t-sql. Для своих задач он вполне годится, и минимальная типизация присутствует.
И так понятно, что всё то, что есть сейчас — "годится". Но вопрос же был не в этом, а в том, что можно улучшить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gardener, Вы писали:
Pzz>>Я имел дело с ARM'ом, когда SMP там еще не было. Как сейчас, я просто не в курсе.
G>И когерентные, и некогерентные решения есть. Это еще тот конструктор.
А бывают некогерентные, но при этом с SMP? Если да, как у них в user space программируют?
Здравствуйте, Pzz, Вы писали:
Pzz>А бывают некогерентные, но при этом с SMP? Если да, как у них в user space программируют?
Не знаю, как программируют они.
Но предложенная тут
Здравствуйте, Pzz, Вы писали:
Pzz>Всех, кто на них когда-либо писал — расстрелять. Pzz>Сведения о нем приравнять к государственной тайне. Тех, кто ее разглашает — расстрелять. Pzz>Призывы к использованию других ОС приравнять к оправданию терроризма. Оправдывающих терроризм — расстрелять. Pzz>И молча же выписываем постановление автора программы — расстрелять. Pzz>И наступит всеобщее счастье.
После грядущей мировой войны — с хакерами и робототехникой, примерно так и будет. И личные автомобили тоже запретят. Будете ездить на убере с автопилотом.
Здравствуйте, WolfHound, Вы писали:
_>>С Хаскелем двойственная ситуация. С одной стороны он весьма лаконичный (частенько даже лучше Питона), а с другой стоит хоть немного выйти за рамки парадигмы ФП (например банально захотеть мутабельную переменную), как начинается такой ад, в сравнение с которым PHP и VB начинают казаться замечательными языками. ))) WH>Зачем тебе изменяемая переменная в скрипте, написанном на хаскеле? WH>Изменяемые переменные нужны только для оптимизации.
Не только для оптимизации, но и для лаконичности кода. Например в одних ситуациях удобнее map, а в другой явный for (с используемой переменной для итерации).
_>>Да вроде очевидно объяснил же. Хотя и с кодом проблем нет: WH>
WH>foreach (var name in Directory.EnumerateFiles(".", "*.fb2"))
WH>{
WH> var data = File.ReadAllText(name, Encoding.UTF8);
WH> data = HttpUtility.HtmlDecode(data);
WH> using (var zip = ZipFile.Open(name + ".zip", ZipArchiveMode.Create))
WH> using (var file = zip.CreateEntry(name).Open())
WH> using (var writer = new StreamWriter(file, Encoding.UTF8))
WH> writer.Write(data);
WH> File.Move(name, name + ".bak");
WH>}
WH>
Открываю блокнот, сохраняю этот код как test.cs и запускаю его в командной строке — ничего не происходит. Так, ладно, ладно, это я пошутил (хотя на самом деле это было бы максимально честное сравнение) и всё же сделаем в начале запуск csc.exe для нашего кода. Только вот всё равно ничего не работает, говорит: " Программа не содержит статический метод "Main", подходящий для точки входа"...
_>>Хы, товарищ наконец то созрел для организации своего стартапчика... Это позитивно, хотя офис у них конечно весёлый сейчас (http://pulumi.com/contact). Однако не пойму откуда ты взял, что это будет продолжением дела Midori. Я например после прочтения этого его сообщения и изучения их сайта по прежнему не имею ни малейшего представления об их идеях. Облака, ИИ и т.п. — это всё просто текущие относительно хайповые темы... WH>Он в своих статьях говорил, что мидори может работать на кластере. Те ОС живёт не на одной машине, а сразу на нескольких.
Если это будет действительно так, то будет весьма интересно. Хотя вообще проблема кластеров — это несколько другая область, но тоже весьма интересная, а то доминирования MPI и Hadoop (каждого в своей специализации) уже несколько "наскучило". )))
Здравствуйте, Sinclair, Вы писали:
_>>Есть публичные примеры? ) S>Singularity.
Так там же у нас помнится было ограничение на язык типа safe C# — там понятно, что можно легко поделить память. А здесь мы уже обсуждаем полноценное промежуточное представление (типа того же LLVM IR).
Здравствуйте, alex_public, Вы писали:
_>Не только для оптимизации, но и для лаконичности кода. Например в одних ситуациях удобнее map, а в другой явный for (с используемой переменной для итерации).
Например?
_>Открываю блокнот, сохраняю этот код как test.cs и запускаю его в командной строке — ничего не происходит. Так, ладно, ладно, это я пошутил (хотя на самом деле это было бы максимально честное сравнение) и всё же сделаем в начале запуск csc.exe для нашего кода. Только вот всё равно ничего не работает, говорит: " Программа не содержит статический метод "Main", подходящий для точки входа"...
1)Вся обвязка генерируется ИДЕ. Все импорты тоже может делать ИДЕ.
2)Ничто не мешает сделать статически типизированный язык без этой обвязки.
Ну и в любом случае код получился примерно такой же. С точностью до организации API.
А если заменить IDisposible на уникальные типы и добавить немного сахара, то при той же организации API получим вот такой код.
foreach (var name in Directory.EnumerateFiles(".", "*.fb2"))
{
ZipFile
.Open(name + ".zip", ZipArchiveMode.Create)
.CreateEntry(name).Open().StreamWriter(Encoding.UTF8)
.Write(HttpUtility.HtmlDecode(File.ReadAllText(name, Encoding.UTF8)));
File.Move(name, name + ".bak");
}
Короче динамическая типизация не нужна.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали: _>Так там же у нас помнится было ограничение на язык типа safe C# — там понятно, что можно легко поделить память.
Нет, там язык типа MSIL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
_>>Не только для оптимизации, но и для лаконичности кода. Например в одних ситуациях удобнее map, а в другой явный for (с используемой переменной для итерации). WH>Например?
Так я же вроде указал пример — использование итерируемой переменной. Или тебе нужен совсем конкретный? Ну вот например распечатать список с нумерованием элементов. Думаю очевидный императивный код на том же Питоне не надо показывать? )
_>>Открываю блокнот, сохраняю этот код как test.cs и запускаю его в командной строке — ничего не происходит. Так, ладно, ладно, это я пошутил (хотя на самом деле это было бы максимально честное сравнение) и всё же сделаем в начале запуск csc.exe для нашего кода. Только вот всё равно ничего не работает, говорит: " Программа не содержит статический метод "Main", подходящий для точки входа"... WH>1)Вся обвязка генерируется ИДЕ. Все импорты тоже может делать ИДЕ.
IDE..., генерируется..., может делать... Короче в реальном мире никто это для скриптов использовать не будет.
WH>2)Ничто не мешает сделать статически типизированный язык без этой обвязки.
Да, и я даже знаю один такой язык. Называется Nim. Причём он включает в себя и питоноподобный синтаксис (с поправкой на статическую типизацию) и мощное метапрограммирование (в стиле макросов лиспа, только статическое) и даже высокую производительность (т.к. компилируется в C++). И кстати там есть даже возможность автоматического совмещения компиляции с запуском — казалось бы вот он идеал для скриптов.
Однако т.к. этот язык имеет очень маленькую популярность, то ни продвинутых инструментов, ни развитых родных библиотек у него нет. Так что на практике вышеприведённый пример с реальным полезным коротеньким скриптом на нём не записать (ну точнее в теории можно, после нескольких дней подключения соответствующих C/C++ библиотек и написания удобных обёрток к ним, но такое уж точно никому не нужно).
WH>Короче динамическая типизация не нужна.
В теории возможно. Но посмотри на реальный окружающий мир — нет ни единого языка со статической типизацией, подходящего под описанную простейшую задачу. И есть как минимум несколько подходящих динамических.
Здравствуйте, Sinclair, Вы писали:
_>>Так там же у нас помнится было ограничение на язык типа safe C# — там понятно, что можно легко поделить память. S>Нет, там язык типа MSIL.
Это ничем не отличается от моего утверждения (ну разве что позволяет написать ещё на других .net языках, но суть не меняет).
Здравствуйте, alex_public, Вы писали:
_>Так я же вроде указал пример — использование итерируемой переменной. Или тебе нужен совсем конкретный? Ну вот например распечатать список с нумерованием элементов.
Ты просто думаешь императивно. Именно поэтому я попросил пример.
main = print $ zip ["a", "b", "c"] [1..]
Выводит:
[("a",1),("b",2),("c",3)]
zip берёт два списка и возвращает список кортежей.
Первым параметром передаём список. Вторым передаём бесконечный список, состоящий из последовательных целых чисел.
_>Думаю очевидный императивный код на том же Питоне не надо показывать? )
Ты уверен, что будет короче, чем на хаскеле?
Короче если ты думаешь, что тебе нужна изменяемая переменная в хаскеле то ты либо занимаешь оптимизацией. Либо не знаешь, как писать на хаскеле.
_>IDE..., генерируется..., может делать... Короче в реальном мире никто это для скриптов использовать не будет.
Мы тут не по реальный мир говорим. А про то что можно сделать.
_>Однако т.к. этот язык имеет очень маленькую популярность, то ни продвинутых инструментов, ни развитых родных библиотек у него нет.
Нитру для того и делаем чтобы продвинуты инструменты получались бесплатно.
_>В теории возможно. Но посмотри на реальный окружающий мир — нет ни единого языка со статической типизацией, подходящего под описанную простейшую задачу. И есть как минимум несколько подходящих динамических.
Как минимум хаскель. На нём просто нужно писать, как на хаскеле, а не как на императивном языке.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Я тут ради интереса всё же решил глянуть детально и выяснил, что похоже тут
_>Однако т.к. этот язык имеет очень маленькую популярность, то ни продвинутых инструментов, ни развитых родных библиотек у него нет. Так что на практике вышеприведённый пример с реальным полезным коротеньким скриптом на нём не записать (ну точнее в теории можно, после нескольких дней подключения соответствующих C/C++ библиотек и написания удобных обёрток к ним, но такое уж точно никому не нужно).
я слегка ошибся. А именно: нужные библиотеки в Nim всё же есть. Правда в виде отдельные внешних модулей (к которым я кстати так и не нашёл документации, только исходники на github), но вроде как ставящихся при помощи встроенного менеджера пакетов. Так что ситуация с Nim похоже чуть лучше, чем я описал. Но всё же до Питона пока не дотягивает.
Здравствуйте, WolfHound, Вы писали:
_>>Так я же вроде указал пример — использование итерируемой переменной. Или тебе нужен совсем конкретный? Ну вот например распечатать список с нумерованием элементов. WH>Ты просто думаешь императивно. Именно поэтому я попросил пример. WH>
WH>main = print $ zip ["a", "b", "c"] [1..]
WH>
WH>Выводит: WH>
WH>[("a",1),("b",2),("c",3)]
WH>
WH>zip берёт два списка и возвращает список кортежей. WH>Первым параметром передаём список. Вторым передаём бесконечный список, состоящий из последовательных целых чисел.
Это вообще ни о том. Ты показал очевиднейшую вещь (которая кстати и в варианте на Питоне будет), но при этом опустил собственно основную часть кода. Никому не нужен вывод списка кортежей, а нужны правильно (в том смысле что должно быть место для произвольного форматирования) выведенные элементы списка под номерами. Точный питоновский аналог твоего кода выглядит так:
print list(enumerate(["a", "b", "c"], 1))
Как видишь, такая же длина, такой же результат и главное тоже отсутствуют какие-либо дополнительные переменные. Неудивительно, что такой вариант отлично ложится на Хаскель. А я изначально имел в виду (я же писал тебе про обязательное использование переменной итерации в императивном варианте) совсем другой код на Питоне:
for i, v in enumerate(["a", "b", "c"], 1): print i, v #тут естественно может быть сложнее
который выводит:
1 a
2 b
3 c
И да, естественно это тоже без проблем записывается на Хаскеле, но уже гораздо менее симпатично (всяческие монадные map'ы и прочая ересь).
_>>Думаю очевидный императивный код на том же Питоне не надо показывать? ) WH>Ты уверен, что будет короче, чем на хаскеле? WH>Короче если ты думаешь, что тебе нужна изменяемая переменная в хаскеле то ты либо занимаешь оптимизацией. Либо не знаешь, как писать на хаскеле.
Я знаю как надо писать на Хаскеле и мне это совсем не нравится во многих случаях.
_>>Однако т.к. этот язык имеет очень маленькую популярность, то ни продвинутых инструментов, ни развитых родных библиотек у него нет. WH>Нитру для того и делаем чтобы продвинуты инструменты получались бесплатно.
А ты этим ещё занимаешься? А то тут Влад в соседней темке вроде писал, что ты забросил этот проект и он типа один там теперь...
_>>В теории возможно. Но посмотри на реальный окружающий мир — нет ни единого языка со статической типизацией, подходящего под описанную простейшую задачу. И есть как минимум несколько подходящих динамических. WH>Как минимум хаскель. На нём просто нужно писать, как на хаскеле, а не как на императивном языке.
А для скриптов лучше как раз императивный язык. Вот Nim теоретически мог бы подойти, если бы стал популярным.
Здравствуйте, alex_public, Вы писали: _>Это ничем не отличается от моего утверждения (ну разве что позволяет написать ещё на других .net языках, но суть не меняет).
Непонятно, почему вы считаете MSIL или java bytecode принципиально отличающимися от LLVM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Непонятно, почему вы считаете MSIL или java bytecode принципиально отличающимися от LLVM.
Ну, то есть я понимаю, что LLVM IR не позволяет прикрутить к нему верификатор (https://news.ycombinator.com/item?id=3085057) лёгким манием руки.
Но пока что непонятно, что в нём есть такое хорошее, по сравнению с MSIL, что окупает отсутствие верификатора?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Непонятно, почему вы считаете MSIL или java bytecode принципиально отличающимися от LLVM. S>Ну, то есть я понимаю, что LLVM IR не позволяет прикрутить к нему верификатор (https://news.ycombinator.com/item?id=3085057) лёгким манием руки. S>Но пока что непонятно, что в нём есть такое хорошее, по сравнению с MSIL, что окупает отсутствие верификатора?
Ну это легко объяснить с помощью двух простейших риторических вопросов:
— Можно ли скомпилировать произвольный IL код в LLVM.
— Да. См. например IL2CPP от Unity.
— Можно ли скомпилировать произвольный LLVM код в IL.
— Нет. См. например варианты компиляции C++/CLI и то какой код они генерируют.
Теперь поясню почему это критически важно именно для обсуждаемой системы (с программным разделением процессов). Принципиальным нюансом системы с такой безопасностью является то, что абсолютно всё ПО обязано быть написано таким образом. Т.е. мы не можем взять и написать небольшую, критическую важную по быстродействию часть скажем на C, а остальное на языке компилируемом в IL — у нас абсолютно всё должно быть на IL (ну если конечно мы рассматриваем только такой верификатор, а не нечто гипотетическое, способное анализировать и ассемблер, как предлагал WolfHound). Так вот, пока я не увижу эффективных реализаций например кодека h.264 и т.п. на языке, компилируемом в IL, даже смешно обсуждать реальность подобной системы.
Кстати, если уж говорить о программной защите и верификации. В проекте WebAssembly очевидно (т.к. там произвольные модули загружаются из инета в адресное пространство браузера) столкнулись с той же проблемой. И выбрали решение в виде рантайм проверок. Т.е. инструкция обращения к произвольному адресу памяти (кстати, внутри WebAssembly практически повторяет LLVM IR) при исполнение компилируется не в соответствующую машинную инструкцию, а в некий специальный код, который проверяет адрес на допустимые модулю границы (в WebAssembly выделение идёт линейными кусками). Таким образом образуется программная песочница. А в остальном всё функционирует как обычный нативный код, компилируемый LLVM. Я тестировал получаемую производительность на как раз самом сложном для подобного примере (постоянное обращение к памяти) и получилось падение производительности приблизительно в 1,5-2 раза относительно аналогичного оптимизированного нативного кода (C++ gcc с максимальной оптимизацией) — в принципе не самый плохой результат (Java или C# на тех же примерах ведут себя гораздо хуже).
Здравствуйте, alex_public, Вы писали: _>Так вот, пока я не увижу эффективных реализаций например кодека h.264 и т.п. на языке, компилируемом в IL, даже смешно обсуждать реальность подобной системы.
А, ну ок. Вот оно — ядро сомнений.
_>Кстати, если уж говорить о программной защите и верификации. В проекте WebAssembly очевидно (т.к. там произвольные модули загружаются из инета в адресное пространство браузера) столкнулись с той же проблемой. И выбрали решение в виде рантайм проверок. Т.е. инструкция обращения к произвольному адресу памяти (кстати, внутри WebAssembly практически повторяет LLVM IR) при исполнение компилируется не в соответствующую машинную инструкцию, а в некий специальный код, который проверяет адрес на допустимые модулю границы (в WebAssembly выделение идёт линейными кусками). Таким образом образуется программная песочница. А в остальном всё функционирует как обычный нативный код, компилируемый LLVM. Я тестировал получаемую производительность на как раз самом сложном для подобного примере (постоянное обращение к памяти) и получилось падение производительности приблизительно в 1,5-2 раза относительно аналогичного оптимизированного нативного кода (C++ gcc с максимальной оптимизацией) — в принципе не самый плохой результат (Java или C# на тех же примерах ведут себя гораздо хуже).
Ну, то есть проседание на h.264 в полтора-два раза нас бы устроило.
А можно посмотреть на "неэффективную" реализацию h.264 на C#/Java?
Ну, просто чтобы понять, есть ли там простор для оптимизации, или уже всё вылизано, и без допиливания JIT мы никуда не уедем?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Кстати, если уж говорить о программной защите и верификации. В проекте WebAssembly очевидно (т.к. там произвольные модули загружаются из инета в адресное пространство браузера) столкнулись с той же проблемой. И выбрали решение в виде рантайм проверок. Т.е. инструкция обращения к произвольному адресу памяти (кстати, внутри WebAssembly практически повторяет LLVM IR) при исполнение компилируется не в соответствующую машинную инструкцию, а в некий специальный код, который проверяет адрес на допустимые модулю границы (в WebAssembly выделение идёт линейными кусками). Таким образом образуется программная песочница. А в остальном всё функционирует как обычный нативный код, компилируемый LLVM. Я тестировал получаемую производительность на как раз самом сложном для подобного примере (постоянное обращение к памяти) и получилось падение производительности приблизительно в 1,5-2 раза относительно аналогичного оптимизированного нативного кода (C++ gcc с максимальной оптимизацией) — в принципе не самый плохой результат (Java или C# на тех же примерах ведут себя гораздо хуже). S>Ну, то есть проседание на h.264 в полтора-два раза нас бы устроило.
Ну тут не всё так просто. С одной стороны в 2 раза — это конечно очень печально. А с другой мы тут обсуждали замену аппаратной защиты на программную, так что теоретически при реализации всей ОС на таких принципах (и выключение аппаратной защиты) часть потерь может компенсироваться.
), потому как пока не реализована эта штука https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md. И говоря "в два раза", я подразумевал сравнение с вариантом "C++ с отключённой векторизацией", а в реальности соответственно всё гораздо печальнеее пока. Однако т.к. данная возможность стоит у них в ближайших планах на реализацию, то думаю что скоро можно будет говорить о реальном "всего в 1,5-2 раза медленнее C++".
S>А можно посмотреть на "неэффективную" реализацию h.264 на C#/Java? S>Ну, просто чтобы понять, есть ли там простор для оптимизации, или уже всё вылизано, и без допиливания JIT мы никуда не уедем?
Например на http://jcodec.org есть всё нужное. Я сейчас уже точно не помню откуда, но при упоминание этой реализации у меня в голове всплывает "замечательная" цифра в 500 мс/кадр...
Здравствуйте, WolfHound, Вы писали:
WH>Всё что находится внутри requires, ensures и invariant работает исключительно на этапе компиляции и на результирующий код не влияет.
У формальной верификации есть одна небольшая, но очень противная особенность, из-за которой она и не получила должного распространения в настоящее время.
Для того, чтобы описать модель алгоритма сортировки, относительно которой будет верифицироваться его реализация, достаточно нескольких примитивно-рекурсивных функций. Однако же, в реальном мире, имеет место интерес к верификации, скажем, реализаций таких протоколов, как TLS или HTTP. Которые, для описания инвариантнов множества некоторых их состояний, потребуют использования частично-рекурсивных функций. То есть, для описания которых, потребуется полный по Тьюрингу язык.
И возникает справедливый вопрос: как в этом случае верифицировать корректность самой модели?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Для того, чтобы описать модель алгоритма сортировки, относительно которой будет верифицироваться его реализация, достаточно нескольких примитивно-рекурсивных функций.
Покажи в каком месте моего кода находится эта модель?
KV>Однако же, в реальном мире, имеет место интерес к верификации, скажем, реализаций таких протоколов, как TLS или HTTP. Которые, для описания инвариантнов множества некоторых их состояний, потребуют использования частично-рекурсивных функций. То есть, для описания которых, потребуется полный по Тьюрингу язык.
Я не знаю ничего про TLS, но HTTP это же почти регулярный язык.
Из того что там не регулярное:
1)Прочитать число и считать количество байт равное этому числу.
2)Прочитать строку и считать всё до того места где эта строка вновь встретится.
Или я про что-то забыл?
KV>И возникает справедливый вопрос: как в этом случае верифицировать корректность самой модели?
Вот предикаты, которым должны соответствовать все сортировки. Верифицировать их нужно глазами. Благо они очень простые.
//Предикат который утверждает что отрезок [begin..end) отсортирован.
predicate SortedRange(a : array<int>, begin : int, end : int)
requires a != null;
requires 0 <= begin <= end <= a.Length;
reads a;
{
forall i, j :: begin <= i < j < end ==> a[i] <= a[j]
}
//Предикат который утверждает что функция переставляет местами элементы массива [begin..end)
//и не меняет остальной массив
predicate PremutateRange(a : seq<int>, b : seq<int>, begin : int, end : int)
requires |a| == |b|;
requires 0 <= begin <= end <= |a|;
{
(forall i :: 0 <= i < begin && end <= i < |a| ==> a[i] == b[i]) &&
multiset(a[begin..end]) == multiset(b[begin..end]) &&
multiset(a) == multiset(b) &&
a[0..begin] == b[0..begin] && a[end..|a|] == b[end..|a|]
}
Ну и на практике нам нужно верифицировать не всё, а только некоторые свойства программы. Такие как не выход за приделы массива.
А эта задача легко решается добавлением простейшего предиката индексеру массива.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Ну и на практике нам нужно верифицировать не всё, а только некоторые свойства программы. Такие как не выход за приделы массива. WH>А эта задача легко решается добавлением простейшего предиката индексеру массива.
Да, тут уже многие неявно начинают подменять верификацию type safety (которая, в частности, и гарантирует уважение к разделению прав доступа между процессами) на доказательство формальной корректности.
Сейчас, с точки зрения meltdown, интереснее возможность автоматически детектировать малварь, которая пользуется артефактами кэширования.
Ну, то есть мы выполняем заведомо запрещённое чтение, и пользуемся тем, что branch predictor считает срабатывание guard-а на i<Length маловероятным. Поэтому он там в конвеере уже обратился а a[i] и даже прочёл sampledata[a[i]], и только потом вылетел с IndexOutOfRangeException.
В общем, нам страшен только тот код, который после этого занимается замером производительности доступа к sampledata[].
1. Можно ли предотвратить такое вообще при помощи формальных методов детектирования?
2. Если нет — то будет ли угроза велика? Т.е. может ли злонамеренный код извлечь пользу из прочитанных таким образом данных?
У нас же нет возможности фиксировать адреса — пёс его знает, где рантайм расположит наш массив a; и где относительно него будут расположены данные чужих процессов.
Или мы просто будем сканировать память в надежде найти что-то типа номера кредитки, зная характерный формат данных?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Сейчас, с точки зрения meltdown, интереснее возможность автоматически детектировать малварь, которая пользуется артефактами кэширования.
Проблема с атакой через побочный канал в том, что не понятно, как их формализовать.
И совсем не ясно что делать с атаками, о которых мы не знаем.
В принципе я могу себе представить возможность закрыть некоторые классы атак через побочный канал если создавать железо и компилятор, заточенные на это.
Но у таких систем будет относительно низкая производительность и относительно высокое энергопотребление.
S>1. Можно ли предотвратить такое вообще при помощи формальных методов детектирования?
Насчёт формальных методов не знаю.
Но я думаю можно загрубить таймер. Если таймер будет тикать в 10 раз медленнее чем промах кеша, то мы не сможем извлечь информацию через этот канал. И этого должно быть достаточно для работы со звуком и видео.
S>2. Если нет — то будет ли угроза велика? Т.е. может ли злонамеренный код извлечь пользу из прочитанных таким образом данных? S>У нас же нет возможности фиксировать адреса — пёс его знает, где рантайм расположит наш массив a; и где относительно него будут расположены данные чужих процессов.
Если мы будем размещать данные в случайном месте 64х битного адресного пространства, то крайне маловероятно что что-то можно будет найти.
S>Или мы просто будем сканировать память в надежде найти что-то типа номера кредитки, зная характерный формат данных?
Это возможно. Но весьма хлопотно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Покажи в каком месте моего кода находится эта модель?
Её и не должно быть в коде. Инварианты и пред-/пост-условия, используемые в рамках формальной верификации, всегда описывают свойства некоторой подразумеваемой эталонной модели предметной области, относительно которой осуществляется верификация. В простейших случаях, типа сортировки, в явном построении этой модели нет необходимости, т.к. её свойства формулируются интуитивно. Если же говорить о верификации реальных систем, то там без построения такой модели обойтись не получится. Например, для верификации компилятора какого-либо языка, необходимо формальное описание, как грамматики языка, так и его семантики: денотационной -- для верификации компилятора относительно матмодели языка, интерпретационной -- для верификации кодогенератора, трансформационной -- для верификации средств метапрограммирования или транскомпиляции и т.п. Всё это вместе и составляет первую часть той модели, о которой я говорил.
WH>Я не знаю ничего про TLS, но HTTP это же почти регулярный язык. WH>Из того что там не регулярное: WH>1)Прочитать число и считать количество байт равное этому числу.
И это уже делает HTTP контекстно-зависимым языком (см. https://pdfs.semanticscholar.org/7d95/6ddef192f3a10b22bc41044566be396c751f.pdf, п3.3), для разбора которого требуется LBA, суть -- машина Тьюринга с ограниченной памятью.
WH>Вот предикаты, которым должны соответствовать все сортировки. Верифицировать их нужно глазами. Благо они очень простые.
Они действительно простые, но только потому, что простыми в данном примере являются формулы определения отношения частичного порядка на множестве элементов, выступающие здесь в роли первой части упомянутой модели.
WH>//Предикат который утверждает что функция переставляет местами элементы массива [begin..end) WH>//и не меняет остальной массив
И вот тут мы приходим ко второй части модели. Если опираться на определение понятия алгоритма из теории формальных языков (т.е. что всякий алгоритм является распознавателем какого-либо формального языка), то первая часть лишь доказывает, что верифицируемый алгоритм распознаёт полное множество слов, принадлежащих некоторому языку. Но нам также надо ещё и доказать, что этот же алгоритм не распознаёт слова, принадлежащие дополнению данного языка. Дополнение КЗ-языка является КЗ-языком -> ещё одна МТ с ограниченной памятью, отсутствие которой нужно доказать. А доказать отсутствие чего-либо в общем случае "гораздо труднее", чем наличие
Опять-таки, в случае сортировки вполне достаточно сказать "алгоритм может переставлять элементы входного массива, как ему вздумается, лишь бы на выходе всегда был упорядоченный массив", опираясь на допущение, что сортировка -- не более чем цепочка последовательных перестановок элементов некоторого множества. А как быть, даже в таком относительно простом случае, как, к примеру, режимы блочного шифрования с обратной связью, где каждый последующий блок шифротекста является результатом нетривиальных операций между промежуточным блоком и всеми или некоторыми предыдущими?
Для верификации криптографии, кстати, на практике используются специально заточенные под эту задачу DSL'и. Такие, как https://github.com/GaloisInc/cryptol, например. Просто потому, что описать даже примитивные криптоалгоритмы традиционными средствами верификации невероятно тяжело. И это при том, что за любым таким алгоритмом стоит совершенно строгая формальная модель. Что касается прочих классов уязвимостей, то частичные модели на данный момент, построены только для инъекций, некоторых подклассов атак повреждения памяти и гонок за ресурсами. Для всех остальных классов моделей нет, а значит и нет возможности верифицировать код на предмет их отсутствия.
WH>Ну и на практике нам нужно верифицировать не всё, а только некоторые свойства программы. Такие как не выход за приделы массива.
Уязвимость -- есть множество достижимых состояний приложения (конфигураций в терминологии Тьюринга), в которых для любого информационного потока нарушается любое из свойств защищённости (в общепринятой модели угроз это -- конфиденциальность, доступность, целостность, авторизованность и аутентичность). Для того, чтобы доказать безопасность приложения средствами частичной формальной верификации (т.е. когда верифицируется не всё), мы должны помимо всего прочего ещё и доказать, что верификация покрывает всё множество таких состояний. Не буду утверждать, что это неразрешимая проблема (хотя, IMO, так оно и есть), но вот то, что известных способов её решения на данный момент не существует -- совершенно точно.
Кстати, если найдётся время, могу порекомендовать доклад с нашей прошлой конфы на тему формальной верификации: https://www.youtube.com/watch?v=gKEOzRm7aaw&feature=youtu.be Денис занимается верификацией компонентов ядра Linux в ИСП РАН для сами-догадаетесь-какого дистрибутива и с предметной областью знаком не понаслышке. Во второй части доклада как раз рассматриваются основные проблемы и ограничения формальной верификации (как связанных именно со спецификой С-кода, так и в общем).
Я тут говорил про верификацию safety. Ты же расширил тему на верификацию вообще всего. И ещё security притянул о которой речи вообще не шло.
При этом нужно всегда помнить, что без safety о security разговор можно даже не начинать.
И safety сама по себе является очень полезной штукой даже без security.
KV>Её и не должно быть в коде. ... Всё это вместе и составляет первую часть той модели, о которой я говорил.
К счастью для того о чём говорю я это всё не нужно.
KV>И это уже делает HTTP контекстно-зависимым языком (см. https://pdfs.semanticscholar.org/7d95/6ddef192f3a10b22bc41044566be396c751f.pdf, п3.3), для разбора которого требуется LBA, суть -- машина Тьюринга с ограниченной памятью.
Как это мешает верифицировать две простейшие функции?
Тут же всё намного проще чем сортировка.
KV>Они действительно простые, но только потому, что простыми в данном примере являются формулы определения отношения частичного порядка на множестве элементов, выступающие здесь в роли первой части упомянутой модели.
Даже оставаясь в рамках простых случаев мы можем получить очень много плюшек.
Например, если мы знаем, что сортировка всегда работает корректно то мы можем использовать это свойство для доказательства других свойств.
KV>Для верификации криптографии, кстати, на практике используются специально заточенные под эту задачу DSL'и. Такие, как https://github.com/GaloisInc/cryptol, например. Просто потому, что описать даже примитивные криптоалгоритмы традиционными средствами верификации невероятно тяжело.
Я посмотрел по диагонали. Но ничего необычного кроме манипуляции последовательностями бит там не увидел.
Прямая поддержка этой фичи действительно сильно упрощает жизнь. Причём не только верификатору, но разработчикам алгоритмов. И потенциально из этого описания можно генерировать очень быстрый код.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>В принципе я могу себе представить возможность закрыть некоторые классы атак через побочный канал если создавать железо и компилятор, заточенные на это. WH>Но у таких систем будет относительно низкая производительность и относительно высокое энергопотребление.
Не, это не интересно. S>>1. Можно ли предотвратить такое вообще при помощи формальных методов детектирования? WH>Насчёт формальных методов не знаю. WH>Но я думаю можно загрубить таймер.
Ну, как вариант. Но тоже — микроскопом по яйцам. Хочется чего-то гламурненького, хотя нутром чую, что невозможно это.
Скорее придётся отказаться от адресной арифметики вообще. Или как-то ещё гарантировать, что мы в принципе никогда не исполняем код типа
if(i<=a.Len)
throw;
s+=a[i];// на самом деле к моменту throw операция уже выполнена и исказила кэш.
Варианты, которые я вижу:
переписать guard как-то так:
div ebx
test eax, eax
jnz out_of_range_handler
mov eax, myArray[edx] // в случае выхода за пределы мы сюда не попадём; но даже спекулятивный исполнитель полезет в адреса в пределах разрешённого нам блока
Да, это немношк удорожает проверки; но надо стремиться к устранению таких проверок на уровне JIT, чтобы в большинстве мест косвенный доступ был статически проверен. WH>Если мы будем размещать данные в случайном месте 64х битного адресного пространства, то крайне маловероятно что что-то можно будет найти.
Ну вот как раз интересно — в той же Singularity есть ли какая-то доля статически размещённых данных?
Опасна ли она? Ну, то есть можно ли при её чтении пройти по цепочке — типа "в нулевой странице у нас всегда лежит ядро верификатора, в первой — код джита, в 56 у нас обычно попадает головная страница сессии ОС, а в ней по смещению 408 лежит указатель на структуру user, в которой восьмое поле — это ссылка на пароль в UTF-8"
S>>Или мы просто будем сканировать память в надежде найти что-то типа номера кредитки, зная характерный формат данных? WH>Это возможно. Но весьма хлопотно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>В принципе я могу себе представить возможность закрыть некоторые классы атак через побочный канал если создавать железо и компилятор, заточенные на это. WH>>Но у таких систем будет относительно низкая производительность и относительно высокое энергопотребление. S>Не, это не интересно.
А как по мне весьма интересно.
Если сделать специализированный крипточип который выполняет все команды за одинаковое время, все команды потребляют одинаковое количество энергии и компилятор доказал, что функция всегда выполняет одно и то же количество команд вне зависимости от данных.
То атаки через измерение времени исполнения и измерение потребления энергии отпадут.
Разумеется, этот чип будет исполнять исключительно криптографию.
Причём после того как мы получим симметричный сессионный ключ алгоритм шифрования канала передачи данных можно исполнять уже на обычном железе.
S>Ну, как вариант. Но тоже — микроскопом по яйцам. Хочется чего-то гламурненького, хотя нутром чую, что невозможно это.
Можно наконец начать доказывать процессоры.
Чтобы такое не повторилось.
Правда может найтись неожиданный вектор атаки через побочный канал.
S>Скорее придётся отказаться от адресной арифметики вообще.
Это невозможно. Её можно без потерь убрать из прикладного кода, но на уровне реализации без неё никуда.
S>Варианты, которые я вижу: S>
S> переписать guard как-то так: S>
S> div ebx
S> test eax, eax
S> jnz out_of_range_handler
S> mov eax, myArray[edx] // в случае выхода за пределы мы сюда не попадём; но даже спекулятивный исполнитель полезет в адреса в пределах разрешённого нам блока
S>
S>S>Да, это немношк удорожает проверки; но надо стремиться к устранению таких проверок на уровне JIT, чтобы в большинстве мест косвенный доступ был статически проверен.
Я ничего не понял. Как это поможет исправить проблему с meltdown?
S>Ну вот как раз интересно — в той же Singularity есть ли какая-то доля статически размещённых данных?
Не знаю.
Но ничего не мешает при загрузке системы размещать данные по случайному адресу.
После чего обнулять загрузчик.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Я ничего не понял. Как это поможет исправить проблему с meltdown?
Основная идея — предотвратить попадание в конвеер кода, который обращается по невалидному указателю.
Как у нас выглядит meltdown?
Главный код — это обращение по адресу, который получается из разыменования злого указателя:
Он построен на том, что разыменование указателя и чтение по нему выполняются до того, как будет проверена доступность страницы по *badPtr и брошено исключение.
После этого мы типа спокойно проверяем скорости доступа к разным частям userspace_array[].
В управляемой верифицируемой платформе понятия "указатель" нету, мы не можем разыменовать 0xBAADF00D.
Но есть массивы и ссылки.
Поэтому можно запилить аналог meltdown:
int i = 0xBAADFOOD;
var myData = new char[1];
var tmp = myData[i]; //выходим далеко за пределы массиваchar not_used = userspace_array[tmp * 4096];
Ну, такой код не пройдёт ни компиляцию, ни верификацию — нам придётся пошаманить с i, чтобы компилятор думал, что есть хотя бы шанс уложиться внутрь myData.
Тогда верификатор потребует воткнуть проверку:
int i = 0xBAADFOOD;
...//Запутываем компилятор с верификаторомvar myData = new char[1];
if(i>myData.Length) throw new IndexOutOfRangeException(); // без этой проверки верификатор не пропустит следующую строкуvar tmp = myData[i]; //выходим далеко за пределы массиваchar not_used = userspace_array[tmp * 4096];
Здесь у нас утечка ровно потому, что branch prediction успеет прочитать в not_used ещё до того, как выполнится проверка (чтобы гарантировать это, придётся написать чуть больше кода, но там ничего сложного нет).
То есть, в конвеере есть код, который прибавляет к myData значение, которое больше его длины.
Если мы заменим банальное сравнение на вычисление остатка, то уязвимость исчезнет:
int i = 0xBAADFOOD;
...//Запутываем компилятор с верификаторомvar myData = new char[1];
if(i>myData.Length) // без этой проверки верификатор не пропустит следующую строкуthrow new IndexOutOfRangeException();
else
i = i % myData.Length // на позитивном пути мы принудительно ограничиваем индексvar tmp = myData[i]; //выходим далеко за пределы массиваchar not_used = userspace_array[tmp * 4096];
Всё. В таком коде в конвеере никогда нет чтений за пределами массива, даже если i "пытается" за них выйти. Собсно, всё вшивается в реализацию джитом инструкции ldelem. Устранение избыточных проверок возлагаем на jit.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Pzz>А бывают некогерентные, но при этом с SMP? Если да, как у них в user space программируют?
Я не уверен здесь в терминологии. Просто несколько идентичных процессоров с собственными некогерентными кешами? Такое бывает. Например в SoC с которым сейчас работаю. Только там нет user-space. Программировать неудобно, и используется такая схема вынужденно — те процессоры которые влазят в бюджет по транзисторам не имеют когерентного кеша.
У нас это отдельные фирмваре, собирающиеся из обших исходников, общающиеся через память и железные фифо, в принципе очень похоже на общение разные процессов в нормальной ОС.
Здравствуйте, gardener, Вы писали:
G>Я не уверен здесь в терминологии. Просто несколько идентичных процессоров с собственными некогерентными кешами? Такое бывает. Например в SoC с которым сейчас работаю. Только там нет user-space. Программировать неудобно, и используется такая схема вынужденно — те процессоры которые влазят в бюджет по транзисторам не имеют когерентного кеша.
Я интересуюсь потому, что традиционные поточные API (напр., POSIX threads, C++ threads) просто не содержат необходимых операций, чтобы программировать компутер с некогерентным кэшом. Там не предусмотрено способа сказать процессору "сбрось кэш в таком-то месте" или "перечитай из памяти в таком-то месте".
Ну и соответственно, даже если это операции добавить в виде нестандартных расширений, то чужую библиотеку, если захочется ей воспользоваться, все равно придется перелопачивать, она к такой жизни будет не готова.
Поэтому мне любопытно, если такое чудо существует, интересно, как люди на нем живут.
В ядре или на самодельной железке с собственной средой программирования такой проблемы нет, потому что и операции нужные, скорее всего, предусмотрены, и legacy кода нет.
Pzz>В ядре или на самодельной железке с собственной средой программирования такой проблемы нет, потому что и операции нужные, скорее всего, предусмотрены, и legacy кода нет.
Достаточно просто должно быть запустить на разных процессорах отдельные экземпляры ОС (тот же Linux) и отдельные процессы. Общаться между собой наверное всеми механизмами, которые подразумевают обмен сообщениями (пайпс например). Общую память тоже не сложно сделать — mmap() требует MMU — здесь маппинг будет некешируемый. Модификация какая-то в кернеле потребуется само собой, но не очень много.
Потом например в Linux был (может и сейчас есть) сacheflush() system call, я его когда-то на MIPS использовал.
Насчет отдельных экземпляров. Если не путаю в MQX RTOS есть такая возможность. Экземпляры, обмен сообщениями.
N>Не-а. Он и за прошедшие 20 лет не решил эти проблемы, и не решил бы их и тогда. N>Проблемы Itanium в том, что EPIC не работает с современной памятью и кэшами в мультипроцессорной системе.
Здравствуйте, gardener, Вы писали:
N>>Не-а. Он и за прошедшие 20 лет не решил эти проблемы, и не решил бы их и тогда. N>>Проблемы Itanium в том, что EPIC не работает с современной памятью и кэшами в мультипроцессорной системе.
G>А можно больше деталей?
Можно.
Пусть у вас последовательность команд. Какая-то часть из них кодирует операции только с регистрами — считаем, они доступны всегда, и на чтение и на запись. Какая-то обращается к памяти. Вот тут начинаются проблемы. Если у вас обыкновенная DRAM, у неё самая длительная операция это закрыть неактуальную строку (переписать из её кэша, который в самой микросхеме DRAM, в собственно DRAM-часть) и открыть заказанную (прочитать и переписать в тот кэш на борту DRAM). Эта операция занимает, согласно вики на DDR4, минимум 37.5 нс. (DDR3 и выше — в таймингах типа 10-10-10 сложить все 3 числа и подсчитать в тактах в clock rate (не путать с data rate).) В более бюджетных — и выше. Умножьте это на частоту процессора в гигагерцах и получите количество его тактов, сколько он ждёт. А ещё надо добавить время на опознание, что данных нет ни в одном локальном кэше (обычно добавляется где-то до 30 тактов), нет ни у одного партнёра по SMP (может быть и ~50 тактов) и на чтение полной строки (64 байта на x86) из DRAM (ну, ещё десятка два тактов, там высокая параллельность) — спокойно можно добрать и до 300 тактов.
Это чрезвычайно высокая цифра, даже если сравнивать с супердорогими арифметическими операциями типа целочисленного деления (128/64 на x86, считается, до 90 тактов).
Теперь представим себе исполнение этих команд команд. На x86 вполне может быть, что пока 30-я по счёту только-только прочиталась из памяти, 25-я раскодирована, 20-й назначили все внутренние регистры и она ждёт выполнения, 15-я выполняется, 10-я закончила и результаты готовы, но ждёт, пока предыдущие завершат операции, результат 7-й сидит во write queue на выходе в кэш, для 5-й заканчивают синхронизацию между кэшами в SMP, 1-я наконец всё типа закончила (слила результат в кэш в строку, которая эксклюзивно принадлежит на запись текущему ядру). В это время 2-я задумчиво занимается делением, и её результаты будут ещё тактов через 40. Но она (2-я) пишет в регистр, поэтому не тормозит заметную остальных; её результаты будут применены только к 15-й команде, а результаты той — только к 24-й, поэтому с остальными можно работать. Я не преувеличиваю в цифрах — у Skylake, например, цепочка от "наконец заканчиваем, фиксируем результаты" до "выбрали, начинаем декодировать" может быть до 224 микроопераций.
Процессор сам вычисляет, какая команда от какой зависит. Есть очевидные зависимости по регистрам (типа, если 3-я записала в eax, а 5-я его читает, 5-я должна выполняться после 3-й). Есть зависимости по памяти (x86 настаивает на том, что все операции записи в память упорядочены по этим действиям записи — хотя вычисления в них не требуют такой зависимости). Получается такой себе DAG (направленный ациклический граф) исполнений, внутри которого заметная свобода.
А теперь чем отличается EPIC? Само название поясняет: Explicitly parallel instruction computing. Параллельность рассчитана на этапе написания машинного кода (обычно — компилятором). Причём не в терминах "данная команда хочет результаты той, что на 15 раньше по цепочке" — такое бы требовало слишком много места для записи — а в виде группировок типа "данные команды друг на друга не влияют" (см. ниже), "можно параллелить сколько угодно по вкусу" и "а вот тут мы знаем явную зависимость, надо завершить все предыдущие до всех последующих". В доке по Itanium это выглядит так:
>> An instruction group is a sequence of instructions starting at a given bundle address and slot number and including all instructions at sequentially increasing slot numbers and bundle addresses up to the first stop, taken branch, Break Instruction fault due to a break.b, or Illegal Operation fault due to a Reserved or Reserved if PR[qp] is one encoding in the B-type opcode space. For the instructions in an instruction group to have well-defined behavior, they must meet the ordering and dependency requirements described below.
и вот главные слова — "must meet the ordering and dependency requirements". Автору машкода надо явно определить группы, в которых взаимовлияние минимизировано, и зафиксировать их. Дальше в доке много страшных слов, но вот одни из ключевых:
>> Between instruction groups, every instruction in a given instruction group will behave as though its read occurred after the update of all the instructions from the previous instruction group.
Процессор не имеет права посчитать, что какая-то команда из IG1 может быть выполнена одновременно с какой-то последующей IG2, если между ними стоит явный stop. Даже прочесть данные из памяти в регистр — потому что это называется update of architectural state. Память тормозит? Жди.
>> Within an instruction group, every instruction will behave as though its read of the register state occurred before the update of the register state by any instruction (prior or later) in that instruction group, except as noted in the Register dependencies and Memory dependencies described below.
[...] >> Register dependencies: Within an instruction group, read-after-write (RAW) and write-after-write (WAW) register dependencies are not allowed (except пара незначительных исключений)
А это, наоборот, в одной группе не может быть зависимостей (как уже сказал — надо отбирать только независимые действия). Хотел исхитриться и применить результаты чтения сразу же? Обломись, бабка, мы на корабле.
Дальше в доке много чего — 100500 поправок, уточнений и исключений, словно специально, чтобы запутать всех и усложнить компилятор до предела. Но смысл основной тот же: пока на тех архитектурах, где процессор вычисляет зависимости на ходу (как x86), одна команда не тормозит соседних "товарок", пока её результаты не нужны, и может быть выделена из основного потока — на IA-64 такой свободы нет, учись предсказывать задержки по памяти — то, чего в принципе предсказать невозможно на обычном современном железе (если вы не занимаетесь Meltdownʼом).
Резонный вопрос — а почему вообще Intel решил, что возможно такую архитектуру сделать эффективной? А вот тут надо заглянуть в историю и заметить, что тогда же его топ-менеджмент попался на две удочки одновременно — первая под названием Rambus, а вторая — NetBurst (Pentium 4 должен был по тем планам стать последним x86). Супербыстрая DRAM плюс ориентация на потоковые SIMD действия (для "мультимедиа") и пренебрежение всеми остальными классами задач. Чем тут поможет SIMD? А именно тем, что для основных задач хорошо предсказывается необходимость подчитать память — можно заранее (на одну-две IG) сказать prefetch на нужный кусок, пока выполняются предыдущие, оно уже в L1. Но тут наступил облом — не стала мультимедия единственным использованием компьютера, а Rambus мало того, что выпустила память с бо́льшими задержками, так и оказалось, что все новомодные усовершенствования это фикция, а заодно патентный буллинг (Intel потеряла ок. 4e8$$, насколько помню).
Так что EPIC эффективен только там, где вы можете строго ограничить время одной даже самой длительной команды. Видимо, из подобных соображений Intel исключил из IA-64 простое целочисленное деление — он знал, что это долго, но "не знал" того же про чтение DRAM. Если у вас SRAM (умножьте цену памяти на 10-20) — ok, вперёд. Если у вас DSP (тоже, считаем, SRAM) — тоже пойдёт, туда подобные архитектуры внедрились и устоялись. Но для "обычного" современного компа, для толстого сервера — ой, зась.
И вслед этому очевидный вопрос про "импортозаместительный" Эльбрус-4. На синтетических тестах он много чего показывает, но про реальные задачи идёт много подпольных отзывов про жуткие тормоза...
Здравствуйте, gardener, Вы писали:
G>Достаточно просто должно быть запустить на разных процессорах отдельные экземпляры ОС (тот же Linux) и отдельные процессы. Общаться между собой наверное всеми механизмами, которые подразумевают обмен сообщениями (пайпс например). Общую память тоже не сложно сделать — mmap() требует MMU — здесь маппинг будет некешируемый. Модификация какая-то в кернеле потребуется само собой, но не очень много.
Я не про имплементацию, а про семантику.
Понятно, что если не позволять нитям одного процесса расползаться по ядрам, то проблема сильно поуменьшится. Но не до конца, потому что есть еще shared memory. Делать ее некешируемой — это аццкие тормоза. Да и процессу не давать расползаться по ядрам тоже несколько обидно.
G>Насчет отдельных экземпляров. Если не путаю в MQX RTOS есть такая возможность. Экземпляры, обмен сообщениями.
MQX не связана обязательствами быть совместимой с традиционным API.
Маленький вопрос по write queue. Я так понимаю это то же самое что встречается в других архитектурах под именем write buffer. Но он должен по идее находиться между кешем и внешней шиной, и буферизует все записи, как кешируемые так и некешируемые (в случае ARM например его использрвание настраивается как тип памяти в MMU или MPU).
Можно ли грубо резюмировать что проблема с EPIC что в статике не получается так хорошо распараллелить инструкции как это делает в динамике out-of-order процессор. И причины — группировка инструкций не очень гибкая, предсказать внешние задержки в статике нереально в обычной системе.
И потом поскольку DDR latency очень высока глубина out-of-order должна быть тоже высока, и она недостижима в этих примерах VLIW?
DDR latency и производительность — мне сейчас очень интересна эта тема.
Есть несколько достаточно простых in-order RISC процессоров. Система занимается обработкой сетевых пакетов. Эти процессоры организую своего рода pipeline.
В результате многих оптимизаций пришли к резултату когда bolleneck СPU тратит ~1.6K тактов на пакет, 1.5 тактов на инструкцию, ~570 инструкций на пакет, ~750 тактов это pipeline stall на внешней шине.
ICache miss почти ноль (1-2 в среднем на пакет), DDR latency в зависимости от нагрузки 50-70 тактов.
Внутреннее состояние в tighly coupled memory, т.е. гарантированно очень быстро, как из обычного кеша.
Нужна еще большая производительность.
Оптимизировать код? Осталось всего 570 инструкций — буду пытаться, но шансов уже немного.
Уменьшать задержки с внешней памятью? 47% времени тратится на это. Скорее всего сюда надо смотреть.
DDR bandwidth похоже хватает с головой (жду результаты от ASIC team с тестами на FPGA), но практически уверен по косвенным данным.
Т.е. надо смотреть на DDR latency и уменьшать CPU stalls из-за этого. Процессор in-order, поэтому делать надо explicitly. Prefetch инструкций нет. Есть tightly coupled DMA, доступ к его регистрам близок, есть двухпортовая tightly coupled data memory. Пока вижу вариант делать prefetch с помощью этого DMA с целью спрятать DDR latency. Других возможностей пока не вижу.
Здравствуйте, gardener, Вы писали:
G>Вау, это была целая лекция
G>Маленький вопрос по write queue. Я так понимаю это то же самое что встречается в других архитектурах под именем write buffer. Но он должен по идее находиться между кешем и внешней шиной, и буферизует все записи, как кешируемые так и некешируемые (в случае ARM например его использрвание настраивается как тип памяти в MMU или MPU).
Нет, я имел в виду другое — между исполнительным механизмом и кэшами. О нём редко говорят, но, например, у Криса Касперски в "Техника оптимизации программ. Эффективное использование памяти" хорошо описано его поведение и влияние (на примере P3, P4, так что всё надо пересчитывать на новые процессоры, но основной принцип должен был остаться).
G>Можно ли грубо резюмировать что проблема с EPIC что в статике не получается так хорошо распараллелить инструкции как это делает в динамике out-of-order процессор. И причины — группировка инструкций не очень гибкая, предсказать внешние задержки в статике нереально в обычной системе.
Именно.
G>И потом поскольку DDR latency очень высока глубина out-of-order должна быть тоже высока,
Да. Уже говорил — в последних Intel оно более 200, и аналогичное говорили про топовые ARM.
G> и она недостижима в этих примерах VLIW?
Здравствуйте, s_aa, Вы писали:
_>Сделал бы так, чтобы все языки на момент создания поддерживали только русский язык. Проснулись бы американцы, ан кругом Пока() Если () Для (пер ё = 0; ё < массив.длина; ё++).
Попробуй просто писать на русском языке.
"Пока" и "Если" можешь не руссифицировать.
Гораздо прикольнее называть по-русски имена переменных и функций.
Сначала будет ломка, похожая на наркотическую, зато потом...
A>Гораздо прикольнее называть по-русски имена переменных и функций. A>Сначала будет ломка, похожая на наркотическую, зато потом...
Да я пробовал, нет никакой ломки. Полезно если алгоритм трудный для понимания. Названия функция и переменных типа "ПроверитьНаличиеКарты(ТипКартаПациента карта)" помогает. Недостатки — необходимость переключаться постоянно рус/лат и трудности при интеграции с языками где это не поддерживается.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во-первых, архитектуру x86/x64 предложили бы переделать все, тут сомнения нет, нечего обсуждать.А какую именно нужно — на эту тему и без того обсуждений немало PD>Во-вторых, я не вполне согласен с тезисом. Линукс где только не работает, и появись новый процессор -будет и на нем работать. Windows тоже PD>А все, что выше ОС — так это совсем слабо от процессора зависит
Сорри, малость не согласен насчёт слабой зависимости от архитектуры проца.
На сегодня симметричная система организации мультипроцессорности пока выигрывает, хотя потенциал маштабирования в ней никакой.
На уровне одного кристалла еще хоть как-то масштабируется, на уровне отдельных кристаллов — уже на порядок хуже.
Соответственно, АПИ современных ОС сильно завязаны на это SMP.
Стандарты мейнстримовых языков тоже покрывают лишь SMP.
А всё что вправо-влево — это даже непонятно как окучивать.
А ведь в своё время было и железо и языки и соотв.операционки, для реализации произвольной масштабируемости в отсутствии симметричности доступа к памяти. Т.е., рано или поздно (ИМХО, уже скоро), эту область придётся переизобретать заново.
По-сути, сегодня выгодней поставить один кристалл на 16 ядер, чем 4 кристалла по 4 ядра.
В итоге, эра настоящей мультизадачности началась намного позже, чем могла бы начаться.
Потому что всё упирается в ПО.
Уже имеющееся ПО был относительно легко допилить до SMP-сценариев.
А так-то, если представить, что параллельным вычислениям уделяется достаточное внимание всю дорогу, т.е. наличествуют и языки и операционки, то мощные многопроцессорные компы сугубо юзверского уровня (на относительно дешевых процах) можно было бы собирать еще в 90-е.
Но увы, увы. ))
Те многопроцессорные системы были крайне дороги из-за специфического внешнего контроллера когерентной памяти.
И каждый проц должен уметь общаться с такими контроллерами.
Т.е., там круги по воде пошли слишком далеко, сделав направление многопроцессорных машин неадекватной по стоимости.
Что в итоге еще больше замедлило направление в этой области и т.д. и т.п.
Здравствуйте, WolfHound, Вы писали:
WH>Либо в клиническом случае пользователи качают патч на эту программу и всё. WH>Ты кстати в курсе что винда молча при запуске исправляет некоторые популярные программы чтобы они работали.
Вернее, подставляет им ожидаемые от АПИ баги или недокументированные эффекты.
==============
Не пробовал на виндах до Висты изменить текущий фокус на другое окно прямо во время оповещения о получении окном фокуса и вернуть признак "всё ок"? Очень забавные получались иногда фишки — курсор находится в одном окне EDIT, выделение происходит в этом же окне, а буквы набираются в другое окно.
Т.е. на все экземпляры EDIT в текущем потоке у них был единственный "редактор", которому не всегда корректно выставляли оперируемое окно (зависело от того, в какой последовательности обрабатывать WM_FOCUS — вызывать сначала предыдущую оконную процедуру до сабклассинга, или сначала делать некие свои действия, а потом вызывать предыдущую процедуру).
Здравствуйте, WolfHound, Вы писали:
S>>1. Можно ли предотвратить такое вообще при помощи формальных методов детектирования? WH>Насчёт формальных методов не знаю. WH>Но я думаю можно загрубить таймер. Если таймер будет тикать в 10 раз медленнее чем промах кеша, то мы не сможем извлечь информацию через этот канал. И этого должно быть достаточно для работы со звуком и видео.
Это невозможно в общем случае. Потому как банальный код вида:
for(int i=0; ; i++) if(stop){
result=i;
break;
}
уже даст "счётчик времени" с точностью в десятки раз лучше, чем время обращения к оперативной памяти (отсутствие которого по сути и обнаруживают во всех этих уязвимостях).
Здравствуйте, alex_public, Вы писали:
_>уже даст "счётчик времени" с точностью в десятки раз лучше, чем время обращения к оперативной памяти (отсутствие которого по сути и обнаруживают во всех этих уязвимостях).
И как ты собираешься его использовать?
Твой поток висит на получении данных и ничего не делает.
Чтобы этот трюк сработал нужен таймер, который работает параллельно твоему потоку. В нативе это не проблема ибо есть rdtsc.
А что можно сделать в управляемой системе без разделяемой памяти я не знаю.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
Pzz>Я интересуюсь потому, что традиционные поточные API (напр., POSIX threads, C++ threads) просто не содержат необходимых операций, чтобы программировать компутер с некогерентным кэшом.
Согласен.
Но готовые решения есть в более раннем POSIX.
Например, QNX поддерживает старый POSIX, который, как и сама эта операционка, рассчитан на нессиметричную модель памяти.
Процессы в такой модели размножаются через обычный fork, где через флаги задаётся требуемый уровень шаринга памяти.
Если шаринг памяти м/у двумя экземплярами после форка не требуется, то новый процесс можно отправить на другой узел.
Если требуется, то получается что-то вроде "потоков" внутри одного узла.
Балансировщик нагрузки может перемещать независимые процессы или зависимую группу их м/у узлами.
Кароч, всё уже было изобретено, но забыто за ненадобностью в последние лет 20.
Теперь опять надо.
Pzz>Ну и соответственно, даже если это операции добавить в виде нестандартных расширений
Зачем нестандартных? ))
Классика жанра — пайпы.
После форка независимые по памяти процессы общаются через них, родимых.
В той же QNX общаются просто чудесно, виндовые пайпы работали заметно медленней на той же технике.
Pzz>то чужую библиотеку, если захочется ей воспользоваться, все равно придется перелопачивать, она к такой жизни будет не готова.
ХЗ.
Практически весь легаси гнутый код всегда был готов, бо сразу же писался универсальным образом, чтобы работать не только на SMP.
Pzz>Поэтому мне любопытно, если такое чудо существует, интересно, как люди на нем живут.
На QNX жили прекрасно.
Да и не только QNX, просто я когда-то в конце 90-х плотно щупал QNX4.
Не смотря на скудную графику (в сравнении с виндами), сама она была просто бомба.
А так-то все "большие" UNIX по состоянию на ~20 лет назад были построены сверху несимметричной схемы.
Потому что не могло быть никакой симметричной схемы на, допустим, 128-ми процессорной машинке.
Pzz>В ядре или на самодельной железке с собственной средой программирования такой проблемы нет, потому что и операции нужные, скорее всего, предусмотрены, и legacy кода нет.
Легаси код есть. Полный набор классических юниксовых утилит в наличии.
Здравствуйте, Pzz, Вы писали:
Pzz>Понятно, что если не позволять нитям одного процесса расползаться по ядрам, то проблема сильно поуменьшится. Но не до конца, потому что есть еще shared memory. Делать ее некешируемой — это аццкие тормоза. Да и процессу не давать расползаться по ядрам тоже несколько обидно.
Не по ядрам, а по узлам, где каждый узел — обычный SMP.
Поэтому, вовсе не обидно.
На сегодня "узлом" может быть отдельный кристалл многоядерного проца.
? А почему сразу нельзя?
)
