Ваше программное обеспечение для моделирования, скорее всего, связано либо с процессором, либо с памятью . Для таких рабочих нагрузок можно было бы не видеть каких-либо существенных различий между выполнением кода на «голом железе» или внутри 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 не дает выигрыша в производительности по сравнению с использованием обычной файловой системы на диске.