Có phải là một vấn đề để trở thành một lập trình viên không có kiến ​​thức về độ phức tạp tính toán?

Tôi đã được chỉ định một bài tập trong trường đại học của tôi. Tôi đoán nó về nhà và cố gắng lập trình một thuật toán để giải nó, nó là thứ gì đó liên quan đến đồ thị, tìm các thành phần được kết nối, tôi đoán vậy.

Sau đó, tôi đã làm những điều tầm thường nhất xuất hiện trong tâm trí của tôi và sau đó trình bày cho giảng viên của tôi. Sau khi quan sát ngắn, anh ta nhận thấy rằng độ phức tạp thời gian chạy của giải pháp của tôi là vô hình và cho thấy một cái gì đó hiệu quả hơn. Và có một truyền thống của các lập trình viên không có ý tưởng về độ phức tạp tính toán (tôi là một trong số đó), vậy có vấn đề gì không nếu một lập trình viên không biết gì về độ phức tạp tính toán?

Vâng, tôi sẽ nói rằng biết một cái gì đó về độ phức tạp tính toán là điều bắt buộc đối với bất kỳ lập trình viên nghiêm túc nào. Miễn là bạn không phải đối phó với các tập dữ liệu khổng lồ, bạn sẽ không biết sự phức tạp, nhưng nếu bạn muốn viết một chương trình giải quyết các vấn đề nghiêm trọng, bạn cần nó.

Trong trường hợp cụ thể của bạn, ví dụ về việc tìm các thành phần được kết nối của bạn có thể đã hoạt động cho các biểu đồ có thể nói lên tới nút. Tuy nhiên, nếu bạn đã thử một biểu đồ với nút thì thuật toán của giảng viên có thể đã quản lý được điều đó trong 1 giây, trong khi thuật toán của bạn sẽ có (tùy thuộc vào mức độ phức tạp của nó) mất 1 giờ, 1 ngày hoặc thậm chí là 1 vĩnh cửu.$100$$100.000$

Một lỗi khá phổ biến mà sinh viên mắc phải trong khóa học thuật toán của chúng tôi là lặp đi lặp lại qua một mảng như thế này:

while array not empty
    examine first element of array
    remove first element from array

Đây có thể không phải là mã đẹp nhất nhưng trong một chương trình phức tạp, một cái gì đó như thế này có thể xuất hiện mà không có lập trình viên nhận thức được nó. Bây giờ, vấn đề với chương trình này là gì?

Giả sử chúng ta chạy nó trên tập dữ liệu gồm phần tử. So với chương trình sau, chương trình cũ sẽ chạy chậm hơn.$100.000$$50.000$

while array not empty
    examine last element of array
    remove last element from array

Tôi hy vọng bạn đồng ý rằng có kiến ​​thức để làm cho chương trình của bạn chạy nhanh hơn lần có lẽ là một điều quan trọng đối với một lập trình viên. Hiểu được sự khác biệt giữa hai chương trình đòi hỏi một số kiến ​​thức cơ bản về lý thuyết phức tạp và một số kiến ​​thức về các chi tiết của ngôn ngữ bạn đang lập trình.$50.000$

Trong ngôn ngữ mã giả của tôi, "loại bỏ một phần tử khỏi một mảng" sẽ dịch chuyển tất cả các phần tử sang bên phải của phần tử được loại bỏ một vị trí từ bên trái. Điều này làm cho việc loại bỏ phần tử cuối cùng thành thao tác vì để thực hiện điều đó, chúng ta chỉ cần tương tác với 1 phần tử. Loại bỏ phần tử đầu tiên là vì để loại bỏ phần tử đầu tiên, chúng ta cần chuyển tất cả các phần tử khác sang một vị trí bên trái.O ( n ) n - $O(1)$$O(n)$$n-1$

Một bài tập rất cơ bản về độ phức tạp là chứng minh rằng chương trình đầu tiên sẽ thực hiện hoạt động trong khi chương trình thứ hai chỉ sử dụng thao tác. Nếu bạn cắm bạn sẽ thấy một chương trình hiệu quả hơn nhiều so với chương trình kia.nn=$\frac{1}{2}n^2$$n$$n=100.000$

Đây chỉ là một ví dụ về đồ chơi nhưng nó đòi hỏi sự hiểu biết cơ bản về độ phức tạp để phân biệt sự khác biệt giữa hai chương trình và nếu bạn thực sự đang cố gắng gỡ lỗi / tối ưu hóa một chương trình phức tạp hơn có lỗi này thì cần phải tìm hiểu nhiều hơn ra lỗi ở đâu Bởi vì một lỗi như loại bỏ một phần tử khỏi một mảng theo kiểu này có thể được ẩn rất tốt bởi sự trừu tượng trong mã.

Có một sự hiểu biết tốt về sự phức tạp cũng giúp ích khi so sánh hai cách tiếp cận để giải quyết vấn đề. Giả sử bạn đã tự mình đưa ra hai cách tiếp cận khác nhau để giải quyết vấn đề các thành phần được kết nối: để quyết định giữa chúng, sẽ rất hữu ích nếu bạn có thể (nhanh chóng) ước tính độ phức tạp của chúng và chọn phương án tốt hơn.

Đây là phản bác câu trả lời của Tom van der Zanden , trong đó tuyên bố rằng đây là điều bắt buộc.

Vấn đề là, hầu hết các lần, chậm hơn 50.000 lần không liên quan (tất nhiên trừ khi bạn làm việc tại Google).

Nếu thao tác bạn thực hiện mất một phần triệu giây hoặc nếu N của bạn không bao giờ vượt quá một ngưỡng nhất định (Một phần lớn mã hóa được thực hiện hiện nay) thì KHÔNG BAO GIỜ. Trong những trường hợp suy nghĩ về sự phức tạp tính toán sẽ chỉ khiến bạn lãng phí thời gian (và rất có thể là tiền).

Độ phức tạp tính toán là một công cụ để hiểu lý do tại sao một cái gì đó có thể chậm hoặc quy mô xấu, và làm thế nào để cải thiện nó, nhưng hầu hết thời gian là quá mức cần thiết.

Tôi đã là một lập trình viên chuyên nghiệp hơn năm năm nay và tôi chưa bao giờ thấy cần phải suy nghĩ về độ phức tạp tính toán khi lặp bên trong một vòng lặp O (M * N) bởi vì luôn luôn hoạt động rất nhanh hoặc M và N rất nhanh nhỏ bé.

Có nhiều thứ quan trọng hơn, thường được sử dụng và khó hiểu hơn đối với bất kỳ ai làm công việc lập trình (luồng và hồ sơ là những ví dụ tốt trong lĩnh vực hiệu suất).

Tất nhiên, có một số điều bạn sẽ không bao giờ có thể làm được nếu không hiểu độ phức tạp tính toán (ví dụ: tìm đảo chữ trên từ điển), nhưng hầu hết thời gian bạn không cần đến nó.

Tôi đã phát triển phần mềm trong khoảng ba mươi năm, làm việc như một nhà thầu và nhân viên, và tôi đã khá thành công với nó. Ngôn ngữ đầu tiên của tôi là BASIC, nhưng tôi đã nhanh chóng tự học ngôn ngữ máy móc để có được tốc độ tốt từ chiếc hộp không đủ sức mạnh của mình. Tôi đã dành rất nhiều thời gian trong các trình biên dịch trong những năm qua và đã học được rất nhiều về việc sản xuất mã được tối ưu hóa nhanh, hiệu quả bộ nhớ.

Bất kể nói gì, tôi tự dạy. Tôi chưa bao giờ gặp ký hiệu O cho đến khi tôi bắt đầu phỏng vấn vài năm trước. Nó không bao giờ xuất hiện trong công việc chuyên môn của tôi NGOẠI TRỪ trong các cuộc phỏng vấn. Vì vậy, tôi đã phải học những điều cơ bản chỉ để xử lý câu hỏi đó trong các cuộc phỏng vấn.

Tôi cảm thấy như nhạc sĩ jazz không thể đọc được nhạc. Tôi vẫn có thể chơi tốt. Tôi biết về hashtables (quái, tôi đã phát minh ra hashtables trước khi tôi biết rằng chúng đã được phát minh) và các cấu trúc dữ liệu quan trọng khác, và tôi thậm chí có thể biết một số thủ thuật mà chúng không dạy ở trường. Nhưng tôi nghĩ rằng sự thật là nếu bạn muốn thành công trong nghề này, bạn sẽ cần phải đi indie hoặc tìm hiểu câu trả lời cho các câu hỏi mà họ sẽ hỏi trong các cuộc phỏng vấn.

Tình cờ, gần đây nhất tôi đã phỏng vấn cho vai trò nhà phát triển web mặt trước. Họ hỏi tôi một câu hỏi trong đó câu trả lời đòi hỏi cả kiến ​​thức về độ phức tạp tính toán và logarit. Tôi đã xoay sở để nhớ đủ toán từ hai mươi năm trước để trả lời nó ít nhiều chính xác, nhưng nó hơi bị chói tai. Tôi chưa bao giờ phải sử dụng logarit trong bất kỳ sự phát triển mặt trước nào.

Chúc bạn may mắn!

Câu hỏi khá chủ quan, vì vậy tôi nghĩ rằng câu trả lời là tùy thuộc .

Sẽ không thành vấn đề nếu bạn làm việc với một lượng nhỏ dữ liệu. Trong những trường hợp này, thường sử dụng bất cứ điều gì, ví dụ như thư viện chuẩn của ngôn ngữ của bạn cung cấp.

Tuy nhiên, khi bạn xử lý một lượng lớn dữ liệu hoặc vì một số lý do khác mà bạn khăng khăng rằng chương trình của bạn nhanh, thì bạn phải hiểu độ phức tạp tính toán. Nếu bạn không, làm thế nào để bạn biết cách giải quyết vấn đề, hoặc thậm chí có thể giải quyết vấn đề đó nhanh đến mức nào? Nhưng chỉ hiểu lý thuyết là không đủ để trở thành một lập trình viên thực sự giỏi. Để tạo mã cực nhanh, tôi tin rằng, bạn cũng phải hiểu cách máy của bạn hoạt động (bộ nhớ cache, bố cục bộ nhớ, tập lệnh) và trình biên dịch của bạn làm gì (trình biên dịch làm tốt nhất, nhưng không hoàn hảo).

Tóm lại, tôi nghĩ rằng sự hiểu biết phức tạp rõ ràng làm cho bạn trở thành một lập trình viên tốt hơn.

Đó chắc chắn là một vấn đề nếu ai đó đang phát triển các thuật toán quan trọng không hiểu được độ phức tạp của thuật toán. Người dùng thuật toán thường dựa vào chất lượng thực hiện tốt có các đặc tính hiệu suất tốt. Mặc dù độ phức tạp không phải là yếu tố duy nhất đóng góp cho các đặc tính hiệu năng của thuật toán, nhưng nó là một yếu tố quan trọng. Một người không hiểu độ phức tạp của thuật toán sẽ ít có khả năng phát triển các thuật toán với các đặc tính hiệu suất hữu ích.

Nó ít gây ra vấn đề cho người dùng thuật toán, giả sử các thuật toán có sẵn có chất lượng tốt. Điều này đúng với các nhà phát triển sử dụng các ngôn ngữ có thư viện chuẩn, được chỉ định rõ ràng, được chỉ định - họ chỉ cần biết cách chọn một thuật toán đáp ứng nhu cầu đó. Vấn đề xuất hiện ở chỗ chúng là nhiều thuật toán thuộc một số loại (giả sử, sắp xếp) có sẵn trong một thư viện, bởi vì độ phức tạp thường là một trong những tiêu chí để chọn giữa. Một nhà phát triển không hiểu sự phức tạp thì không thể hiểu được cơ sở để chọn một thuật toán hiệu quả cho nhiệm vụ của họ.

Sau đó, có những nhà phát triển tập trung vào (vì muốn mô tả tốt hơn) những mối quan tâm phi thuật toán. Ví dụ, họ có thể tập trung vào phát triển giao diện người dùng trực quan. Các nhà phát triển như vậy thường sẽ không cần phải lo lắng về độ phức tạp của thuật toán mặc dù, một lần nữa, họ có thể dựa vào các thư viện hoặc mã khác được phát triển với chất lượng cao.

Nó phụ thuộc, nhưng không phụ thuộc vào lượng dữ liệu bạn đang làm việc, mà phụ thuộc vào loại công việc bạn làm, các chương trình bạn phát triển.

Chúng ta hãy gọi cho lập trình viên mà không biết về lập trình viên không phức tạp về khái niệm.

Các lập trình viên noobish có thể làm:

• phát triển cơ sở dữ liệu lớn - anh ta không cần phải biết cách thức hoạt động bên trong, tất cả những gì anh ta phải biết là các quy tắc về phát triển cơ sở dữ liệu. Anh ta biết những thứ như: những gì nên được lập chỉ mục, ... nơi tốt hơn là tạo ra sự dư thừa trong dữ liệu, nơi không ...
• làm trò chơi - anh ta chỉ cần nghiên cứu cách một số công cụ trò chơi hoạt động và tuân theo mô hình, trò chơi và đồ họa máy tính của nó là một vấn đề dữ liệu khá lớn. Xem xét 1920 * 1080 * 32bit = cca 7,9 MB cho một ảnh / khung hình duy nhất ... @ 60 FPS, tốc độ tối thiểu là 475 MB / s. Hãy xem xét, chỉ một bản sao không cần thiết của ảnh toàn màn hình sẽ lãng phí khoảng 500 MB thông lượng bộ nhớ mỗi giây. Nhưng, anh ta không cần quan tâm đến điều đó, vì anh ta chỉ sử dụng động cơ!

Các lập trình viên noobish không nên làm:

• phát triển các chương trình phức tạp được sử dụng rất thường xuyên, bất kể kích thước của dữ liệu mà nó hoạt động, ... ví dụ, dữ liệu nhỏ sẽ không gây ra tác động đáng chú ý của giải pháp không phù hợp trong quá trình phát triển, vì nó sẽ chậm hơn thời gian biên dịch, v.v. giây cho một chương trình đơn giản không phải là nhiều từ góc độ lập trình viên mới, Vâng, hãy xem xét máy chủ máy chủ, chạy chương trình này hai mươi lần mỗi giây. Nó sẽ đòi hỏi 10 lõi để có thể duy trì tải đó!
• phát triển các chương trình cho các thiết bị nhúng. Các thiết bị nhúng hoạt động với dữ liệu nhỏ, nhưng chúng cần phải hiệu quả nhất có thể, bởi vì các hoạt động dư thừa tạo ra sự tiêu hao năng lượng không cần thiết

Vì vậy, lập trình viên noobish là tốt, khi bạn muốn chỉ sử dụng công nghệ. Vì vậy, khi nói đến việc phát triển các giải pháp mới, công nghệ tùy chỉnh, v.v ... Vậy thì tốt hơn là thuê người lập trình không nũng nịu.

Tuy nhiên, nếu công ty không phát triển công nghệ mới, chỉ sử dụng những công nghệ đã được tạo ra. Sẽ thật lãng phí tài năng khi thuê lập trình viên giỏi và tài năng. Điều tương tự cũng áp dụng, nếu bạn không muốn làm việc trên các công nghệ mới và bạn sẽ ổn khi đưa ý tưởng của khách hàng vào các thiết kế và chương trình sử dụng các khung đã được tạo sẵn, thì sẽ lãng phí thời gian của bạn, để tìm hiểu thứ gì đó bạn sẽ không cần, ngoại trừ nếu đó là sở thích của bạn và bạn thích những thách thức logic.

Tôi hơi do dự khi viết một câu trả lời ở đây nhưng vì tôi thấy mình đang cảm thấy khó chịu với một số người khác [một số ý kiến ​​của tôi đã được chuyển sang trò chuyện], đây là cách tôi nhìn thấy nó ...

Có nhiều cấp độ / mức độ kiến ​​thức cho rất nhiều thứ trong điện toán (và theo thuật ngữ này, tôi muốn nói đại khái là sự kết hợp giữa khoa học máy tính với công nghệ thông tin). Độ phức tạp tính toán chắc chắn là một lĩnh vực rộng lớn (Bạn có biết OptP là gì không? Hoặc định lý Abiteboul-Vianu nói gì?) Và cũng thừa nhận rất nhiều chiều sâu: hầu hết những người có bằng CS không thể đưa ra bằng chứng chuyên môn đi vào nghiên cứu ấn phẩm trong tính phức tạp tính toán.

$n^2$

Tôi thực sự dám so sánh tình huống biết khi nào nên áp dụng các khái niệm phức tạp tính toán (và biết khi nào bạn có thể bỏ qua chúng một cách an toàn) với thực tiễn hơi phổ biến (bên ngoài thế giới Java) khi thực hiện một số mã nhạy cảm hiệu năng trong C và không nhạy cảm hiệu năng nội dung trong Python, v.v. (Như một bên, điều này được gọi trong Julia nói về "sự thỏa hiệp tiêu chuẩn" .) Biết khi nào bạn không phải nghĩ về hiệu suất giúp bạn tiết kiệm thời gian lập trình, đó cũng là một mặt hàng khá có giá trị.

Và một điểm nữa là việc biết độ phức tạp tính toán sẽ không tự động giúp bạn tối ưu hóa các chương trình; bạn cần hiểu thêm các công cụ liên quan đến kiến ​​trúc như cục bộ bộ đệm, [đôi khi] đường ống và ngày nay cũng lập trình song song / đa lõi; cái sau có cả lý thuyết phức tạp của riêng nó và những cân nhắc thực tế là tốt; một hương vị sau này từ một bài báo SOSP 2013 "Mọi kế hoạch khóa đều có mười lăm phút nổi tiếng. Không có chín kế hoạch khóa nào chúng tôi xem xét vượt trội so với bất kỳ kiến ​​trúc nào khác, trên tất cả các kiến ​​trúc mục tiêu hoặc khối lượng công việc. Nói đúng ra, để tìm kiếm sự tối ưu, một Do đó, nên chọn thuật toán khóa dựa trên nền tảng phần cứng và khối lượng công việc dự kiến. "

Nếu bạn không biết big-O, bạn nên học nó. Nó không khó, và nó thực sự hữu ích. Bắt đầu với việc tìm kiếm và sắp xếp.

Tôi nhận thấy rằng rất nhiều câu trả lời và nhận xét đề nghị hồ sơ , và hầu như chúng luôn có nghĩa là sử dụng một công cụ định hình .

Vấn đề là, các công cụ định hình trên khắp bản đồ về mức độ hiệu quả của chúng để tìm kiếm những gì bạn cần để tăng tốc. Ở đây tôi đã liệt kê và giải thích những quan niệm sai lầm mà các trình hồ sơ mắc phải.

Kết quả là các chương trình, nếu chúng lớn hơn một bài tập học thuật, có thể chứa những người khổng lồ đang ngủ , mà ngay cả trình hồ sơ tự động tốt nhất cũng không thể lộ ra. Bài đăng này cho thấy một vài ví dụ về cách các vấn đề hiệu suất có thể ẩn khỏi trình biên dịch.

Nhưng họ không thể trốn tránh kỹ thuật này.