Не было, примерно никогда.
Была (и как-бы осталась) некая пародия на POSIX в духе "назло бабушке".
--
Если внимательно посмотреть на дизайн компонентов ядра NT, то будет очевидно как несколько раз уши отмораживали назло POSIX-бабушке: управление виртуальной памятью, процессы и треды, файловая система...
Изначально самой приличной вещью в NT-ядре был IRP-стек (т.е. схема построения и взаимодействия). Но в конце 90-х его переусложнили и превратили в кошмар (управление питанием для bus-драйверов и т.п.). А когда втащили win32sys в ядро — настал вообще ад.
Собственно все проблемы WSL1 от ядра NT — в сравнении с Linux как медленно, так и просто не работает. Причем без возможности исправить.
--
Аргументы автора статьи местами не соответствуют действительности, а где-то он явно лукавит. M$ уже многократно (раз десять?) кидала разработчиков закрывая какие-то API, платформы и программы. И сколько помню с совместимостью всегда укачивало (усилия прикладываются, включая симуляцию багов, но всегда что-то отваливалось).
В целом, мне не совсем понятна мотивация убеждать всех в том, что WSL — это не Windows Subsystem for Linux, а LSW (Linux Subsystem for Windows), чем на самом деле пока являются WSL1 и WSL2.
Реализовать системные вызовы Linux поверх ядра NT примерно невозможно/нерационально (очень много нужно переделать), а вот наоборот в разы проще (включая Native API и Win32). Но тут важно не раздувать проблемы, вовремя отбрасывая лишнее. Например, масса windows-драйверов (NDIS, USB) может работать без переделки.
Скрестить Linux и Windows на уровне общего гипервизора конечно проще, но все же я не думаю что в перспективе M$ этим ограничится.
Причастные к Э, подскажите в lcc есть настройки pgo?
Да, конечно.
Опции управления режимом компиляции:
[...]
-frename-statics Добавить имя файла к именам статических переменных и
функций
-pg Генерировать код программы для получения профиля для
дальнейшего его использования программой gprof
-fprofile-arcs Создавать в процессе компиляции файлы с информацией о дугах
для программы gcov
-ftest-coverage Создавать в процессе компиляции файлы с информацией о
базовых блоках для программы gcov
--coverage Эквивалентно комбинации опций -fprofile-arcs,
-ftest-coverage
Опции профилирования:
-fprofile-use[=<file>]
Загрузить данные профилирования из файла <file> (по
умолчанию eprof.sum)
-fprofile-generate[=<path>]
Генерировать код программы для получения профиля в каталоге
<path> (по умолчанию в текущем каталоге)
-fprofile-generate-parallel[=<path>]
Генерировать код программы, использующей распараллеливание
для получения профиля в каталоге <path> (по умолчанию в
текущем каталоге)
-fprofile-generate-kernel
Генерировать код программы для получения профиля в при
сборке ядра
-fprofile-kernel-generate
Устаревший дубликат опции -fprofile-generate-kernel
-fprofile-subst=<old_module_name1>:<new_module_name1>,...
Заменить имя считанного из профиля файла <old_module_name>
на указанное имя <new_module_name>
-fprofile-strict-names
Выдать ошибку при отсутствии в профиле информации для
файла, поданного в командной строке
-fprofile-values Включить режим профилирования значений переменных
-fprofile-skip-proc=<proc1,proc2,...>
Данные процедуры не будут инструментироваться, профиль для
них не будет загружаться
-fprofile-skip-module=<module1,module2,...>
Данные модули не будут инструментироваться, профиль для них
не будет загружаться
Хм, вообще-то как-раз таки завезли, особенно в lcc 1.25
Но причина относительной толерантности (например) штеуд-ядер к "ветвистому" коду в очень неплохом предсказателе переходов и спекулятивном выполнении. И как только в Эльбрусах появится сравнимый по эффективности предсказатель ситуация принципиально изменится.
Что привнес 16C в этой области или планируется в ближайшее время не в курсе, но область эта очень не простая, в том числа, как потому что легко "наломать дров" (повторить spectre-дыры), так и потому что "всё что можно" уже запатентовано в максимально широких формулировках.
В том виде как сейчас — не было. Но в предыдущем комментарии ошибка в другом — хотя и многопоточных приложений тогда еще не было, то засыпал именно процесс, а не процессор.
Линус распинался не о том что fail-fast плох или вреден, а что неприемлем переход на fail-fast "задним числом", когда под раздачу попадают ничего непонимающие детипользователи.
Реализация glibc избавлена от сравнений и условных переходов, в том числе изначально рассчитана на инлайнинг. Её примерно всегда дешевле заинлайнить чем вызвать, как по объему кода, так и по скорости.
В целом довольно наивно/глупо писать статью со словами "галиматья", "дурацкая херня" и т.п. (это я про автора, а переводчику респект) не понимая и 1/10 причин "зачем и почему" так сделано. А голосование довольно хорошо показывает "среднюю по больнице" квалификацию голосующих.
Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в perf kvm stat будут EXTERNAL_INTERRUPT.
Трафик между двумя VM неплохо разруливал-бы 1Hippeus, но в 2014 его посчитали ненужным (включая массу простых и разумных предложений по всяким mailboxes для VM<->HV и VM<->VM, и т.п.).
Тем не менее, если без "бы", то для коммуникаций VM->VM все равно потребуется дешевый и безопасный (не ломающий гипервизор) wake из VM. Пока у меня нет сведений о каких-либо подвижках в железе для акселерации этих моментов (Штеуд погряз в spectre и тех-процессе, другие сюда пока не смотрят).
Соответственно, без такого wake придется дергать гипервизор, в лучшем случаи с учетом порогов/гистерезисов. Но пока (вроде-бы, не знаю) никто не считает это проблемой заслуживающей переделки кодовой базы (virtio и т.д.). Поэтому vSwitch (сам-по-себе он не плох) и разумные страданья за виртуализацию.
Т.е. мне более-менее понятно что и как следует делать (собственно могу), но не понятно кто и как все это организует/возглавит/оплатит. По ощущениям (имею право быть не правым) Штеуд скатывается в некукопожатные по темам касающимся API/BAPI и взаимодействия (ибо "решето"). MIPS — ищут куда продать куки (им не до концептов), ARM (вот на покупателя), RISCV (сильно разрозненно). Может быть у наших в МЦСТ дойдут руки, если их не отшибут "эффективные менеджеры" и давление диванных хейтеров.
— факт №1: Сначала Трам (ради выборов и хайпа?) заявил что создание вакцины будет очередным великим достижением Америки.
— факт №2: Затем Вектор сделал вакцину, которая безопасна и работает, поэтому провел её регистрацию по российским нормам.
— факт №3: После этого Факт №2 был озвучен на совещании...
Что тут неверного или "неоднозначного" в интервью?
Раз оба президента высказались про «первую в мире вакцину»
Один сказал "гоп" не прыгнув, другой озвучил факт.
А с чего вы взяли что распределение должно быть равномерным (если вы говорите о возможности/вероятности "случайного совпадения значений для 9 участников при наличии 12 точек") ?
Или что ряд 800, 1600, 3200, 6400 не релевантен наблюдаемым величинам?
Для чего в вашем понимании нужны данные по интервалам до 800, после 6400 или более точная шкала между?
Не было, примерно никогда.
Была (и как-бы осталась) некая пародия на POSIX в духе "назло бабушке".
--
Если внимательно посмотреть на дизайн компонентов ядра NT, то будет очевидно как несколько раз уши отмораживали назло POSIX-бабушке: управление виртуальной памятью, процессы и треды, файловая система...
Изначально самой приличной вещью в NT-ядре был IRP-стек (т.е. схема построения и взаимодействия). Но в конце 90-х его переусложнили и превратили в кошмар (управление питанием для bus-драйверов и т.п.). А когда втащили win32sys в ядро — настал вообще ад.
Собственно все проблемы WSL1 от ядра NT — в сравнении с Linux как медленно, так и просто не работает. Причем без возможности исправить.
--
Аргументы автора статьи местами не соответствуют действительности, а где-то он явно лукавит. M$ уже многократно (раз десять?) кидала разработчиков закрывая какие-то API, платформы и программы. И сколько помню с совместимостью всегда укачивало (усилия прикладываются, включая симуляцию багов, но всегда что-то отваливалось).
В целом, мне не совсем понятна мотивация убеждать всех в том, что WSL — это не Windows Subsystem for Linux, а LSW (Linux Subsystem for Windows), чем на самом деле пока являются WSL1 и WSL2.
Реализовать системные вызовы Linux поверх ядра NT примерно невозможно/нерационально (очень много нужно переделать), а вот наоборот в разы проще (включая Native API и Win32). Но тут важно не раздувать проблемы, вовремя отбрасывая лишнее. Например, масса windows-драйверов (NDIS, USB) может работать без переделки.
Скрестить Linux и Windows на уровне общего гипервизора конечно проще, но все же я не думаю что в перспективе M$ этим ограничится.
Ох, молодец "богомол".
Теперь самое сложно пройти "медные трубы", не оглохнув и не потеряв цель.
Удачи!
Пока "вся суть" в том, что вы применяете эпитеты не зная темы.
Сразу виден подход специалиста ;)
Если серьезно, то "мозгов" там ровно столько, сколько вложить.
VLIW тут отличается несколько ином методом их укладки.
Да, конечно.
Хм, вообще-то как-раз таки завезли, особенно в lcc 1.25
Но причина относительной толерантности (например) штеуд-ядер к "ветвистому" коду в очень неплохом предсказателе переходов и спекулятивном выполнении. И как только в Эльбрусах появится сравнимый по эффективности предсказатель ситуация принципиально изменится.
Что привнес 16C в этой области или планируется в ближайшее время не в курсе, но область эта очень не простая, в том числа, как потому что легко "наломать дров" (повторить spectre-дыры), так и потому что "всё что можно" уже запатентовано в максимально широких формулировках.
Лучше сразу апгрейт на Gentoo или Arch ;)
В том виде как сейчас — не было. Но в предыдущем комментарии ошибка в другом — хотя и многопоточных приложений тогда еще не было, то засыпал именно процесс, а не процессор.
Была "виндовс" tickless, а стала "совсем tickless" — теперь никто не знает как она тикает ;)
Линус распинался не о том что fail-fast плох или вреден, а что неприемлем переход на fail-fast "задним числом", когда под раздачу попадают ничего непонимающие
детипользователи.Так вы считаете что от assert-ов следует вообще отказаться по обозначенным "причинам"?
В glibc недостает assert-а, который-бы контролировал допустимость аргумента.
У меня даже стойкое дежавю, что лет 10 назад я то-ли субиметл такой патч, то-ли добавлял assert в заголовки на сборочной ферме.
Реализация glibc избавлена от сравнений и условных переходов, в том числе изначально рассчитана на инлайнинг. Её примерно всегда дешевле заинлайнить чем вызвать, как по объему кода, так и по скорости.
В целом довольно наивно/глупо писать статью со словами "галиматья", "дурацкая херня" и т.п. (это я про автора, а переводчику респект) не понимая и 1/10 причин "зачем и почему" так сделано. А голосование довольно хорошо показывает "среднюю по больнице" квалификацию голосующих.
+100500
С тестами всё нормально. Все упомянутые "навороты" в glibc, в том числе, для скорости.
Трафик между двумя VM неплохо разруливал-бы 1Hippeus, но в 2014 его посчитали ненужным (включая массу простых и разумных предложений по всяким mailboxes для VM<->HV и VM<->VM, и т.п.).
Тем не менее, если без "бы", то для коммуникаций VM->VM все равно потребуется дешевый и безопасный (не ломающий гипервизор) wake из VM. Пока у меня нет сведений о каких-либо подвижках в железе для акселерации этих моментов (Штеуд погряз в spectre и тех-процессе, другие сюда пока не смотрят).
Соответственно, без такого wake придется дергать гипервизор, в лучшем случаи с учетом порогов/гистерезисов. Но пока (вроде-бы, не знаю) никто не считает это проблемой заслуживающей переделки кодовой базы (virtio и т.д.). Поэтому vSwitch (сам-по-себе он не плох) и разумные страданья за виртуализацию.
Т.е. мне более-менее понятно что и как следует делать (собственно могу), но не понятно кто и как все это организует/возглавит/оплатит. По ощущениям (имею право быть не правым) Штеуд скатывается в некукопожатные по темам касающимся API/BAPI и взаимодействия (ибо "решето"). MIPS — ищут куда продать куки (им не до концептов), ARM (вот на покупателя), RISCV (сильно разрозненно). Может быть у наших в МЦСТ дойдут руки, если их не отшибут "эффективные менеджеры" и давление диванных хейтеров.
Пожелаю авторам/волонтерам википедии стремиться к объективности непредвзятости, и т.д. и т.п.
Тем не менее, в моём варианте реальности/мультивселенной гонка закончена ~месяц назад.
Ох, ну скажем так: тот вариант реальности/мультивселенной, в котором нахожусь я, мне нравится больше.
— факт №1: Сначала Трам (ради выборов и хайпа?) заявил что создание вакцины будет очередным великим достижением Америки.
— факт №2: Затем Вектор сделал вакцину, которая безопасна и работает, поэтому провел её регистрацию по российским нормам.
— факт №3: После этого Факт №2 был озвучен на совещании...
Что тут неверного или "неоднозначного" в интервью?
Один сказал "гоп" не прыгнув, другой озвучил факт.
А разве "гонка" не закончилась месяц назад?
А с чего вы взяли что распределение должно быть равномерным (если вы говорите о возможности/вероятности "случайного совпадения значений для 9 участников при наличии 12 точек") ?
Или что ряд 800, 1600, 3200, 6400 не релевантен наблюдаемым величинам?
Для чего в вашем понимании нужны данные по интервалам до 800, после 6400 или более точная шкала между?