Chạy một mô phỏng trên Ubuntu thuần so với trên Ubuntu trong Windows (WSL)

15

Tôi muốn hỏi một câu hỏi về việc thử nghiệm một mô phỏng CAE lớn trên cùng một máy tính trong hai tình huống sau.

Hệ thống Ubuntu thuần túy
Hệ thống Ubuntu trong Windows 10 (WSL)

Là tốc độ tính toán trong cả hai trường hợp gần như nhau hoặc chúng khác nhau?

windows windows-subsystem-for-linux benchmarks

— ABCDEMMM
nguồn

4

Không biết bản chất của mô phỏng, điều này là không thể trả lời.

— muru

1

@muru: Nó không phải là mơ hồ. Một "mô phỏng" có lẽ là một công việc nền chuyên sâu tính toán, làm cho nó bị ràng buộc bởi CPU hoặc bộ nhớ. (I / O trên đĩa hoặc mạng cũng có thể là nút cổ chai, nhưng đó là điều mà mọi người viết các chương trình đó có xu hướng tránh và một số mã mô phỏng hiện đại thậm chí có thể sử dụng GPU để tính toán song song.) Người ta có thể dễ dàng viết (hoặc tải xuống) điểm chuẩn kiểm tra tất cả 2 đến 5 nút thắt có thể có này và kiểm tra xem có sự khác biệt đáng kể nào giữa WSL và Ubuntu gốc hay không đối với bất kỳ lỗi nào trong số chúng. Tôi sẽ làm điều đó, nhưng tôi không có sẵn WSL (hoặc Windows 10).

— Ilmari Karonen

3

@IlmariKaronen "có lẽ". Tùy thuộc vào dữ liệu mang đến khủng hoảng, nó cũng có thể bị IO tăng cường ngay cả khi CPU bị ràng buộc. Và phần còn lại của bình luận của bạn là một lý do khá chính đáng để kết thúc điều này - chúng tôi không có ý tưởng nào về sự kết hợp có thể xảy ra của các nút thắt cổ chai ở đây.

— muru

1

Vâng, tôi đã đăng một câu trả lời, vì hóa ra điểm chuẩn phù hợp đã trực tuyến . Rõ ràng, tôi không thể nói chắc chắn liệu mã mô phỏng cụ thể của OP sẽ chạy chậm hơn trên WSL hay không; nhưng trong mọi trường hợp, một câu trả lời cho câu hỏi đó không có tác dụng với bất cứ ai trừ OP. Điều tôi có thể trả lời, dựa trên các điểm chuẩn, là loại mã mô phỏng nào có thể được dự kiến hợp lý sẽ có sự khác biệt về hiệu năng giữa WSL và Linux nguyên gốc.

— Ilmari Karonen

@muru, nó là Mô phỏng CAE (Abaqus CAE).

— ABCDEMMM

18

Phần mềm mô phỏng của bạn rất có thể là bị ràng buộc CPU hoặc bị ràng buộc bộ nhớ . Đối với các khối lượng công việc như vậy, người ta sẽ không ngoại trừ thấy bất kỳ sự khác biệt đáng kể nào giữa việc chạy mã trên "kim loại trần" hoặc bên trong WSL (hoặc bất kỳ lớp tương thích hoặc VM nào khác sử dụng thực thi riêng), vì trong cả hai trường hợp, HĐH hầu như chỉ đứng trong khi mã mô phỏng chạy trực tiếp trên CPU.

Tuy nhiên, cũng có thể mô phỏng của bạn ít nhất bị ràng buộc một phần I / O và đó là nơi mà sự khác biệt có thể xuất hiện. Rõ ràng, WSL (hiện tại) có lớp giao diện hệ thống tập tin khá chậm có thể làm chậm đáng kể I / O của đĩa. * Điều đó nói rằng, trong khi I / O của đĩa có thể là nút cổ chai chính cho nhiều loại tác vụ xử lý dữ liệu hàng loạt, một "mô phỏng" thường không nên dành phần lớn thời gian để đọc và viết tệp. Nếu là của bạn, bạn có thể muốn xem xét việc chạy nó từ đĩa RAM (ví dụ: tmpfs trên bản địa ** Linux) để tránh truy cập đĩa vật lý không cần thiết.

Trong mọi trường hợp, cách duy nhất để chắc chắn là kiểm tra mô phỏng của bạn trong cả hai môi trường và thời gian cần thiết để chạy. Tuy nhiên, trước khi làm điều đó, bạn có thể muốn xem các điểm chuẩn hiện có, như WSL so với Docker so với VirtualBox so với điểm chuẩn hiệu suất Linux gốc của Phoronix từ tháng 2 năm 2018 và kiểm tra kết quả xem có bất kỳ thử nghiệm nào nhấn mạnh các thành phần tương tự của hệ thống như mô phỏng của bạn.

. Một vấn đề có thể liên quan mà tôi không lưu ý ở trên là các điểm chuẩn cho thấy sự khác biệt đáng kể về hiệu năng OpenMP đa luồng cả giữa các môi trường máy chủ khác nhau và giữa các bản phân phối Linux khác nhau ngay cả khi chạy trên phần cứng trần. điều đó không quá ngạc nhiên, vì luồng và IPC được xử lý bởi kernel. Tôi đoán rằng phần lớn sự khác biệt giữa các distro có thể dẫn đến các tham số điều chỉnh kernel thời gian chạy và / hoặc biên dịch khác nhau.)

^{*) Theo MSDN bài viết trên blog này từ năm 2016, có thực sự là hai thành phần giao diện hệ thống tập tin trong WSL: VolFs, mà giả lập chặt chẽ nguồn gốc ngữ nghĩa hệ thống tập tin Linux trên NTFS và được sử dụng để gắn kết ví dụ /và /homevà DrvFs, cung cấp chủ yếu là Windows giống như ngữ nghĩa và được sử dụng để truy cập các ổ đĩa Windows lưu trữ thông qua /mnt/cvv. Nếu phần mềm của bạn không yêu cầu đặc biệt các tính năng hệ thống tệp Linux gốc như nhiều liên kết cứng đến cùng một tệp, việc định cấu hình nó để lưu trữ các tệp dữ liệu của nó trong thư mục DrvFs có thể cải thiện hiệu suất truy cập tệp trên WSL.}

^{**) Theo chủ đề Reddit này từ tháng 5 năm 2017, "tmpfs hiện được mô phỏng bằng đĩa" trên WSL. Trừ khi có gì đó đã thay đổi trong năm ngoái, điều này có lẽ có nghĩa là việc sử dụng tmpfs trên WSL không mang lại lợi ích hiệu năng nào khi sử dụng hệ thống tệp trên đĩa thông thường.}

— Ilmari Karonen
nguồn

Có lẽ không chỉ điều chỉnh các tham số, mà cả các tùy chọn trình biên dịch (ví dụ -O3 -march=haswellhoặc một cái gì đó. Tôi không biết Clear Linux thực sự sử dụng gì để xây dựng hạt nhân của chúng, nhưng có lẽ BMI2 / popcnt/ bất cứ điều gì có thể tạo ra sự khác biệt có thể đo được trong glibc và kernel. (Hạt nhân đã thắng Tuy nhiên, lợi ích của AVX là vì hạt nhân tránh chạm vào các thanh ghi FPU ngoại trừ trong mã cụ thể như dữ liệu sửa lỗi phần mềm RAID5 / 6.)

— Peter Cordes

12

Ubuntu trong Windows (WSL - Bản cập nhật mùa thu 2017) chắc chắn chậm hơn Ubuntu "thuần túy" trong môi trường Linux.

Ví dụ, vẽ màn hình mất nhiều thời gian hơn trong Windows 10 so với Ubuntu 16.04, tức là bạn thực sự có thể thấy con trỏ di chuyển trong Windows 10:

Mất khoảng 5 giây để màn hình giật gân WSL Bash vẽ. Khi so sánh, khoảng 1 1/2 giây cho cùng một màn hình giật gân trong Ubuntu 16.04:

Điểm chuẩn CPU

Phần đầu tiên cho thấy I / O màn hình chậm như thế nào nhưng về điểm chuẩn CPU thì sao?

Từ câu hỏi này Hỏi Ubuntu Q & A: Tiện ích đo điểm chuẩn CPU cho Linux , tôi đã chạy thử nghiệm trên Ubuntu 16.04 trên Linux và Windows. Trên Linux khoảng 24 giây trên Windows 10 phiên bản 1709 khoảng 31 giây. Linux nhanh hơn 6 giây hoặc nhanh hơn khoảng 25%. Tuy nhiên tôi mới nâng cấp Windows 10 lên phiên bản 1803 (Redstone 4 hay còn gọi là bản cập nhật Spring Creators tháng 4 năm 2018) và mất 24 giây giống như Linux.

Ubuntu 16.04 trên 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 trên Windows 10 bản dựng 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 trên Windows 10 bản dựng 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

LƯU Ý: Bản cập nhật mùa xuân Windows 10 cho năm 2018 (được đặt tên là Redstone 4 ) đã ra mắt vào ngày 9 tháng 5 (4 ngày trước) và tôi sẽ sớm cài đặt nó để kiểm tra các cải tiến. Không còn nghi ngờ gì nữa. Một điều tôi biết về sở thích đó là khả năng điều hành croncông việc khi khởi nghiệp. Tôi cần điều đó để sao lưu tự động hàng ngày vào gmail.com.

LƯU Ý 2: Tôi vừa cài đặt Windows 10 Build 1803 (Bản cập nhật mùa xuân tháng 4 năm 2018 của AKA Redstone 4) và việc vẽ màn hình nhanh hơn nhiều. Bây giờ chỉ còn 3 giây thay vì 5 giây để hiển thị màn hình giật gân Bash. Điểm chuẩn CPU ngang bằng với Linux bây giờ.

— WinEunuuchs2Unix
nguồn

8

Lưu ý rằng điều này là sai lệch - điều này không phân biệt hiệu suất I / O và hiệu suất tính toán khác. WSL được biết là chậm đối với I / O (xem ví dụ: điểm chuẩn Phoronix). Điều đó không nói lên điều gì về việc liệu các tính toán của OP có thể được thực hiện nhanh như trong WSL hay không.

— muru

6

Tôi thực sự ngạc nhiên khi vẽ màn hình giật gân không hiệu quả ngay lập tức trong cả hai trường hợp. Máy tính của bạn (có lẽ) rất vui khi thực hiện cập nhật màn hình phức tạp hơn nhiều trong vài mili giây, ví dụ như khi phát video. Và lần cuối cùng tôi thấy một thiết bị đầu cuối chậm như trong lần ghi âm đầu tiên của bạn là vào đầu những năm 90, khi quay số BBS trên modem 2400 bps của tôi.

— Ilmari Karonen

"Ubuntu trong Linux" nghĩa là gì?

— Jon Bentley

3

Thành thật mà nói, loại điểm chuẩn này hoàn toàn vô dụng đối với bất kỳ loại chương trình thực tế nào, vì bất kỳ điểm chuẩn nào về cơ bản đo tốc độ vẽ của bàn điều khiển. Nút cổ chai chương trình của bạn là I / O của bàn điều khiển (vốn nổi tiếng là chậm ngay cả trên Linux với hầu hết các trình giả lập thiết bị đầu cuối), hoặc đây không phải là thước đo đáng tin cậy của bất kỳ thứ gì hữu ích.

— Matteo Italia

2

@ WinEunuuchs2Unix Từ những gì tôi có thể thấy, có rất ít sự tính toán. nhưng rất nhiều I / O: tìm nạp thời tiết từ một nơi nào đó, đọc ngày và thời gian, và in nó ở định dạng, đọc thông tin hệ thống, v.v ... Dù sao, bạn đã bao giờ sử dụng Abaqus chưa? Phần mềm mô phỏng như nó hoặc Ansys hoặc Simulink không bị ràng buộc I / O màn hình khi chạy mô phỏng thực tế trừ khi bạn buộc mô phỏng phải như vậy. Hoàn toàn có thể cho những điều này hiển thị kết quả cuối cùng tùy thuộc vào mô phỏng được thực hiện.

— muru

7

Hãy suy nghĩ về nó - trong WSL, máy tính của bạn đang chạy hệ thống Windows đồ họa đầy đủ (là một con lợn tài nguyên khủng khiếp ở nơi đầu tiên) cộng với hệ thống con Ubuntu. Trong Ubuntu gốc, nó chỉ chạy Ubuntu.

— JimDeadlock
nguồn

1

@JimDeadlock Tôi thực sự không nghĩ rằng nó giết chết máy tính để bàn, nó chỉ không hiển thị nó. Mọi ứng dụng gui vẫn đang chạy trong nền, phải không?

— Eric Duminil

2

GUI GUI tiêu tốn một số bộ nhớ, nhưng CPU không sử dụng nhiều khi không làm gì cả. Tôi không thấy lý do tại sao điều đó sẽ có tác động đáng kể?

— vidarlo

1

Chuyển giao bàn điều khiển sang VT khác sẽ không giết bất kỳ quy trình nào; @EricDuminil là chính xác. Nó có thể tạm dừng những thứ đang sử dụng thời gian CPU để cập nhật đồ họa, bởi vì máy chủ X biết rằng nó không còn được hiển thị nữa (và do đó có thể không lãng phí bất kỳ thời gian nào khi xử lý OpenGL hoặc bất cứ điều gì). Nhưng nếu bạn chạy pstreehoặc ps auxw, rõ ràng là tất cả các quy trình vẫn còn sống. (Hoặc topvà nhấn M để sắp xếp theo mức tiêu thụ bộ nhớ).

— Peter Cordes

2

@MichaelEricOberlin: Thay đổi sang VT khác không ảnh hưởng đến runlevel! Chỉ là các bảng điều khiển văn bản vẫn có sẵn trong một runlevel bắt đầu GDM. (Và BTW, runlevel cơ bản là một điều của quá khứ; systemdkhông làm việc như SysV initPhần trước của nhận xét này được giả vờ rằng bạn đang chạy một cũ distro Linux 5 hoặc 10 năm với một trường học cũ. initThiết lập.) Nhưng có , đăng xuất khỏi phiên X của bạn và dừng X11 / GDM sẽ giải phóng tài nguyên, đặc biệt là nếu bạn không có không gian hoán đổi hoặc máy tính để bàn của bạn thường xuyên thức dậy ngay cả khi "không hoạt động".

— Peter Cordes

1

@MichaelEricOberlin: Nhận xét của bạn khá đơn giản là sai. Bạn có thể xem xét xóa nó?

— Eric Duminil

1

Tôi không biết liệu điều này có ảnh hưởng đến mô phỏng của bạn hay không, nhưng nó có thể:

WSL KHÔNG sử dụng RAM cho bộ nhớ dùng chung! Nó sử dụng đĩa!

Điều này có nghĩa, nếu mô phỏng của bạn sử dụng bộ nhớ dùng chung (suy nghĩ /dev/shm), nó có thể bị chậm và / hoặc làm hao mòn thiết bị lưu trữ của bạn! Và hình phạt hiệu suất đến từ nhiều lớp:

Trình điều khiển hệ thống tập tin
Trình điều khiển lưu trữ
Phương tiện lưu trữ

Nhưng nếu nó không làm điều này, thì hiệu suất sẽ tương tự như trên Ubuntu kim loại trần (giả sử không có I / O nào khác, như những người khác đã đề cập).

— người dùng541686
nguồn

thực sự tốt để biết điều đó

— ABCDEMMM