Запуск симуляции на чистой Ubuntu против Ubuntu в Windows (WSL)


15

Я хотел бы задать вопрос о тестировании большой CAE- симуляции на одном компьютере в следующих двух ситуациях.

  1. Чистая система Ubuntu
  2. Система Ubuntu в Windows 10 (WSL)

Являются ли скорости расчета в обоих случаях практически одинаковыми или они разные?


4
Без знания природы симуляции на это невозможно ответить.
Муру

1
@muru: Это не что расплывчатое. «Симуляция» - это, по-видимому, вычислительно-фоновое задание, которое делает его связанным с процессором или памятью. (Дисковый или сетевой ввод-вывод также может быть узким местом, но люди, пишущие такие программы, склонны избегать этого, и некоторые современные моделирующие программы могут даже использовать графический процессор для параллельных вычислений.) Можно довольно легко написать (или загрузить) эталонный тест он проверяет все 2-5 возможных узких мест и проверяет, есть ли существенная разница между WSL и Ubuntu для какой-либо из них. Я бы сделал это, но у меня нет WSL (или Windows 10) доступны.
Илмари Каронен

3
@IlmariKaronen "предположительно". В зависимости от того, какие данные загружены, они также могут интенсивно обрабатывать ввод-вывод, даже если они связаны с процессором. А оставшаяся часть вашего комментария - довольно веская причина, чтобы закрыть это - мы понятия не имеем, какое здесь может иметь место возможное сочетание узких мест.
Муру

1
Что ж, я опубликовал ответ, поскольку выясняется, что подходящие тесты уже доступны . Очевидно, я не могу с уверенностью сказать, будет ли специфический код симуляции OP работать медленнее на WSL или нет; но в любом случае ответ на этот вопрос бесполезен никому, кроме ФП в любом случае. На основании этих тестов я могу ответить на вопрос, какие типы кодов симуляции можно ожидать с разницей в производительности между WSL и собственным Linux.
Илмари Каронен

@muru, это CAE Simulation (Abaqus CAE).
ABCDEMMM

Ответы:


18

Ваше программное обеспечение для моделирования, скорее всего, связано либо с процессором, либо с памятью . Для таких рабочих нагрузок можно было бы не видеть каких-либо существенных различий между выполнением кода на «голом железе» или внутри WSL (или любого другого уровня совместимости или виртуальной машины, использующей собственное выполнение), поскольку в любом случае ОС в основном просто находится в режиме ожидания в то время как код симуляции работает непосредственно на процессоре.

Тем не менее, также возможно, что ваше моделирование, по крайней мере, частично связано с вводом / выводом, и именно здесь могут возникнуть различия. Очевидно, WSL (в настоящее время) имеет довольно медленный интерфейсный уровень файловой системы, который может значительно замедлить дисковый ввод-вывод. * При этом дисковый ввод-вывод может быть основным узким местом для многих видов задач массовой обработки данных, «симуляции». обычно не следует тратить большую часть своего времени на чтение и запись файлов. Если у вас есть, вы можете захотеть запустить его с RAM-диска (например, tmpfs на нативном ** Linux), чтобы избежать ненужного доступа к физическому диску.

В любом случае, единственный способ убедиться в этом - проверить свою симуляцию в обеих средах и время, необходимое для ее запуска. Однако прежде чем делать это, вы можете взглянуть на существующие тесты, такие как тест производительности WSL и Docker, VirtualBox и родной Linux от Phoronix от февраля 2018 года , и проверить результаты любых тестов, в которых используются те же компоненты. системы, как ваша симуляция делает.

(FWIW, результаты Phoronix, по-видимому, в основном соответствуют общим принципам, которые я изложил выше, хотя есть несколько примечательных странностей, таких как VirtualBox, по-видимому, превосходящих родной Linux в нескольких тестах, связанных с вводом / выводом, по-видимому, из-за того, что его виртуальный диск не всегда сразу синхронизирует данные на физический диск. Одна потенциально важная проблема, которую я не смог отметить выше, заключается в том, что тесты показывают существенные различия в многопоточной производительности OpenMP как между различными средами хоста, так и между различными дистрибутивами Linux даже при работе на голом оборудовании. это не так уж и удивительно, так как многопоточность и IPC обрабатываются ядром. Я полагаю, что большая часть различий между дистрибутивами может заключаться в разных параметрах настройки времени выполнения и / или времени компиляции ядра.)


*) Согласно этому сообщению в блоге MSDN от 2016 года, в WSL на самом деле есть два компонента интерфейса файловой системы: VolFs, который близко эмулирует собственную семантику файловой системы Linux поверх NTFS и используется для монтирования, например, /и /home, и DrvFs, который обеспечивает в основном семантику, подобную Windows и используется для доступа к дискам хоста Windows через /mnt/cи т. д. Если вашему программному обеспечению не требуются собственные функции файловой системы Linux, такие как несколько жестких ссылок на один и тот же файл, его настройка для хранения файлов данных в папке DrvFs может повысить производительность доступа к файлам на WSL.

**) Согласно этой ветке Reddit от мая 2017 года, "tmpfs в настоящее время эмулируется с использованием диска" в WSL. Если что-то не изменилось за последний год, это, вероятно, означает, что использование tmpfs в WSL не дает выигрыша в производительности по сравнению с использованием обычной файловой системы на диске.


Возможно, не только параметры настройки, но и параметры компилятора (например, -O3 -march=haswellили что-то в этом роде. Я не знаю, что на самом деле использует Clear Linux для сборки своих ядер, но, возможно, BMI2 / popcnt/ что-то еще может измерить разницу в glibc и ядре. (Ядро победило Тем не менее, AVX не выигрывает, потому что ядро ​​избегает касания регистров FPU, за исключением специального кода, такого как данные для исправления ошибок в программном обеспечении RAID5 / 6.)
Питер Кордес

12

Ubuntu в Windows (WSL - 2017 Fall Creators Update) определенно медленнее, чем «Чистая» Ubuntu в среде Linux.

Например, для рисования экрана в Windows 10 требуется намного больше времени, чем для Ubuntu 16.04, то есть вы действительно можете видеть движение курсора в Windows 10:

WSL bash startup.gif

Для раскраски заставки WSL Bash требуется около 5 секунд. Для сравнения: в том же самом заставке в Ubuntu 16.04 это примерно 1,5 секунды:

Ubuntu терминал splash.gif


Тестирование CPU

В первом разделе показано, насколько медленен ввод / вывод на экране, но как насчет тестирования процессора?

Из этого вопроса Ubuntu Q & A: утилита для тестирования производительности процессора для Linux , я провел тесты на Ubuntu 16.04 для Linux и Windows. В Linux около 24 секунд, в Windows 10 версии 1709 около 31 секунды. Linux работает на 6 секунд быстрее или примерно на 25% быстрее. Однако я только что обновил Windows 10 до версии 1803 (Redstone 4, также известной как Spring Creators апрель 2018 года), и это заняло 24 секунды, что совпадает с Linux.

Ubuntu 16.04 в Linux

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.5065s
    total number of events:              10000
    total time taken by event execution: 23.5049
    per-request statistics:
         min:                                  2.13ms
         avg:                                  2.35ms
         max:                                  8.52ms
         approx.  95 percentile:               2.76ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.5049/0.00

Ubuntu 16.04 на Windows 10 сборка 1709

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          30.5350s
    total number of events:              10000
    total time taken by event execution: 30.5231
    per-request statistics:
         min:                                  2.37ms
         avg:                                  3.05ms
         max:                                  6.21ms
         approx.  95 percentile:               4.01ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   30.5231/0.00

Ubuntu 16.04 на Windows 10 сборка 1803

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.7223s
    total number of events:              10000
    total time taken by event execution: 23.7155
    per-request statistics:
         min:                                  2.21ms
         avg:                                  2.37ms
         max:                                  4.53ms
         approx.  95 percentile:               2.73ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.7155/0.00

ПРИМЕЧАНИЕ. Весеннее обновление Windows 10 для 2018 года (дублированное Redstone 4 ) вышло 9 мая (4 дня назад), и я скоро установлю его, чтобы проверить улучшения. Без сомнения, их много. Я знаю, что меня интересует это способность запускать cronзадания при запуске. Мне это нужно для автоматического ежедневного резервного копирования на gmail.com.

ПРИМЕЧАНИЕ 2. Я только что установил Windows 10 Build 1803 (апрель 2018 года, Spring Creators Update, AKA Redstone 4), и рисование экрана происходит намного быстрее. Теперь только 3 секунды вместо 5 секунд для отображения заставки Bash. Тест производительности процессора наравне с Linux.


8
Обратите внимание, что это вводит в заблуждение - это не различает производительность ввода-вывода и другие вычислительные характеристики. Известно, что WSL работает медленно для ввода / вывода (см., Например, тесты Phoronix). Это ничего не говорит о том, могут ли вычисления OP выполняться так же быстро в WSL.
Муру

6
Я искренне удивлен, что рисование заставки не эффективно мгновенно в обоих случаях. Ваш компьютер (предположительно) будет рад сделать гораздо более сложные обновления экрана за несколько миллисекунд, например, при воспроизведении видео. И в последний раз, когда я видел терминал таким же медленным, как в вашей первой записи, был в начале 90-х, когда я набирал BBS на моем модеме со скоростью 2400 бит / с.
Илмари Каронен

Что вы подразумеваете под "Ubuntu в Linux"?
Джон Бентли

3
Честно говоря, этот тип теста совершенно бесполезен для любой реалистичной программы, как любой тест, который по существу измеряет скорость рисования консоли. Либо узким местом вашей программы является консольный ввод / вывод (который, как известно, медленный даже в Linux с большинством терминальных эмуляторов), или это не надежная мера ничего полезного.
Matteo Italia

2
@ WinEunuuchs2Unix Из того, что я вижу, мало вычислений. но много операций ввода-вывода: получение информации о погоде, чтение даты и времени, печать в формате, чтение информации о системе и т. д. В любом случае, вы когда-нибудь использовали Abaqus? Программное обеспечение для моделирования, такое как Ansys или Simulink, не привязывается к экрану ввода-вывода при запуске реального моделирования, если только вы не заставляете имитацию быть такой. Для них вполне возможно показать справедливые конечные результаты в зависимости от выполненного моделирования.
Муру

7

Подумайте об этом - в WSL ваш компьютер работает под управлением полной графической системы Windows (которая, в первую очередь, является ужасающей проблемой ресурсов), а также подсистемы Ubuntu. В родной Ubuntu работает только Ubuntu.


1
@JimDeadlock Я действительно не думаю, что это убивает рабочий стол, оно просто не отображает его. Каждое приложение GUI все еще работает в фоновом режиме, не так ли?
Эрик Думинил

2
Windows GUI потребляет немного памяти, но не сильно загружает процессор, когда ничего не делает. Я не понимаю, почему это оказало бы существенное влияние?
Видарло

1
Переключение консоли на другой VT не убивает никаких процессов; @EricDuminil правильно. Это может приостановить то, что использовало процессорное время для обновления графики, потому что X-сервер знает, что он больше не отображается (и, следовательно, может не тратить время на обработку OpenGL или что-либо еще). Но если вы запускаете pstreeили ps auxw, очевидно, что все процессы все еще живы. (Или topнажмите M для сортировки по потреблению памяти).
Питер Кордес

2
@MichaelEricOberlin: переход на другой VT не влияет на уровень запуска! Просто текстовые консоли все еще доступны на уровне выполнения, который запускает GDM. (И кстати, уровни запуска в основном ушли в прошлое; systemdне работают как SysV init. В предыдущей части этого комментария делается вид, что вы работали с 5 или 10-летним дистрибутивом Linux с initнастройкой старой школы .) Но да выход из сеанса X и остановка X11 / GDM высвободят ресурсы, особенно если у вас нет места подкачки, или на вашем рабочем столе часто возникает дерьмо, которое часто просыпается даже в режиме ожидания.
Питер Кордес

1
@MichaelEricOberlin: Ваш комментарий просто неправильный. Не могли бы вы удалить его?
Эрик Думинил

1

Я не знаю, повлияет ли это на вашу симуляцию в частности, но это может:

WSL НЕ использует RAM для разделяемой памяти! Он использует диск!

Это означает, что если ваша симуляция использует общую память (подумайте /dev/shm), она может быть медленной и / или изнашивать ваше устройство хранения! И снижение производительности происходит из нескольких слоев:

  • Драйвер файловой системы

  • Драйвер хранилища

  • Носитель

Но если он этого не делает, то производительность должна быть такой же, как в Ubuntu с голым металлом (при условии отсутствия других операций ввода-вывода, как уже упоминали другие).


действительно приятно это знать!
ABCDEMMM
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.