Tại sao sqrt vô hướng SSE (x) chậm hơn rsqrt (x) * x?

Tôi đã lập hồ sơ một số phép toán cốt lõi của chúng tôi trên Intel Core Duo và trong khi xem xét các cách tiếp cận khác nhau đối với căn bậc hai, tôi đã nhận thấy một điều kỳ lạ: sử dụng các phép toán vô hướng SSE, nhanh hơn để lấy căn bậc hai đối ứng và nhân nó để lấy sqrt, thay vì sử dụng opcode sqrt gốc!

Tôi đang kiểm tra nó với một vòng lặp như:

inline float TestSqrtFunction( float in );

void TestFunc()
{
  #define ARRAYSIZE 4096
  #define NUMITERS 16386
  float flIn[ ARRAYSIZE ]; // filled with random numbers ( 0 .. 2^22 )
  float flOut [ ARRAYSIZE ]; // filled with 0 to force fetch into L1 cache

  cyclecounter.Start();
  for ( int i = 0 ; i < NUMITERS ; ++i )
    for ( int j = 0 ; j < ARRAYSIZE ; ++j )
    {
       flOut[j] = TestSqrtFunction( flIn[j] );
       // unrolling this loop makes no difference -- I tested it.
    }
  cyclecounter.Stop();
  printf( "%d loops over %d floats took %.3f milliseconds",
          NUMITERS, ARRAYSIZE, cyclecounter.Milliseconds() );
}

Tôi đã thử điều này với một số cơ quan khác nhau cho TestSqrtFunction và tôi có một số thời gian thực sự khiến tôi đau đầu. Điều tồi tệ nhất cho đến nay là sử dụng hàm sqrt () gốc và để trình biên dịch "thông minh" "tối ưu hóa". Ở 24ns / float, sử dụng FPU x87, điều này thật tệ hại:

inline float TestSqrtFunction( float in )
{  return sqrt(in); }

Điều tiếp theo tôi đã thử là sử dụng nội tại để buộc trình biên dịch sử dụng opcode sqrt vô hướng của SSE:

inline void SSESqrt( float * restrict pOut, float * restrict pIn )
{
   _mm_store_ss( pOut, _mm_sqrt_ss( _mm_load_ss( pIn ) ) );
   // compiles to movss, sqrtss, movss
}

Điều này tốt hơn, ở mức 11,9ns / float. Tôi cũng đã thử kỹ thuật xấp xỉ Newton-Raphson lập dị của Carmack , chạy thậm chí còn tốt hơn cả phần cứng, ở mức 4,3ns / float, mặc dù với lỗi 1 trong 2 ¹⁰ (quá nhiều so với mục đích của tôi).

Doozy là khi tôi thử chọn SSE cho căn bậc hai nghịch đảo , và sau đó sử dụng một phép nhân để lấy căn bậc hai (x * 1 / √x = √x). Mặc dù điều này cần đến hai phép toán phụ thuộc, nhưng nó là giải pháp nhanh nhất cho đến nay, với tốc độ 1,24ns / float và chính xác đến 2 ^-14 :

inline void SSESqrt_Recip_Times_X( float * restrict pOut, float * restrict pIn )
{
   __m128 in = _mm_load_ss( pIn );
   _mm_store_ss( pOut, _mm_mul_ss( in, _mm_rsqrt_ss( in ) ) );
   // compiles to movss, movaps, rsqrtss, mulss, movss
}

Câu hỏi của tôi về cơ bản là những gì cho ? Tại sao opcode căn bậc hai tích hợp trong phần cứng của SSE lại chậm hơn so với việc tổng hợp nó từ hai phép toán khác?

Tôi chắc chắn rằng đây thực sự là chi phí của chính op, bởi vì tôi đã xác minh:

• Tất cả dữ liệu đều nằm trong bộ nhớ cache và các truy cập là tuần tự
• các chức năng được nội tuyến
• mở vòng lặp không tạo ra sự khác biệt
• cờ trình biên dịch được đặt thành tối ưu hóa hoàn toàn (và lắp ráp tốt, tôi đã kiểm tra)

( chỉnh sửa : stephentyrone chỉ ra một cách chính xác rằng các hoạt động trên chuỗi số dài nên sử dụng các hoạt động đóng gói SIMD vectơ hóa, chẳng hạn như rsqrtps- nhưng cấu trúc dữ liệu mảng ở đây chỉ dành cho mục đích thử nghiệm: điều tôi thực sự đang cố gắng đo lường là hiệu suất vô hướng để sử dụng trong mã không thể được vector hóa.)

sqrtsscho một kết quả làm tròn chính xác. rsqrtssđưa ra giá trị gần đúng với nghịch đảo, chính xác đến khoảng 11 bit.

sqrtssđang tạo ra kết quả chính xác hơn rất nhiều, khi cần độ chính xác. rsqrtsstồn tại cho các trường hợp khi một số gần đúng là đủ, nhưng tốc độ là bắt buộc. Nếu bạn đọc tài liệu của Intel, bạn cũng sẽ tìm thấy một chuỗi lệnh (xấp xỉ căn bậc hai nghịch đảo theo sau bởi một bước Newton-Raphson duy nhất) cung cấp độ chính xác gần như đầy đủ (độ chính xác ~ 23 bit, nếu tôi nhớ đúng) và vẫn còn nhanh hơn sqrtss.

chỉnh sửa: Nếu tốc độ là quan trọng và bạn thực sự gọi điều này trong một vòng lặp cho nhiều giá trị, bạn nên sử dụng các phiên bản vector hóa của các hướng dẫn này rsqrtpshoặc sqrtpscả hai đều xử lý bốn float cho mỗi lệnh.

Điều này cũng đúng với sự phân chia. MULSS (a, RCPSS (b)) nhanh hơn DIVSS (a, b). Trên thực tế, nó vẫn nhanh hơn ngay cả khi bạn tăng độ chính xác của nó bằng phép lặp Newton-Raphson.

Cả Intel và AMD đều khuyến nghị kỹ thuật này trong sách hướng dẫn tối ưu hóa của họ. Trong các ứng dụng không yêu cầu tuân thủ IEEE-754, lý do duy nhất để sử dụng div / sqrt là khả năng đọc mã.

Thay vì cung cấp một câu trả lời, điều đó thực sự có thể không chính xác (tôi cũng sẽ không kiểm tra hoặc tranh luận về bộ nhớ cache và những thứ khác, giả sử chúng giống hệt nhau) Tôi sẽ cố gắng chỉ cho bạn nguồn có thể trả lời câu hỏi của bạn.
Sự khác biệt có thể nằm ở cách tính toán sqrt và rsqrt. Bạn có thể đọc thêm tại đây http://www.intel.com/products/processor/manuals/ . Tôi khuyên bạn nên bắt đầu từ việc đọc các chức năng của bộ xử lý mà bạn đang sử dụng, có một số thông tin, đặc biệt là về rsqrt (cpu đang sử dụng bảng tra cứu nội bộ với giá trị xấp xỉ rất lớn, giúp việc lấy kết quả đơn giản hơn nhiều). Có vẻ như rsqrt nhanh hơn sqrt rất nhiều, nên 1 phép toán mul bổ sung (không tốn kém) có thể không thay đổi tình hình ở đây.

Chỉnh sửa: Một vài sự kiện có thể đáng nói:
1. Một khi tôi đang thực hiện một số tối ưu hóa vi mô cho thư viện đồ họa của mình và tôi đã sử dụng rsqrt để tính toán độ dài của vectơ. (thay vì sqrt, tôi đã nhân tổng bình phương của mình với rsqrt của nó, chính xác là những gì bạn đã làm trong các thử nghiệm của mình) và nó hoạt động tốt hơn.
2. Tính toán rsqrt bằng cách sử dụng bảng tra cứu đơn giản có thể dễ dàng hơn, như đối với rsqrt, khi x chuyển sang vô cùng, 1 / sqrt (x) chuyển sang 0, vì vậy đối với x nhỏ, các giá trị hàm không thay đổi (nhiều), trong khi đối với sqrt - nó đi đến vô cùng, vì vậy nó là trường hợp đơn giản;).

Ngoài ra, giải thích rõ: Tôi không chắc mình đã tìm thấy nó ở đâu trong những cuốn sách mà tôi đã liên kết, nhưng tôi khá chắc chắn rằng tôi đã đọc rằng rsqrt đang sử dụng một số bảng tra cứu và nó chỉ nên được sử dụng khi có kết quả không cần phải chính xác, mặc dù - tôi cũng có thể sai, vì nó đã xảy ra một thời gian trước đây :).

Newton-Raphson hội tụ về 0 f(x)bằng cách sử dụng gia số bằng với -f/f' nơif' là đạo hàm.

Đối với x=sqrt(y), bạn có thể cố gắng giải quyết f(x) = 0để xsử dụng f(x) = x^2 - y;

Sau đó, gia số là: dx = -f/f' = 1/2 (x - y/x) = 1/2 (x^2 - y) / x có sự phân chia chậm trong đó.

Bạn có thể thử các chức năng khác (như f(x) = 1/y - 1/x^2) nhưng chúng sẽ phức tạp không kém.

Hãy nhìn vào 1/sqrt(y)bây giờ. Bạn có thể thử f(x) = x^2 - 1/y, nhưng nó sẽ phức tạp không kém: dx = 2xy / (y*x^2 - 1)chẳng hạn. Một lựa chọn thay thế không rõ ràng f(x)là:f(x) = y - 1/x^2

Sau đó: dx = -f/f' = (y - 1/x^2) / (2/x^3) = 1/2 * x * (1 - y * x^2)

Ah! Đó không phải là một biểu thức tầm thường, nhưng bạn chỉ có phép nhân trong đó, không có phép chia. => Nhanh hơn!

Và: bước cập nhật đầy đủ new_x = x + dxsau đó đọc:

x *= 3/2 - y/2 * x * x mà cũng dễ dàng.

Có một số câu trả lời khác cho vấn đề này đã có từ vài năm trước. Đây là những gì mà sự đồng thuận đã đúng:

• Các lệnh rsqrt * tính toán một giá trị gần đúng với căn bậc hai nghịch đảo, tốt cho khoảng 11-12 bit.
• Nó được thực hiện với một bảng tra cứu (tức là một ROM) được lập chỉ mục bởi phần định trị. (Trên thực tế, đó là một bảng tra cứu nén, tương tự như các bảng toán học cũ, sử dụng các điều chỉnh đối với các bit bậc thấp để tiết kiệm trên các bóng bán dẫn.)
• Lý do tại sao nó có sẵn là vì nó là ước tính ban đầu được FPU sử dụng cho thuật toán căn bậc hai "thực".
• Ngoài ra còn có một lệnh tương hỗ gần đúng, rcp. Cả hai hướng dẫn này đều là manh mối về cách FPU triển khai căn bậc hai và phép chia.

Đây là những gì mà sự đồng thuận đã sai:

• Các FPU thời SSE không sử dụng Newton-Raphson để tính căn bậc hai. Đó là một phương pháp tuyệt vời trong phần mềm, nhưng sẽ là một sai lầm nếu thực hiện nó theo cách đó trong phần cứng.

Thuật toán NR để tính căn bậc hai đối ứng có bước cập nhật này, như những người khác đã lưu ý:

x' = 0.5 * x * (3 - n*x*x);

Đó là rất nhiều phép nhân phụ thuộc dữ liệu và một phép trừ.

Sau đây là thuật toán mà FPU hiện đại thực sự sử dụng.

Cho trước b[0] = n, giả sử chúng ta có thể tìm thấy một dãy số Y[i]sao cho b[n] = b[0] * Y[0]^2 * Y[1]^2 * ... * Y[n]^2gần bằng 1. Sau đó hãy xem xét:

x[n] = b[0] * Y[0] * Y[1] * ... * Y[n]
y[n] = Y[0] * Y[1] * ... * Y[n]

Rõ ràng x[n]cách tiếp cận sqrt(n)và y[n]phương pháp tiếp cận 1/sqrt(n).

Chúng ta có thể sử dụng bước cập nhật Newton-Raphson cho căn bậc hai nghịch đảo để có được Y[i]:

b[i] = b[i-1] * Y[i-1]^2
Y[i] = 0.5 * (3 - b[i])

Sau đó:

x[0] = n Y[0]
x[i] = x[i-1] * Y[i]

và:

y[0] = Y[0]
y[i] = y[i-1] * Y[i]

Quan sát quan trọng tiếp theo là đó b[i] = x[i-1] * y[i-1]. Vì thế:

Y[i] = 0.5 * (3 - x[i-1] * y[i-1])
     = 1 + 0.5 * (1 - x[i-1] * y[i-1])

Sau đó:

x[i] = x[i-1] * (1 + 0.5 * (1 - x[i-1] * y[i-1]))
     = x[i-1] + x[i-1] * 0.5 * (1 - x[i-1] * y[i-1]))
y[i] = y[i-1] * (1 + 0.5 * (1 - x[i-1] * y[i-1]))
     = y[i-1] + y[i-1] * 0.5 * (1 - x[i-1] * y[i-1]))

Tức là, với x và y ban đầu, chúng ta có thể sử dụng bước cập nhật sau:

r = 0.5 * (1 - x * y)
x' = x + x * r
y' = y + y * r

Hoặc, thậm chí lạ hơn, chúng tôi có thể đặt h = 0.5 * y. Đây là khởi tạo:

Y = approx_rsqrt(n)
x = Y * n
h = Y * 0.5

Và đây là bước cập nhật:

r = 0.5 - x * h
x' = x + x * r
h' = h + h * r

Đây là thuật toán của Goldschmidt và nó có một lợi thế rất lớn nếu bạn đang triển khai nó trong phần cứng: "vòng lặp bên trong" là ba phép nhân-cộng và không có gì khác, và hai trong số chúng là độc lập và có thể được kết nối.

Vào năm 1999, các FPU đã cần một mạch cộng / rút ngắn có trục và mạch nhân có trục, nếu không SSE sẽ không "phát trực tuyến" cho lắm. Chỉ cần một trong mỗi mạch vào năm 1999 để thực hiện vòng lặp bên trong này theo cách hoàn chỉnh mà không lãng phí nhiều phần cứng chỉ tính trên căn bậc hai.

Tất nhiên, hôm nay chúng ta đã kết hợp nhân-cộng tiếp xúc với lập trình viên. Một lần nữa, vòng lặp bên trong là ba FMA có trục, thường (một lần nữa) thường hữu ích ngay cả khi bạn không tính căn bậc hai.

Sẽ nhanh hơn vì hướng dẫn này bỏ qua các chế độ làm tròn và không xử lý các ngoại lệ của điểm floatin hoặc các số chuẩn hóa. Vì những lý do này, việc chuyển hướng, suy đoán và thực hiện lệnh fp khác không theo thứ tự dễ dàng hơn nhiều.