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 мс/кадр...
Так, ладно, ладно, это я пошутил (хотя на самом деле это было бы максимально честное сравнение) и всё же сделаем в начале запуск csc.exe для нашего кода. Только вот всё равно ничего не работает, говорит: " Программа не содержит статический метод "Main", подходящий для точки входа"... 
