Có một bất lợi trong việc bắt đầu nhiều ứng dụng cùng một lúc?


1

Về cơ bản tôi đang tự hỏi liệu một nguyên tắc như cục bộ bộ đệm, tức là việc truy cập các phần bộ nhớ liên tiếp có ích hay không vì thông thường các phần lớn hơn của bộ nhớ đó được tải vào bộ đệm, cũng là vấn đề ở cấp ứng dụng.

Trong thực tế - giả sử các ứng dụng không yêu cầu phân bổ thêm một khi đã bắt đầu - Tôi tự hỏi liệu có lợi thế gì khi bắt đầu ứng dụng A và đợi một lúc, sau đó bắt đầu ứng dụng B so với khởi động ứng dụng A và B đồng thời. Đối với trường hợp sau, tôi có thể tưởng tượng A yêu cầu một số bộ nhớ, rồi B, rồi lại tiếp tục (mặc dù tôi không chắc nó xảy ra như vậy nhưng mặt khác, hệ điều hành không thể biết trước được bao nhiêu bộ nhớ sẽ có cần thiết để nó không giống như nó có thể đặt trước một đoạn lớn trước đó).

Có một nhược điểm nào đó không, tức là có bộ nhớ ứng dụng bao gồm nhiều khối tại các địa chỉ cách xa nhau hơn về mặt lý thuyết có thể đạt được nếu tất cả bộ nhớ ứng dụng được phân bổ thành một khối lớn?


Chạy hai tiến trình cùng một lúc, sẽ dẫn đến nhiều lỗi bộ nhớ cache hơn, nhưng cũng sẽ được hưởng lợi từ việc sử dụng song song tốt hơn (ngay cả trên một lõi đơn, vì đĩa và cpu được song song).
ctrl-alt-delor

Giả thuyết của bạn là gì? Có phải là bắt đầu chúng cùng nhau là tốt hơn, hoặc bắt đầu chúng riêng biệt là tốt hơn?
ctrl-alt-delor

@richard Tôi không thực sự có một giả thuyết vì tôi không biết đủ về chủ đề này. Ruột của tôi nói rằng bắt đầu chúng một cách riêng biệt sẽ tốt hơn một khi chúng được bắt đầu; Tôi không quan tâm đến sự song song trong khi bắt đầu.
stijn

Hệ điều hành nào? Kiến trúc gì?
ctrl-alt-delor

Không có gì cụ thể, câu trả lời cụ thể của linux / windows đều ổn
stijn

Câu trả lời:


1

Có một nhược điểm nào đó không, tức là có bộ nhớ ứng dụng bao gồm nhiều khối tại các địa chỉ cách xa nhau hơn về mặt lý thuyết có thể đạt được nếu tất cả bộ nhớ ứng dụng được phân bổ thành một khối lớn?

Bạn sẽ phải:

  • nhìn vào bộ nhớ ảo và vật lý là gì và cách chúng được ánh xạ.

  • xem nếu bộ nhớ đệm được thực hiện ở lớp ảo hoặc vật lý trên kiến ​​trúc của bạn.

  • xem hệ điều hành của bạn làm mọi thứ như thế nào

Liệu bộ nhớ vật lý bị phân mảnh có vấn đề? Chỉ khi nó dẫn đến các bản đồ ảo đến vật lý phức tạp hơn (mmu, v.v.) Một khối ảo liền kề với vật lý không liền kề, mới có thể dẫn đến một bản đồ tra cứu phức tạp hơn nhiều. Linux có nhiều kích cỡ trang khác nhau mà nó có thể sử dụng, nó sẽ cố gắng sử dụng kích thước lớn nhất có thể (để phù hợp nhất với malloc). Trên hệ thống Debian jessie với kernel 4.6.0-0 amd64, tôi có kích thước trang là 4k (154964 đang sử dụng), 2M (3753 đang sử dụng) và 1G (1 đang sử dụng).

Bộ nhớ ảo bị phân mảnh có vấn đề? Tôi không thể thấy điều đó, nếu quá trình yêu cầu một số khối có nhiều malocs, thì nó sẽ xem chúng là riêng biệt, ngay cả khi liền kề. Một maloc phải tiếp giáp trong ảo. Hệ thống an ninh, có thể nhưng bảo vệ các khối giữa mỗi khối bị sai lệch, do đó ngăn chặn chúng liền kề nhau.

Trên Linux, rất nhiều thứ sẽ được chia sẻ giữa các quy trình: Nếu cùng một tệp thực thi, thì chúng sẽ chia sẻ tất cả các khối chỉ đọc của tệp thực thi (văn bản, dữ liệu-ro, v.v.). Họ cũng sẽ chia sẻ dữ liệu khởi tạo (dữ liệu), cho đến khi một trong số họ thay đổi một trang, sau đó trang này được sao chép. Điều tương tự cũng được thực hiện cho tất cả các thư viện được liên kết động, vì vậy chúng sẽ chia sẻ rất nhiều trong số này. Ngoài ra các tệp trên đĩa là trao đổi cho bộ nhớ này, vì vậy nó sẽ không bận tâm đến việc đọc dữ liệu cho đến khi nó cần (chương trình sẽ bắt đầu chạy mà không có dữ liệu nào được đọc, điều này sẽ dẫn đến lỗi ram và một trang được đọc trong, sau đó chương trình sẽ chạy, cho đến khi có một lỗi khác, v.v.). Nếu thiếu ram, một trang có thể bị hủy, nó có thể được đọc lại sau (không cần phải trao đổi nó). Điều này có thể gây ra nhiều đĩa đọc khi bộ nhớ thấp, dẫn đến khởi động chậm hơn.

(một số kiến ​​trúc bộ nhớ đệm bộ nhớ cache: đây là bộ nhớ rõ nhất trong đó nó cần phải nhanh, bộ nhớ đệm vật lý ở các cấp độ khác, nơi nó cần phải có hiệu quả bộ nhớ.).


Vì vậy, các tldr; là bsally: không quan trọng và thật khó để tìm ra nếu nó có nhiều yếu tố liên quan?
stijn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.