Tại điểm nào thì việc đọc không đồng bộ của đĩa I / O hiệu quả hơn so với đồng bộ?

22

Giả sử có một số đoạn mã đọc tệp cho nhiều người tiêu dùng và các tệp có kích thước tùy ý: Ở kích thước nào thì việc đọc tệp không đồng bộ sẽ hiệu quả hơn? Hay nói cách khác, một tập tin phải nhỏ đến mức nào để nhanh hơn chỉ cần đọc nó một cách đồng bộ?

Tôi đã nhận thấy (và có lẽ tôi không chính xác) rằng khi đọc các tệp rất nhỏ, sẽ mất nhiều thời gian hơn để đọc chúng không đồng bộ hơn là đồng bộ (đặc biệt là với .NET). Tôi giả định rằng điều này có liên quan đến việc thiết lập thời gian cho những thứ như Cổng hoàn thành I / O, chủ đề, v.v.

Có bất kỳ quy tắc của ngón tay cái để giúp đỡ ở đây? Hay là nó phụ thuộc vào hệ thống và môi trường?

— thịt
nguồn

Bạn có thể cung cấp mã mà bạn sử dụng cho điểm chuẩn? Tôi nghĩ rằng điều này chỉ có thể xảy ra trong trường hợp kích thước tệp nhỏ hơn kích thước bộ đệm bên trong của trình đọc luồng. Nhưng nếu bạn phải đọc nhiều tệp nhỏ đó, bạn có thể sẽ gặp các vấn đề khác với đĩa i / o

— Daniel Iankov

Tôi không có mã tiện dụng, tôi sợ. Đó là một cái gì đó tôi đã chạy lại một lúc và nó đã xuất hiện trong tâm trí của tôi kể từ đó. Mã này là .NET và về cơ bản là một File.Read ALLBytes () so với FileStream.BeginRead () trong một vòng lặp for

— b thịt

Khi các đường cong biểu thị chéo hiệu quả của chúng và IO không đồng bộ sẽ thoát khỏi giao cắt ở giá trị cao hơn đường cong IO đồng bộ hóa.

— Thomas Eding

14

Thật không may, câu trả lời là "nó phụ thuộc." Bạn có thể dễ dàng viết một chương trình nhỏ để xác định theo thời gian thực nghiệm cả hai lần đọc không đồng bộ và đồng bộ hóa.

Nó sẽ phụ thuộc vào rất nhiều yếu tố. Chúng có được lưu trữ trên đĩa quay, SSD hoặc ổ đĩa mạng không? Bạn đang sử dụng loại CPU nào? Có bao nhiêu ổ cắm / lõi? Bạn đang chạy trong một VM hoặc kim loại trần? Bạn đang chạy một hệ điều hành cổ xưa hay hiện đại?

— Martin C. Martin
nguồn

1

Vâng, tôi đã tìm ra nhiều. Tôi đoán tôi đã hy vọng có một số loại nghiên cứu để sử dụng như một hướng dẫn hoặc quy tắc của ngón tay cái.

— thịt

9

Async có 3 ưu điểm chính:

Nó làm giảm việc sử dụng CPU. Điều này có thể hữu ích nếu bạn cũng đang thực hiện các hoạt động nặng CPU với dữ liệu bạn vừa đọc.
Sử dụng một số loại cơ sở hạ tầng không đồng bộ làm cho mã dễ bị liệt. Đặc biệt nếu bạn đang đọc nhiều tập tin.
Bằng cách gửi nhiều yêu cầu đọc-ghi đến HĐH, HĐH và CTNH có thể sắp xếp lại các thao tác đó để được hoàn thành nhanh hơn. SATA2 có tính năng như vậy.

Tôi tin rằng ưu điểm chính của việc đọc không đồng bộ là khi bạn làm việc với nhiều tệp hoặc bạn cần nhiều năng lượng CPU.

— Hưng phấn
nguồn

Lưu ý cho điểm 2 rằng nó sẽ không tối ưu hóa bất cứ điều gì nếu hoạt động I / O là nút cổ chai. Mọi thứ sẽ khác nếu bạn truy cập song song, thông qua RAID hoặc mạng, các tệp được đặt trên các đĩa khác nhau.

— Arseni Mourzenko

5

Hmm, tôi gặp khó khăn trong việc hiểu ý của bạn với # 1. Tôi muốn nói đó là cách khác trong thực tế. Bởi vì với trường hợp không đồng bộ, bạn hiện đang thay đổi (các) luồng của mình từ blocked waiting for I/O(CPU 0%) thành continue normal processing(> 0% CPU).

— Isak Savo

3

Nó phụ thuộc

Một điều cần lưu ý là việc chuyển đổi bối cảnh giữa các quy trình tốn kém như thế nào. Node.JS được thiết kế theo cách của nó bởi vì nó giả định rằng việc thực hiện chuyển đổi ngữ cảnh rất tốn kém và nếu không bạn sẽ có rất nhiều quá trình chờ đợi trên IE sẽ làm hỏng máy tính.

Mặt khác, Erlang làm cho một chuyển đổi bối cảnh quá trình rất rẻ để mọi thứ có thể được đồng bộ và thời gian chạy Erlang có thể theo dõi toàn bộ.

Vì vậy, các yếu tố cần xem xét:

Chi phí cho một hoạt động chuyển đổi bối cảnh
tốc độ của đĩa để tìm kiếm hoạt động
tốc độ của đĩa cho các hoạt động đọc
là các tập tin trong bộ nhớ cache

Và tôi chắc chắn rằng tôi đang bỏ qua một nửa tá yếu tố

— Zachary K
nguồn

2

Tôi không chắc chắn có một "điểm" cụ thể, nhưng nó có ý nghĩa nhất khi bạn có nhiều luồng hoạt động, vì nó cho phép bạn chồng chéo I / O của mình với công việc khác. Nếu bạn có các luồng dự phòng không hoạt động, thì việc đọc không đồng bộ sẽ không mang lại cho bạn bất kỳ lợi thế nào. Chỉ khi bạn có hàng đợi công việc được lấp đầy và chuỗi của bạn có thể hữu ích thực hiện công việc khác thay vì chờ I / O thì việc truy cập tệp async mang lại bất kỳ lợi thế nào.

— TMN
nguồn

vâng, đó là toàn bộ quan điểm của đa luồng!

— Vlad

1

Tôi nghĩ vấn đề ở đây không phải là tốc độ đọc quá nhiều, vì đó là độ trễ.

Nếu bạn đang đọc từ một ổ đĩa mạng hoặc từ một ổ đĩa cứng cơ học chậm với hàng đợi dài, hiệu suất sẽ mất một thời gian để đọc. Và nếu ứng dụng của bạn cũng thực hiện việc đọc trong luồng GUI, trong trường hợp đó là một ứng dụng rất tệ, thì nó sẽ rất tệ cho người dùng.

— Mã hóa
nguồn