Tùy thuộc vào số lượng lõi bạn có. Nếu bạn chỉ có 2 lõi (CPU, bộ vi xử lý, hyperthreads, bạn biết những gì tôi có nghĩa là), sau đó OpenMP không thể cung cấp cho một sự gia tăng to lớn trong hiệu suất, nhưng sẽ giúp đỡ.Mức tăng tối đa bạn có thể có là chia thời gian của bạn cho số bộ vi xử lý sao cho nó vẫn sẽ mất 100 - 150 ms mỗi khung hình.
Phương trình là
thời gian song song = (([tổng thời gian để thực hiện một nhiệm vụ] - [code mà không thể được song song])/[số cpu]) + [mã mà không thể được song song]
Về cơ bản, OpenMP đá ở chế biến vòng lặp song song. Nó khá dễ sử dụng
#pragma omp parallel for
for (i = 0; i < N; i++)
a[i] = 2 * i;
và bang, bạn cho song song. Nó không hoạt động cho mọi trường hợp, không phải mọi thuật toán đều có thể được song song theo cách này nhưng nhiều thuật toán có thể được viết lại (bị tấn công) để tương thích. Nguyên tắc chính là Hướng dẫn đơn, Nhiều dữ liệu (SIMD), áp dụng cùng một mã chập cho nhiều pixel chẳng hạn.
Nhưng đơn giản việc áp dụng sổ ghi chép sách này đi ngược lại các quy tắc tối ưu hóa.
1-Benchmark mã của bạn
2-Tìm các tắc nghẽn REAL với "khoa học" bằng chứng (số) thay vì chỉ đoán mà bạn nghĩ rằng có một nút cổ chai
3-Nếu nó thực sự đang xử lý vòng, sau đó OpenMP là dành cho bạn
Có thể tối ưu hóa đơn giản trên mã hiện tại của bạn có thể mang lại kết quả tốt hơn, ai biết được?
Đường khác sẽ chạy opengl trong chuỗi và xử lý dữ liệu trên một chuỗi khác. Điều này sẽ giúp ích rất nhiều nếu opengl hoặc hệ thống kết xuất hạt của bạn mất rất nhiều năng lượng, nhưng hãy nhớ rằng luồng có thể dẫn đến các loại tắc nghẽn đồng bộ hóa khác.
Bạn cũng có thể chỉ sử dụng pthread hoặc bất kỳ hệ điều hành nào đã cung cấp. – pestilence669
@Pestilence - vâng, mặc dù tôi muốn đề xuất các giải pháp đa nền tảng :) –
lol. pthreads trên Cygwin sau đó! :) – pestilence669