Комментарии 80
Написать не «WSL1 в 13 раз тормознее WSL2», а несколько иначе. На тех же фактах.
Как принято сравнивать winapp@wine@Linux > winapp@Windows на одной и той же машине.
Вот так было бы честнее.
А пока это «быстрее в 13 раз» — акробатика с фактами.
Практически всю работу по поддержке ELF и транслированию вызовов и просто выбросили и воткнули немного допиленное ядро линукса в виртуалку в HyperV, сделав интерфейсы уже к ней.
В посте отсутствует ответ на вопрос из заголовка.
Дело в том, что запись на диск и системные вызовы Linux обходились достаточно дорого (с точки зрения временных затрат) из-за архитектуры первой версии WSL.
Ну и почему они обходились достаточно дорого? Что конкретно не так с архитектурой WSL1? Что делает трансляцию системных вызовов дорогой? Лично для меня совершенно контринтуитивно, что виртуальная машина должна по какой-то причине работать быстрее чем вайн наоборот. У меня такое чувство, будто в WSL1 просто наговнокодили.
А что, вайн работает со скоростью натуральной винды?
Субъективно, всяко быстрее винды в виртуалке (впрочем, сравнение не совсем честное)
А при чём тут виртуалка?
Вы пост-то читали? WSL2 это виртуалка, вот при чём.
Это слой совместимости.
Но «поручили файловые операции сетевому диску VHD» (со слов автора).
И нет — виртуальный сетевой диск != виртуальная машина.
WSL2 — это именно виртуалка с линуксом:
WSL 2 использует последнюю и самую новую технологию виртуализации для запуска ядра Linux внутри упрощенной служебной виртуальной машины.
Основное отличие лишь в том, что эта виртуалка хорошо интегрирована с виндой.
Ключевое — «упрощенной» и «Ядро Linux в WSL 2 создано собственными силами на основе».
То есть уже не Linux, но еще не Windows. Или наоборот.
И если потери производительности Windows-приложений в Linux (в виртуальной Windows или под Wine) довольно хорошо известны (речь о единицах процентов), то как работает эта
PS. чисто по-женски интересно — какая религия запрещает эффективным манагерам Microsoft сделать нормальный транслятор вызовов абсолютно открытой OS?
Команде Wine не мешает почти полная закрытость Windows — даже
… и не очень хорошо с собственно Linux'ом.
Ключевое — «упрощенной» и «Ядро Linux в WSL 2 создано собственными силами на основе».
Опять таки вы путаете подход использованный при создании WSL1 и WSL2.
То что вы пишете это именно про WSL1, где действительно кастомное ядро Linux, в котором системные вызовы Linux пробрасываются/транслируются в системные вызовы Windows. Из-за чего в WSL1 получилось много проблем с совместимостью и целый список не работающих фич и софта.
PS. чисто по-женски интересно — какая религия запрещает эффективным манагерам Microsoft сделать нормальный транслятор вызовов абсолютно открытой OS?
Но в Microsoft поняли, что так не пойдёт (трансляцией) и решили переделать всё с нуля используя свою технологию виртуализации Hyper-V (поддерживает аппаратную виртуализацию на базе Intel VT либо AMD SVM). Т.е. WSL2 это уже полноценный образ Linux. Назвали всё это WSL2.
Чисто технически у WSL1 и WSL2 задача одна, а реализация разная. Новая реализация очевидно сильно лучше. Складывается вопрос почему раньше так не сделали, а пошли более жёстким, больным путём.
Чисто теоретически если бы это был не Microsoft вместо Hyper-V мог бы быть и KVM и XEN.
Я бы сказал от части криворукость и легаси. Windows 10 это ядро Windows 7 с навешенными брокерами функционала Windows 8 (только того, который решили оставить).
Вместо «мы устали топтаться по своим граблям, поэтому по-быстрому слепила из того, что было» пишут «применили экстремально новейшие технологии».
А вместо «теперь WSL тормозит только в 3 раза относительно нативного Linux, а не в 40, как раньше» пишут «ускорилось в 13 раз».
Ализар отдыхает.
"Чисто технически" вся ядра NT принципиально не умеют две вещи:
- уменьшение размера файла меньше за-mmap-ленного размера (неустранимый баг №902);
- уведомительную (advisory) блокировку файлов (неустранимый баг №1927);
Теоретически M$ конечно могут это "починить" (сделали же clone/fork), но отказались (видимо) из-за трудоемкости и бесперспективности (всё выходило в разы медленнее чем в Linux).
Ну и пока не работает на хостах с AMD
WSL2 — это не виртуалка.
Это слой совместимости.
Это вы путаете как раз с WSL1, который по сути и был слоем совместимости (подмена системных вызовов Linux системными вызовами Windows).
А вот WSL2 это именно виртуалка в Hyper-V. С рядом настроек для проброса и шаринга.
WSL2 — это какбывиртуалка.
Хотя исходной целью был просто слой совместимости.
Именно, точнее она чуть шире чем просто слой совместимости, тут скорее экосистема для разработки. Вот только в WSL1 этот слой был очень корявый и не совместимый как выяснилось.
В WSL2 это виртуалка, в которую ставится дополнительно связующий софт (именно слой совместимости между Windows и Linux). Стоит ещё отметить что дистрибутивы операционок в Microsoft Store распространяются и поддерживаются разработчиками этих операционок. Так например Ubuntu это облачный образ с настройками для лучшей работы именно в Hyper-V.
P.S. Я этим уже пользуюсь пол года и мне нравится реализация именно WSL2. Microsoft так же оставили возможность выбора режима WSL1 или WSL2 как по умолчанию для новых дистрибутивов, так и выбор конкретному дистрибутиву. И ещё пока есть проблема в WSL2, на уровне организации виртуальной сети (пока не умеет в IPv6, с января имеется тикет на решение, но появится это решение скорее всего через несколько релизов после Майского).
Если бы… Не операционОК, а операционКИ. 1 шт.
(ну 1.5, если с Kali Linux).
Я вот не увидел как просто взять и поставить кентос. Не надо оптимизировано — просто хоть как-то.
А никак.
Если бы… Не операционОК, а операционКИ. 1 шт.
Почему же, вот открыл Microsoft Store и что я вижу:
- Ubuntu (Canonical Group Limited)
- Ubuntu 18.04 (Canonical Group Limited)
- Ubuntu 20.04 (Canonical Group Limited)
- openSUSE-Leap-15-1 (SUSE)
- SUSE Linux Enterprise Server 15 SP1 (SUSE)
- SUSE Linux Enterprise Server 12 SP5 (SUSE)
- Kali Linux (Kali Linux)
- Debian (The Debian project)
Раньше ешё были Fedora официальные, но сейчас их нет.
Остальные/Кастомы:
- Alpine (agowa338)
- Pengwin (Whitewater Foundry, Ltd. Co.)
- Fedora Remix for WSL (Whitewater Foundry, Ltd. Co.)
- Pengwin Enterprise (Whitewater Foundry, Ltd. Co.)
А ещё можно и самому создавать из tar с командой wsl:
--import <Distro> <InstallLocation> <FileName> [Options]
Импорт указанного TAR-файла в качестве нового дистрибутива.
В качестве имени стандартного выходного файла можно указать "-".
Параметры:
--version <Version>
Указание версии, которую нужно использовать для нового дистрибутива.Я пост читал, если что, и отвечал относительно 1й версии, которая транслирует вызовы, прямо как вайн, но от «криворуких» из МС.
Если приложение нормально написано, то разницы нет или нечувствительно.
А многие вещи работают даже быстрее.
Ну и почему они обходились достаточно дорого? Что конкретно не так с архитектурой
WSL1? Что делает трансляцию системных вызовов дорогой?
Возможно сами файловые операции обходились слишком дорого по сравнению с Linux.
Например, мне известно приложение (грубо говоря распаковщик архивов) которое изначально разрабатывалось на Linux, а потом было перенесено на Windows и там работало в несколько раз медленнее. И это исправили, барабанная дробь, пулом потоков для вызова CloseHandle. Потому что антивирус как раз в этот момент подключался в работу, а разработчики не ожидали что операция "закрыть дескриптор файла" может быть медленной и соответственно программа была не рассчитана на "зависание" в этой точке и ждала "закрытия файла" хотя могла бы читать следующий файл из архива использовать ЦПУ для "разжатия" и т.п.
И конечно в чем смысл транслятора системных вызовов если каждое приложение под него нужно адаптировать,
проще запустить в вирт. машине и игнорировать антивирусы.
Вы просто перефразировали процитированный мной фрагмент. Ну так почему эти накладные расходы оказались больше накладных расходов на виртуальную машину? На то же хранение файлов в виртуалке тоже неизбежно будут какие-то накладные расходы, виртуальные диски всё равно на тот же NTFS кладутся в итоге.
Плюс давно уже виртуалки не уступают в производительности хосту, потому что по сути работают просто рядом с хостовой системой, которая также управляется Hyper-V гипервизром.
Тут где-то в комментариях рассказывали, что тормозят в основном файлы.
Если в виртуалке обычный виртуальный диск с каким-нибудь ext4, то он будет храниться в виде файла на реальном NTFS-диске, а значит будет как минимум два вызова: сперва запись ext4 в виртуалке, потом запись этого ext4 на NTFS, а если диск динамического размера, то добавятся накладные расходы на управление этой динамикой, плюс фрагментацию ФС на хосте никто не отменял.
Если же паравиртуализация, какой-то специальный драйвер ФС или типа того, то это опять же трансляция обращений к драйверу в какие-нибудь вызовы на стороне хоста.
Так что я всё равно не понимаю, почему трансляция системных вызовов должна быть медленнее виртуальной машины.
У меня такое чувство, будто в WSL1 просто наговнокодили.
Не в WSL1, а несколько раньше.
И не "наговнокодили", а скорее не решились устранять недостатки дизайна.
Многие вещи в ядре NT начинались с отличного дизайна и были заимплеменчены достаточно хорошо, но некоторые были буквально "назло бабушке уши отморожу": процессы и треды, 1/3 инфраструктуры виртуальной памяти, файловая система — там адовы накладные расходы. Потом дополнительно добавили ведро дёгтя (win32sys), а ради мифа совместимости не стали упрощать IRP-стек.
В результате имеем то что имеем — WSL1 работает со скоростью нативных системных вызовов Windows 10 (затраты на трансляцию там погоды не делают), а WSL2 почти догоняет нативное ядро Linux.
Поэтому вместо сопоставления WSL1/WSL2 корректнее сформулировать "При некоторой усредненно-взвешенной оценке ядро Windows 10 выполняет системные вызовы в 13 раз медленнее Linux" — и это действительно так.
Чисто теоретически, возможно ли грузить WSL2 со службами автоматически при запуске системы, иметь доступ по SSH и к иксам по VNC извне?
Это актуальная информация для тех, кто хотел перейти на ОС Windows, но никак не решался.
Хех забавно, обычно переходят в другую сторону
Windows ведь может быть запущена, как под их родным гипервизором HyperV, так и под VirtualBox, QEMU, KVM, VmWare и т.д.
Запустится ли WSL2 под «вторым» слоем виртуализации (nested virtualization), или работоспособной будет только 1ая версия WSL, или версия 2, но только под HyperV с включённой опцией вложенной виртуализации (которую, например хостер может не захотеть включать для вашей… виртуальной машины)
Ну это просто ограничение, задаваемое выбором того что у MS имеется — hyper-v.
С другой стороны, при наличии любой другой VM, WSL2 уже не становится особо нужным — единственная удобная вещь это интеграция, хотя как правило нужен лишь доступ к файлам из хоста в линукс, а это просто делается самбой.
Что же касается тормознутости WSL1 — если добавить его в исключения для антивирусов (включая Defender) — всё очень даже шустро становится. Не без глюков конечно но всё же далеко не как черепаха.
Что позволит одновременно пользоваться как и виртуалками на базе hyper-v (WSL2 + эмуляторы android, в моем случае), так и одновременно крутить виртуалки на базе vmware.
Вообще интересно как это произошло. Огромный отдел работал над интеграцией линукса в винду с общей файловой системой и системными вызовами и вдруг пришел какой-то румяный менеджер, скачал из инета виртуалку, и не прогадал ведь — в результате у разных субьектов из статей на глазах скупые слезы счастья.
P. S. Раньше на WSL1 у меня был баш доступен и весь линукс прямо на винде, было может не супер быстро но я особо не замечал, собирал огромные штуки собирал типа всяких бустов. Сейчас это почти невозможно сделать без копирования на виртуальный диск, все тормозит просто неимоверно Лучше бы померили во сколько раз медленнее стало на ntfs, а не во сколько раз быстрее на ext4.
WSL1 для работы с NTFS, он никуда не уходит и останется доступным, а WSL2 для работы с виртуальным диском. Да, сделали неудобно, и возможно в документации нужно было точнее объяснить что для чего.
Вы ошибаетесь
Посмотреть список установленных систем и версий wsl:
wsl --list --verboseСменить версию для какой-то конкретной (например Ubuntu-20.04):
wsl --set-version Ubuntu-20.04 2Для запуска другой версии:
wsl -d Ubuntu-20.04Что произойдет с подсистемой WSL 1? Будет ли прекращена ее поддержка?
В настоящее время не планируется объявлять подсистему WSL 1 нерекомендуемой. Вы можете запускать дистрибутивы WSL 1 и WSL 2 параллельно, обновлять их и переходить на более раннюю версию дистрибутива в любое время. Добавление WSL 2 в качестве новой архитектуры для команды WSL представляет собой лучшую платформу, которая предоставляет отличные возможности для запуска среды Linux в Windows.
Может потому что Вы конвертируете один и тот же образ между WSL1 и WSL2 а не исопльзуете отдельные дистрибутивы?
WSL2/ext4: 9 секунд i.imgur.com/hdZPNbc.jpg
WSL2/ntfs: 14 МИНУТ (в 93 раза медленней) i.imgur.com/5r97IVU.jpg
WSL1: 33 секунды i.imgur.com/2j2m2yU.jpg
Issue с бенчмарками github.com/microsoft/WSL/issues/4197 (без сборки, просто блоками в dd, даже сетевой диск получается в 3 раза быстрее ntfs.
Микрософт напишет, конечно, «вы просто не держите файлы так», но у меня на рабочем ссд разделе нет места под целый дополнительный линукс, там придется резервировать дополнительно гигов десять наверное и перетаскивать туда все проекты.
Upd: да, для запуска баша вместо wsl --setdefault NAME && bash можно использовать и wsl -d NAME, это ни на что особенно не влияет
На NTFS разделе WSL2 почти в сто раз медленней чем WSL1 а так же MSYS, CYGWIN и полноценно заменить их не может.
Можно частично решить эту проблему, проставив сетевые симлинки с "\\wsl$\" на NTFS, но этот кусок проекта будет все равно физически лежать внутри VM в файле VМDK.
Кроме git clone / git pull и, собственно, сборки, предполагается, что проект еще надо в промежутках как-то разрабатывать, тестировать и отлаживать.
Ожидаемые цифры:
- NTFS в разы медленнее EXT4.
- В WSL1 минимальные накладные расходы при натягивании Linux-операций на NTFS (эмуляция внутри ядра).
- В MSYS2 накладных расходов больше, т.е. больше системных вызовов, которые отрабатывают со скоростью windows (выполняются ядром Windows и драйвером NTFS).
- Худший случай при доступе к NTFS из WSL2. Добавляется эмуляция Linux-операций через SMB, и все это обслуживает службой на стороне windows с выполнением в NTFS.
Единственный способ получить скорость достаточно очевиден — избавиться от медленных компонентов (NTFS, ядра и служб Windows).
Это все конечно очень классно, но когда в WSL2 завезут поддержку GPU?
Почему WSL 2 в 13 раз быстрее, чем WSL: впечатления от Insider Preview