Tôi đã chạy một điểm chuẩn cho các cấu trúc dữ liệu khác nhau rất gần đây tại công ty của tôi, vì vậy tôi cảm thấy mình cần phải bỏ qua một từ. Rất phức tạp để đánh giá một cái gì đó một cách chính xác.
Đo điểm chuẩn
Trên web, chúng tôi hiếm khi tìm thấy (nếu có) một điểm chuẩn được thiết kế tốt. Cho đến hôm nay, tôi chỉ tìm thấy các điểm chuẩn được thực hiện theo cách của nhà báo (khá nhanh chóng và quét hàng tá biến dưới thảm).
1) Bạn cần xem xét về sự nóng lên của bộ nhớ cache
Hầu hết mọi người chạy điểm chuẩn đều sợ sự khác biệt về bộ đếm thời gian, do đó họ chạy nội dung của họ hàng nghìn lần và mất toàn bộ thời gian, họ chỉ cẩn thận lấy cùng hàng nghìn lần cho mỗi thao tác và sau đó xem xét điều đó có thể so sánh được.
Sự thật là, trong thế giới thực, điều đó không có ý nghĩa gì, vì bộ nhớ cache của bạn sẽ không ấm và hoạt động của bạn có thể chỉ được gọi một lần. Do đó, bạn cần phải chuẩn bằng RDTSC và thời gian gọi chúng một lần duy nhất. Intel đã làm một bài báo mô tả cách sử dụng RDTSC (sử dụng lệnh cpuid để làm sạch đường ống và gọi nó ít nhất 3 lần vào đầu chương trình để ổn định nó).
2) Đo độ chính xác RDTSC
Tôi cũng khuyên bạn nên làm điều này:
u64 g_correctionFactor; // number of clocks to offset after each measurement to remove the overhead of the measurer itself.
u64 g_accuracy;
static u64 const errormeasure = ~((u64)0);
#ifdef _MSC_VER
#pragma intrinsic(__rdtsc)
inline u64 GetRDTSC()
{
int a[4];
__cpuid(a, 0x80000000); // flush OOO instruction pipeline
return __rdtsc();
}
inline void WarmupRDTSC()
{
int a[4];
__cpuid(a, 0x80000000); // warmup cpuid.
__cpuid(a, 0x80000000);
__cpuid(a, 0x80000000);
// measure the measurer overhead with the measurer (crazy he..)
u64 minDiff = LLONG_MAX;
u64 maxDiff = 0; // this is going to help calculate our PRECISION ERROR MARGIN
for (int i = 0; i < 80; ++i)
{
u64 tick1 = GetRDTSC();
u64 tick2 = GetRDTSC();
minDiff = std::min(minDiff, tick2 - tick1); // make many takes, take the smallest that ever come.
maxDiff = std::max(maxDiff, tick2 - tick1);
}
g_correctionFactor = minDiff;
printf("Correction factor %llu clocks\n", g_correctionFactor);
g_accuracy = maxDiff - minDiff;
printf("Measurement Accuracy (in clocks) : %llu\n", g_accuracy);
}
#endif
Đây là một công cụ đo lường sự khác biệt và nó sẽ lấy giá trị tối thiểu của tất cả các giá trị đo được, để tránh nhận được -10 ** 18 (giá trị âm bản đầu tiên 64 bit) theo thời gian.
Lưu ý việc sử dụng nội tuyến chứ không phải lắp ráp nội tuyến. Hợp ngữ nội tuyến đầu tiên hiếm khi được hỗ trợ bởi trình biên dịch, nhưng tệ hơn nhiều, trình biên dịch tạo ra một rào cản sắp xếp thứ tự đầy đủ xung quanh lắp ráp nội tuyến vì nó không thể phân tích tĩnh bên trong, vì vậy đây là một vấn đề để đánh giá nội dung trong thế giới thực, đặc biệt là khi chỉ gọi nội dung Một lần. Vì vậy, một nội tại phù hợp ở đây, bởi vì nó không phá vỡ việc sắp xếp lại các hướng dẫn tự do của trình biên dịch.
3) tham số
Vấn đề cuối cùng là mọi người thường kiểm tra quá ít biến thể của kịch bản. Hiệu suất vùng chứa bị ảnh hưởng bởi:
- Người phân bổ
- kích thước của loại chứa
- chi phí thực hiện hoạt động sao chép, hoạt động chuyển nhượng, vận hành di chuyển, vận hành xây dựng, thuộc loại hình chứa.
- số phần tử trong vùng chứa (kích thước của vấn đề)
- loại có 3-phép toán tầm thường
- loại là POD
Điểm 1 rất quan trọng vì các vùng chứa luôn phân bổ theo thời gian và điều này rất quan trọng nếu chúng phân bổ bằng cách sử dụng CRT "mới" hoặc một số hoạt động do người dùng xác định, chẳng hạn như phân bổ nhóm hoặc người làm tự do hoặc ...
( đối với những người quan tâm đến pt 1, hãy tham gia chuỗi bí ẩn trên gamedev về tác động của trình phân bổ hệ thống )
Điểm 2 là vì một số vùng chứa (ví dụ A) sẽ mất thời gian sao chép nội dung xung quanh và loại càng lớn thì chi phí càng lớn. Vấn đề là khi so sánh với một thùng chứa B khác, A có thể thắng B đối với loại nhỏ và thua đối với loại lớn hơn.
Điểm 3 giống như điểm 2, ngoại trừ nó nhân chi phí với một số hệ số trọng số.
Điểm 4 là một câu hỏi về chữ O lớn lẫn với các vấn đề về bộ nhớ cache. Một số vùng chứa có độ phức tạp kém phần lớn có thể hoạt động tốt hơn các vùng chứa có độ phức tạp thấp đối với một số loại nhỏ (như mapso với vector, vì vị trí bộ nhớ cache của chúng tốt, nhưngmap phân mảnh bộ nhớ). Và sau đó tại một số điểm giao nhau, chúng sẽ mất đi, bởi vì kích thước tổng thể được chứa bắt đầu "rò rỉ" vào bộ nhớ chính và gây ra lỗi bộ nhớ cache, cộng với thực tế là độ phức tạp tiệm cận có thể bắt đầu được cảm nhận.
Điểm 5 là về việc trình biên dịch có thể giải quyết những thứ trống rỗng hoặc tầm thường tại thời điểm biên dịch. Điều này có thể tối ưu hóa rất nhiều hoạt động, bởi vì các vùng chứa được tạo khuôn mẫu, do đó mỗi loại sẽ có cấu hình hiệu suất riêng.
Điểm 6 cũng giống như điểm 5, POD có thể được hưởng lợi từ thực tế rằng việc xây dựng bản sao chỉ là một bản ghi nhớ và một số vùng chứa có thể có một triển khai cụ thể cho những trường hợp này, bằng cách sử dụng các chuyên môn mẫu từng phần hoặc SFINAE để chọn các thuật toán theo các đặc điểm của T.
Về bản đồ phẳng
Rõ ràng bản đồ phẳng là một trình bao bọc vectơ được sắp xếp, giống như Loki PGSVector, nhưng với một số hiện đại hóa bổ sung đi kèm với C ++ 11, khai thác ngữ nghĩa chuyển động để tăng tốc chèn và xóa các phần tử đơn lẻ.
Đây vẫn là một container được đặt hàng. Hầu hết mọi người thường không cần phần đặt hàng, do đó, sự tồn tại của unordered...
Bạn đã xem xét rằng có thể bạn cần một flat_unorderedmap? đó sẽ là một cái gì đó tương tự google::sparse_maphoặc một cái gì đó tương tự — một bản đồ băm địa chỉ mở.
Vấn đề của bản đồ băm địa chỉ mở là tại thời điểm rehash chúng phải sao chép mọi thứ xung quanh sang vùng đất bằng phẳng mở rộng mới, trong khi một bản đồ không có thứ tự tiêu chuẩn chỉ phải tạo lại chỉ mục băm, trong khi dữ liệu được phân bổ vẫn ở nguyên vị trí của nó. Tất nhiên, nhược điểm là bộ nhớ bị phân mảnh như địa ngục.
Tiêu chí của một rehash trong một bản đồ băm địa chỉ mở là khi dung lượng vượt quá kích thước của vectơ nhóm nhân với hệ số tải.
Một hệ số tải điển hình là 0.8; do đó, bạn cần phải quan tâm đến điều đó, nếu bạn có thể định kích thước trước bản đồ băm của mình trước khi điền nó, hãy luôn định kích thước trước thành: intended_filling * (1/0.8) + epsilonđiều này sẽ đảm bảo cho bạn không bao giờ phải quay lại và sao chép lại mọi thứ trong quá trình điền.
Ưu điểm của bản đồ địa chỉ đóng ( std::unordered..) là bạn không phải quan tâm đến các tham số đó.
Nhưng boost::flat_maplà một vector có thứ tự; do đó, nó sẽ luôn có độ phức tạp tiệm cận log (N), kém hơn so với bản đồ băm địa chỉ mở (thời gian không đổi được phân bổ). Bạn cũng nên xem xét điều đó.
Kết quả điểm chuẩn
Đây là một bài kiểm tra liên quan đến các bản đồ khác nhau (với intkhóa và __int64/ somestructdưới dạng giá trị) và std::vector.
thông tin các loại đã thử nghiệm:
typeid=__int64 . sizeof=8 . ispod=yes
typeid=struct MediumTypePod . sizeof=184 . ispod=yes
Chèn
BIÊN TẬP:
Các kết quả trước đây của tôi có một lỗi: họ thực sự đã thử nghiệm tính năng chèn theo thứ tự, cho thấy hoạt động rất nhanh đối với các bản đồ phẳng.
Tôi đã để những kết quả đó sau đó xuống trang này vì chúng rất thú vị.
Đây là bài kiểm tra chính xác:
Tôi đã kiểm tra việc triển khai, không có thứ gọi là loại hoãn lại được thực hiện trong các bản đồ phẳng ở đây. Mỗi phần chèn sẽ được sắp xếp nhanh chóng, do đó điểm chuẩn này thể hiện các khuynh hướng tiệm cận:
map: O (N * log (N))
hashmaps: O (N)
vector và flatmaps: O (N * N)
Cảnh báo : sau đây, 2 bài kiểm tra cho std::mapvà cả hai đều flat_mapcó lỗi và thực sự kiểm tra việc chèn theo thứ tự (so với chèn ngẫu nhiên cho các vùng chứa khác. Vâng, thật khó hiểu, xin lỗi):
Chúng ta có thể thấy rằng việc chèn theo thứ tự, dẫn đến đẩy lùi và cực kỳ nhanh chóng. Tuy nhiên, từ các kết quả không có biểu đồ của điểm chuẩn của tôi, tôi cũng có thể nói rằng điều này không gần mức tối ưu tuyệt đối cho việc chèn ngược. Tại 10k phần tử, tính tối ưu chèn ngược hoàn hảo thu được trên một vectơ được đặt trước. Điều này mang lại cho chúng ta 3 triệu chu kỳ; chúng tôi quan sát 4,8 triệu ở đây cho việc chèn có thứ tự vào flat_map(do đó 160% của mức tối ưu).
Phân tích: hãy nhớ đây là 'chèn ngẫu nhiên' cho vectơ, vì vậy 1 tỷ chu kỳ khổng lồ đến từ việc phải dịch chuyển một nửa (trung bình) dữ liệu lên trên (từng phần tử một) tại mỗi lần chèn.
Tìm kiếm ngẫu nhiên 3 yếu tố (đồng hồ được chuẩn hóa lại thành 1)
kích thước = 100
kích thước = 10000
Lặp lại
trên kích thước 100 (chỉ loại MediumPod)
trên kích thước 10000 (chỉ loại MediumPod)
Hạt muối cuối cùng
Cuối cùng, tôi muốn quay lại "Đo điểm chuẩn §3 Pt1" (công cụ phân bổ hệ thống). Trong một thử nghiệm gần đây tôi đang thực hiện xung quanh hiệu suất của bản đồ băm địa chỉ mở mà tôi đã phát triển , tôi đã đo được khoảng cách hiệu suất hơn 3000% giữa Windows 7 và Windows 8 trên một số std::unordered_maptrường hợp sử dụng ( thảo luận ở đây ).
Điều này khiến tôi muốn cảnh báo người đọc về các kết quả trên (chúng được thực hiện trên Win7): quãng đường của bạn có thể thay đổi.
trân trọng