Здравствуйте, 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>Я хочу идти в правильном направлении, но я не уверен, что это направление правильное.
Я считаю что да.

Здравствуйте, Pzz, Вы писали:

Pzz>И чем тебе фаирвол-то поможет, если ты выводишь сервис наружу?

Какая-никакая, а защита. Выше же написал -- простейшая защита от вкрипткидис. А как быть если кто-то сеть сканирует, уже можно насторожиться.

Здравствуйте, lpd, Вы писали:

lpd>В таком случае были бы патенты на эти технологии. Я ничего не слышал. Можно одну ссылку на что-то действительно полезное,
lpd>чего нет в популярных современных процессорах?
На какие технологии? Которые никто не разрабатывает, потому что их невозможно монетизировать?
lpd>В Windows отсутствие софта действительно проблема. У Debian же есть порт и для Itanium. Пакетов поддерживается много — 9 dvd.
В винде проблема как раз наличие софта. Его много и его жалко — в том смысле, что никто не станет брать платформу, где не работает его XXXXX.
lpd>Перевести пользователей на новую архитектуру, конечно, трудно. Однако, софт не выглядит основной причиной этого. Высокоуровневые языки программирования(С++) и без того достаточно портабельные.
Именно софт и именно выглядит.

Здравствуйте, alex_public, Вы писали:

_>Так я как бы вполне одобряю идею распространения байткода (ну естественно не такого как в .net, а скорее такого как llvm, но это не суть). Только вот с фактом и возможностью верификации подобное распространение ПО никак не связано. И вот как раз на счёт возможности такой верификации у меня есть сомнения. Правда так сказать теоретические (сам я как-то ни одного подобного верификатора пока не писал).
Не очень понял, в чём именно сомнения. "Такая верификация" вполне себе встроена во вполне себе реально существующие системы.

Здравствуйте, Sharov, Вы писали:
S>Как это поможет в случае когда я умножил на 2, а надо было на 5?Если ошибся с условием запроса и выбрал не то?
Никак. И программу за вас он не напишет.
А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится.
Да как нефиг делать. Вы посмотрите на таблицу implicit преобразований в T-SQL.

Здравствуйте, Sinclair, Вы писали:


S>>Как это поможет в случае когда я умножил на 2, а надо было на 5?Если ошибся с условием запроса и выбрал не то?
S>Никак. И программу за вас он не напишет.

А кастыдей из-за типизации там где не надо понаставит.

S>>А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится.
S>Да как нефиг делать. Вы посмотрите на таблицу implicit преобразований в T-SQL.

Я про ansi 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 лечится, если проверка прав происходит (в железе) то запуска загрузки в кэш. Это простой и ясный критерий, который легко можно реализовать в железе. А вот при софтверной проверке даже непонятно, что делать.

Здравствуйте, netch80, Вы писали:

N>Но я вот очень задумчиво себе представляю AOT компиляцию какой-нибудь новой мозиллы при её установке

Знаешь, если ты поиграешься с golang, то ты поймешь, что компилятор может быть быстрым.

Насколько я понимаю, у go линкер делает примерно то, что здесь предлагают делать при установке.

Здравствуйте, Pzz, Вы писали:

Pzz>У ARM'а всю жизнь был некогерентный кеш, что не мешало gcc на нем прекрасно работать.

Вот именно что был. Видимо, не осилили до конца.

Здравствуйте, 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 построил экосистему разработки так, что простые пацаны смогли зарабатывать на этой платформе. И сразу — мотивация, конкуренция, совершенствование, прогресс.
А если я завтра выпущу свою бесплатную ОС, рассчитанную на бесплатный софт, то в неё тупо не пойдут разработчики, т.к. им за это не платят. А, следовательно, не пойдут и пользователи, потому что там нет софта.
Ну и всё — проблема решена; аудитории нет, проект закрыт.