Здравствуйте, 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, и ещё кучи всего. В итоге у нас шансы отдать ответ из кэша становятся близки к нулю, а шансы отдать его быстро — вообще нулевыми.
Зачем мы будем портить хорошую вещь?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
? А почему сразу нельзя?
