Làm thế nào để nâng cao hiệu quả với lập trình chức năng?

Gần đây tôi đã trải qua Hướng dẫn tìm hiểu về bạn rất tốt và vì thực tế tôi muốn giải quyết vấn đề Project Euler 5 với nó, trong đó chỉ rõ:

Số dương nhỏ nhất chia hết cho tất cả các số từ 1 đến 20 là bao nhiêu?

Trước tiên tôi quyết định viết một hàm xác định xem một số đã cho có chia hết cho các số này không:

divisable x = all (\y -> x `mod` y == 0)[1..20]

Sau đó, tôi tính toán nhỏ nhất bằng cách sử dụng head:

sm = head [x | x <- [1..], divisable x]

Và cuối cùng đã viết dòng để hiển thị kết quả:

main = putStrLn $ show $ sm

Thật không may, điều này mất khoảng 30 giây để hoàn thành. Làm điều tương tự với các số từ 1 đến 10 mang lại kết quả gần như ngay lập tức, nhưng sau đó, kết quả lại nhỏ hơn nhiều so với giải pháp cho 1 đến 20.

Tôi đã giải quyết nó sớm hơn trong C và kết quả từ 1 đến 20 cũng được tính gần như ngay lập tức. Điều này khiến tôi tin rằng tôi đang hiểu sai cách giải thích vấn đề này cho Haskell. Tôi đã xem qua các giải pháp của người khác và thấy điều này:

main = putStrLn $ show $ foldl1 lcm [1..20]

Đủ công bằng, điều này sử dụng một chức năng tích hợp, nhưng tại sao kết quả cuối cùng lại chậm hơn rất nhiều khi tự làm điều đó? Các hướng dẫn ngoài kia cho bạn biết cách sử dụng Haskell, nhưng tôi không thấy nhiều trợ giúp với việc chuyển đổi thuật toán thành mã nhanh.

Trước tiên, bạn cần chắc chắn rằng bạn có một nhị phân được tối ưu hóa, trước khi nghĩ rằng ngôn ngữ là vấn đề. Đọc chương Profiling và tối ưu hóa trong Real Wolrd Haskell. Điều đáng chú ý là trong hầu hết các trường hợp, bản chất cấp cao của ngôn ngữ khiến bạn mất ít nhất một phần hiệu suất.

Tuy nhiên, lưu ý rằng giải pháp khác không nhanh hơn vì nó sử dụng hàm tích hợp, mà đơn giản là vì nó sử dụng thuật toán nhanh hơn nhiều : để tìm bội số chung nhỏ nhất của một tập hợp số bạn chỉ cần tìm một vài GCD. So sánh điều này với giải pháp của bạn, mà chu kỳ thông qua tất cả các số từ 1 đến foldl lcm [1..20]. Nếu bạn thử với 30, sự khác biệt giữa thời gian chạy sẽ còn lớn hơn.

Hãy xem sự phức tạp: thuật toán của bạn có O(ans*N)thời gian chạy, đâu anslà câu trả lời và Nlà con số mà bạn đang kiểm tra tính phân chia (20 trong trường hợp của bạn). Tuy nhiên ,
thuật toán khác thực thi Nlần và GCD có độ phức tạp . Do đó thuật toán thứ hai có độ phức tạp . Bạn có thể đánh giá cho mình cái nào nhanh hơn.lcmlcm(a,b) = a*b/gcd(a,b)O(log(max(a,b)))O(N*log(ans))

Vì vậy, để tóm tắt:
Vấn đề của bạn là thuật toán của bạn, không phải ngôn ngữ.

Lưu ý rằng có những ngôn ngữ chuyên ngành vừa có chức năng vừa tập trung vào các chương trình nặng về toán học, như Mathematica, đối với các bài toán tập trung vào toán học có lẽ nhanh hơn hầu hết mọi thứ khác. Nó có một thư viện các chức năng rất được tối ưu hóa, và nó hỗ trợ mô hình chức năng (phải thừa nhận rằng nó cũng hỗ trợ lập trình bắt buộc).

Suy nghĩ đầu tiên của tôi là chỉ các số chia hết cho tất cả các số nguyên tố <= 20 sẽ chia hết cho tất cả các số nhỏ hơn 20. Vì vậy, bạn chỉ cần xem xét các số là bội số của 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 . Một giải pháp như vậy kiểm tra 1 / 9.699.690 số lượng nhiều như cách tiếp cận vũ phu. Nhưng giải pháp Haskell nhanh của bạn làm tốt hơn thế.

Nếu tôi hiểu giải pháp "Haskell nhanh", nó sử dụng Foldl1 để áp dụng hàm lcm (bội số chung nhỏ nhất) cho danh sách các số từ 1 đến 20. Vì vậy, nó sẽ áp dụng lcm 1 2, mang lại 2. Sau đó lcm 2 3 mang lại 6 Sau đó lcm 6 4 mang lại 12, và cứ thế. Theo cách này, hàm lcm chỉ được gọi 19 lần để mang lại câu trả lời của bạn. Trong ký hiệu Big O, đó là các hoạt động O (n-1) để đi đến một giải pháp.

Giải pháp Haskell chậm của bạn đi qua các số từ 1-20 cho mỗi số từ 1 đến giải pháp của bạn. Nếu chúng ta gọi giải pháp s, thì giải pháp Haskell chậm thực hiện các hoạt động O (s * n). Chúng tôi đã biết rằng s là hơn 9 triệu, vì vậy có lẽ giải thích sự chậm chạp. Ngay cả khi tất cả các phím tắt và nhận được trung bình một nửa trong danh sách các số 1-20, thì đó vẫn chỉ là O (s * n / 2).

Gọi điện headkhông cứu bạn khỏi việc thực hiện các tính toán này, chúng phải được thực hiện để tính toán giải pháp đầu tiên.

Cảm ơn, đây là một câu hỏi thú vị. Nó thực sự kéo dài kiến ​​thức Haskell của tôi. Tôi hoàn toàn không thể trả lời nếu tôi không nghiên cứu thuật toán vào mùa thu năm ngoái.

Ban đầu tôi không định viết một câu trả lời. Nhưng tôi đã được thông báo sau khi một người dùng khác đưa ra tuyên bố kỳ lạ rằng chỉ cần nhân các số nguyên tố cặp đầu tiên sẽ tốn kém hơn về mặt tính toán sau đó liên tục áp dụng lcm. Vì vậy, đây là hai thuật toán và một số điểm chuẩn:

Thuật toán của tôi:

Thuật toán tạo tướng, cho tôi một danh sách vô hạn các số nguyên tố.

isPrime :: Int -> Bool
isPrime 1 = False
isPrime n = all ((/= 0) . mod n) (takeWhile ((<= n) . (^ 2)) primes)

toPrime :: Int -> Int
toPrime n 
    | isPrime n = n 
    | otherwise = toPrime (n + 1)

primes :: [Int]
primes = 2 : map (toPrime . (+ 1)) primes

Bây giờ sử dụng danh sách nguyên tố đó để tính kết quả cho một số N:

solvePrime :: Integer -> Integer
solvePrime n = foldl' (*) 1 $ takeWhile (<= n) (fromIntegral <$> primes)

Bây giờ thuật toán dựa trên lcm khác, được thừa nhận là khá ngắn gọn, chủ yếu là do tôi đã triển khai thế hệ chính từ đầu (và không sử dụng thuật toán hiểu danh sách siêu súc tích do hiệu suất kém) trong khi lcmchỉ được nhập từ Prelude.

solveLcm :: Integer -> Integer
solveLcm n = foldl' (flip lcm) 1 [2 .. n]
-- Much slower without `flip` on `lcm`

Bây giờ đối với điểm chuẩn, mã tôi sử dụng cho mỗi mã rất đơn giản: ( -prof -fprof-auto -O2sau đó +RTS -p)

main :: IO ()
main = print $ solvePrime n
-- OR
main = print $ solveLcm n

Đối với n = 100,000, solvePrime:

total time = 0.04 secs
total alloc = 108,327,328 bytes

vs solveLcm:

total time = 0.12 secs
total alloc = 117,842,152 bytes

Đối với n = 1,000,000, solvePrime:

total time = 1.21 secs
total alloc = 8,846,768,456 bytes

vs solveLcm:

total time = 9.10 secs
total alloc = 8,963,508,416 bytes

Đối với n = 3,000,000, solvePrime:

total time = 8.99 secs
total alloc = 74,790,070,088 bytes

vs solveLcm:

total time = 86.42 secs
total alloc = 75,145,302,416 bytes

Tôi nghĩ rằng kết quả nói cho chính họ.

Trình lược tả biểu thị thế hệ nguyên tố chiếm tỷ lệ phần trăm nhỏ hơn và nhỏ hơn của thời gian chạy khi ntăng. Vì vậy, nó không phải là nút cổ chai, vì vậy chúng ta có thể bỏ qua nó ngay bây giờ.

Điều này có nghĩa là chúng tôi thực sự so sánh việc gọi lcmnơi một đối số đi từ 1 đến nvà đối số khác đi theo hình học từ 1 đến ans. Để gọi *với tình huống tương tự và lợi ích gia tăng của việc bỏ qua mọi số không phải là số nguyên tố (không có triệu chứng miễn phí, do tính chất đắt hơn của *).

Và nó được biết đến *là nhanh hơn lcm, như lcmyêu cầu các ứng dụng lặp đi lặp lại mod, và modchậm hơn bất thường ( O(n^2)vs ~O(n^1.5)).

Vì vậy, các kết quả trên và phân tích thuật toán ngắn gọn sẽ làm cho nó rất rõ ràng thuật toán nào nhanh hơn.