Apakah masalah menjadi seorang programmer tanpa pengetahuan tentang kompleksitas komputasi?


30

Saya ditugaskan latihan di universitas saya. Saya membawanya pulang dan mencoba memprogram algoritma untuk menyelesaikannya, itu adalah sesuatu yang berhubungan dengan grafik, menemukan komponen yang terhubung, saya kira.

Kemudian saya membuat hal paling sepele yang muncul di benak saya dan kemudian ditunjukkan kepada dosen saya. Setelah pengamatan singkat, ia merasa bahwa kompleksitas runtime dari solusi saya tidak dapat diganggu gugat dan menunjukkan sesuatu yang lebih efisien. Dan ada tradisi programmer yang tidak tahu apa itu kompleksitas komputasi (saya salah satunya), jadi apakah itu masalah jika programmer tidak tahu apa itu kompleksitas komputasi?


3
Pemberitahuan moderator : tolong jangan gunakan komentar untuk diskusi panjang atau untuk mengirim jawaban bernas. Anda dapat menggunakan ruang obrolan untuk membahas pertanyaan ini; komentar sebelumnya telah dipindahkan ke sana.
Gilles 'SO- stop being evil'

4
Judul Anda mengatakan programmer, tetapi pertanyaan Anda mengatakan siswa. Umumnya 'programmer' menyiratkan 'programmer profesional' - jadi apakah Anda bertanya apakah itu masalah untuk menjadi programmer profesional tanpa pengetahuan tentang kompleksitas komputasi? Atau apakah tidak apa-apa bagi siswa pemrograman untuk tidak memiliki pengetahuan itu? Keduanya adalah pertanyaan yang berbeda, walaupun ternyata mereka memiliki jawaban yang sama.
corsiKa

Jawaban:


42

Ya, saya akan mengatakan mengetahui sesuatu tentang kompleksitas komputasi adalah suatu keharusan bagi setiap programmer yang serius. Selama Anda tidak berurusan dengan kumpulan data besar, Anda akan baik-baik saja tanpa mengetahui kompleksitas, tetapi jika Anda ingin menulis sebuah program yang menangani masalah serius, Anda memerlukannya.

Dalam kasus khusus Anda, contoh Anda menemukan komponen yang terhubung mungkin telah bekerja untuk grafik hingga mengatakan node. Namun, jika Anda mencoba grafik dengan 100.000100100.000 node maka algoritma dosen Anda mungkin akan mengaturnya dalam 1 detik, sedangkan algoritma Anda akan (tergantung pada seberapa buruk kompleksitasnya) diambil 1 jam, 1 hari, atau mungkin bahkan 1 keabadian.

Kesalahan yang agak umum dilakukan oleh siswa dalam kursus algoritme kami adalah beralih ke array seperti ini:

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

Ini mungkin bukan kode yang paling indah tetapi dalam program yang rumit sesuatu seperti ini mungkin muncul tanpa disadari oleh programmer. Sekarang, apa masalahnya dengan program ini?

Misalkan kita menjalankannya pada kumpulan data elemen. Dibandingkan dengan program berikut, program sebelumnya akan berjalan 50.000 lebih lambat.100.00050.000

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

Saya harap Anda setuju bahwa memiliki pengetahuan untuk membuat program Anda berjalan kali lebih cepat mungkin merupakan hal penting bagi seorang programmer. Memahami perbedaan antara kedua program tersebut membutuhkan beberapa pengetahuan dasar tentang teori kompleksitas dan beberapa pengetahuan tentang rincian bahasa tempat Anda pemrograman.50.000

Dalam bahasa kode pseudocode saya, "menghapus elemen dari array" menggeser semua elemen ke kanan elemen yang dihapus satu posisi dari kiri. Ini membuat menghapus elemen terakhir menjadi operasi karena untuk melakukan itu kita hanya perlu berinteraksi dengan 1 elemen. Menghapus elemen pertama adalah O ( n ) karena untuk menghapus elemen pertama kita perlu menggeser semua yang lain n - 1O(1)O(n)n1 satu posisi ke kiri juga.

Latihan yang sangat mendasar dalam kompleksitas adalah untuk membuktikan bahwa program pertama akan melakukan operasi sedangkan program kedua hanya menggunakannoperasi. Jika Anda memasukkann=100.000Anda akan melihat satu program secara drastis lebih efisien daripada yang lain.12n2nn=100.000

Ini hanya contoh mainan tetapi sudah membutuhkan pemahaman dasar tentang kompleksitas untuk membedakan antara kedua program, dan jika Anda benar-benar mencoba untuk men-debug / mengoptimalkan program yang lebih rumit yang memiliki kesalahan ini, dibutuhkan pemahaman yang lebih besar untuk menemukan di mana bug itu. Karena kesalahan seperti menghapus elemen dari array dengan cara ini dapat disembunyikan dengan sangat baik oleh abstraksi dalam kode.

Memiliki pemahaman yang baik tentang kompleksitas juga membantu ketika membandingkan dua pendekatan untuk menyelesaikan masalah. Misalkan Anda telah datang dengan dua pendekatan berbeda untuk memecahkan masalah komponen yang terhubung pada Anda sendiri: untuk memutuskan di antara mereka akan sangat berguna jika Anda dapat (dengan cepat) memperkirakan kerumitan mereka dan memilih yang lebih baik.


10
"So long as you are not dealing with huge data sets you will be fine not knowing complexity"Ini sering benar, tetapi tidak selalu demikian. Misalnya, suatu O(n!)algoritma tidak akan dapat digunakan bahkan untuk set data yang relatif kecil. Jika Anda menggunakan O(n!)algoritma di mana Anda bisa menggunakan O(n^2)program Anda akan memakan waktu 36.288 kali lebih lama untuk dieksekusi pada ukuran data 10 . Pada ukuran data 20, Anda melihat 2,4 triliun operasi.
reirab

1
Saya pikir contoh @ reirab harus dimasukkan dalam jawaban. Itu lebih dramatis dan membuktikan poin Anda lebih tegas. Dan saya pribadi telah digigit oleh algoritma seperti itu, sebelum saya belajar kompleksitas komputasi.
Siyuan Ren

2
Saya pikir ada masalah yang lebih besar. Jika Anda tidak tahu Anda memilih sendiri untuk tugas-tugas di mana ini tidak diperlukan. Jadi Anda bisa mengatakan hampir semua pertanyaan yang perlu saya ketahui X berakhir dengan, mungkin berguna. Jadi terlepas dari apakah kritis itu masih baik untuk diketahui atau mungkin akan menggigit Anda pada akhirnya.
joojaa

"Memahami perbedaan antara kedua program membutuhkan pengetahuan dasar tentang teori kompleksitas" - Saya pikir untuk contoh khusus ini tidak. Anda dapat memprofilkannya, mengamati bahwa semua waktu diambil dalam "menghapus elemen", tahu (tanpa memahami teori kompleksitas) bahwa menghapus elemen terakhir lebih cepat daripada menghapus yang pertama, membuat perubahan, dan karena itu mempercepat program. Keuntungan dari memahami teori kompleksitas adalah bahwa ia memungkinkan Anda untuk secara kuantitas mengurangi masalah-masalah seperti itu tanpa membuat profil, sehingga Anda dapat "mengoptimalkan secara prematur".
Steve Jessop

... dan secara umum saya menduga bahwa semua atau hampir semua contoh praktis dapat diselesaikan, satu per satu, tanpa mengacu pada teori kompleksitas. Dalam hal ini, mengetahui bahwa menyalin banyak data lebih lambat daripada tidak melakukannya, bukanlah "teori kompleksitas". Tetapi tentu saja masih berguna dalam pemrograman (dan profesi apa pun) untuk memiliki model mental yang baik dari prinsip-prinsip yang biasa muncul, karena Anda dapat menganalisis, mendiskusikan, dan menyelesaikan masalah seperti itu secara rutin dengan prinsip alih-alih satu per satu dengan cara ad hoc.
Steve Jessop

26

Ini adalah bantahan dari jawaban Tom van der Zanden , yang menyatakan bahwa ini adalah suatu keharusan.

Masalahnya, 50.000 kali lebih lambat tidak relevan (kecuali Anda bekerja di Google tentu saja).

Jika operasi yang Anda lakukan membutuhkan mikrodetik atau jika N Anda tidak pernah di atas ambang batas tertentu (Sebagian besar pengkodean dilakukan saat ini) itu tidak akan PERNAH menjadi masalah. Dalam kasus tersebut, berpikir tentang kompleksitas komputasi hanya akan membuat Anda membuang waktu (dan kemungkinan besar uang).

Kompleksitas komputasi adalah alat untuk memahami mengapa sesuatu mungkin lambat atau skala buruk, dan bagaimana cara memperbaikinya, tetapi sebagian besar waktu adalah sepenuhnya berlebihan.

Saya telah menjadi programmer profesional selama lebih dari lima tahun sekarang dan saya tidak pernah menemukan kebutuhan untuk berpikir tentang kompleksitas komputasi ketika looping di dalam loop O (M * N) karena selalu operasi sangat cepat atau M dan N begitu kecil.

Ada hal-hal yang jauh lebih penting, umum digunakan, dan lebih sulit untuk dipahami oleh siapa pun yang melakukan pekerjaan pemrograman (threading dan profiling adalah contoh yang baik di bidang kinerja).

Tentu saja, ada beberapa hal yang tidak akan pernah bisa Anda lakukan tanpa memahami kompleksitas komputasi (misalnya: menemukan anagram pada kamus), tetapi sebagian besar waktu Anda tidak membutuhkannya.


3
Untuk memperluas pada poin Anda, ada kasus di mana terlalu banyak penekanan pada kompleksitas komputasi dapat membuat Anda tersesat. Misalnya, mungkin ada situasi di mana algoritma "lebih baik" sebenarnya lebih lambat untuk input kecil. Profiler adalah sumber utama kebenaran.
Kevin Krumwiede

2
@Kevin Krumwiede, saya sepenuhnya setuju dengan Anda bahwa mengoptimalkan pengurutan untuk satu set data sepele adalah berlebihan. Tetapi juga menggambarkan bahwa memiliki setidaknya pemahaman tentang kompleksitas masih penting. Pemahaman inilah yang akan menuntun Anda untuk membuat keputusan bahwa semacam gelembung sesuai sebagai lawan dari beberapa algoritma lain yang lebih kompleks.
Kent A.

4
Ketika Anda tahu set data kecil dalam semua kasus, Anda bisa lolos dengan hal semacam ini. Anda harus sangat berhati-hati terhadap kompleksitas berlebih dalam hal-hal yang disebut dalam loop, meskipun - belum lama ini saya memotong runtime menit ke detik dengan cara ini. Saya juga mengalami masalah O (n ^ 8) satu kali (validasi data.) Banyak perawatan yang menyelesaikannya hingga 12 jam.
Loren Pechtel

7
Saya tidak pernah menemukan kebutuhan untuk berpikir tentang kompleksitas komputasi ketika perulangan di dalam lingkaran O (M * N) karena selalu operasi sangat cepat atau M dan N sangat kecil. - Ironisnya, argumen yang Anda berikan menunjukkan bahwa Anda memang memikirkan kompleksitas komputasi. Anda memutuskan bahwa itu bukan masalah yang relevan untuk apa yang Anda lakukan dan mungkin memang seharusnya demikian, tetapi Anda masih sadar akan keberadaan masalah ini, dan jika itu akan menimbulkan masalah, Anda bisa bereaksi sebelum masalah serius terjadi pada tingkat pengguna.
Wrzlprmft

4
Optimalisasi prematur adalah akar dari semua kejahatan, tetapi pesimisasi prematur adalah akar dari setidaknya sebagian besar pengguna yang terganggu. Anda mungkin tidak perlu bisa menyelesaikan hubungan perulangan, tetapi jika Anda, paling tidak, tidak mampu membedakan antara O (1), O (N) dan O (N ^ 2), terutama ketika Anda Ada loop bersarang, seseorang harus membersihkan kekacauan nanti. Sumber: kekacauan yang harus saya bersihkan nanti. Faktor 50.000 sangat besar sehingga Anda sebaiknya tahu apakah Anda masih mampu membelinya nanti , ketika input Anda bertambah.
Jeroen Mostert

14

Saya telah mengembangkan perangkat lunak selama sekitar tiga puluh tahun, bekerja sebagai kontraktor dan karyawan, dan saya cukup sukses dalam hal itu. Bahasa pertama saya adalah BASIC, tetapi saya dengan cepat belajar sendiri bahasa mesin untuk mendapatkan kecepatan yang layak dari kotak saya yang kurang bertenaga. Saya telah menghabiskan banyak waktu di profiler selama bertahun-tahun dan telah belajar banyak tentang menghasilkan kode yang dioptimalkan dengan cepat dan efisien memori.

Terlepas dari mengatakan, saya belajar sendiri. Saya tidak pernah menemukan notasi O sampai saya mulai mewawancarai beberapa tahun yang lalu. Tidak pernah muncul dalam pekerjaan profesional saya KECUALI selama wawancara. Jadi saya harus mempelajari dasar-dasarnya hanya untuk menangani pertanyaan itu dalam wawancara.

Saya merasa seperti musisi jazz yang tidak bisa membaca lembaran musik. Saya masih bisa bermain dengan baik. Saya tahu tentang hashtable (huh, saya menemukan hashtable sebelum saya tahu bahwa itu sudah ditemukan) dan struktur data penting lainnya, dan saya bahkan mungkin tahu beberapa trik yang tidak mereka ajarkan di sekolah. Tetapi saya pikir kebenarannya adalah jika Anda ingin sukses dalam profesi ini, Anda harus masuk indie atau mempelajari jawaban atas pertanyaan yang akan mereka tanyakan selama wawancara.

Kebetulan, saya baru-baru ini mewawancarai untuk peran pengembang web ujung depan. Mereka mengajukan pertanyaan kepada saya di mana jawabannya membutuhkan pengetahuan tentang kompleksitas komputasi dan logaritma. Saya berhasil mengingat cukup matematika dari dua puluh tahun yang lalu untuk menjawabnya kurang lebih dengan benar, tetapi itu agak menggelegar. Saya tidak pernah harus menggunakan logaritma dalam pengembangan front end.

Semoga beruntung untukmu!


2
Jadi, jawaban Anda adalah "ya"?
Raphael

6
TL; DR: "ya". Namun, dalam pengalaman saya, Anda tidak akan berbicara tentang kompleksitas komputasi di sebagian besar pekerjaan setelah Anda direkrut. Ya, ketahuilah struktur data Anda dan kinerjanya, tetapi hanya dengan mengetahui bahwa suatu algoritma adalah O (n) atau apa pun yang tidak dibuat oleh programmer yang baik. Jauh lebih baik untuk fokus menulis kode yang baik dengan cepat dan kemudian mengoptimalkan hot spot nanti. Keterbacaan dan pemeliharaan biasanya lebih penting untuk sebagian besar kode daripada kinerja.
Scott Schafer

3
Saya pikir itu mungkin terjadi bahwa kompleksitas muncul dalam pengaturan perusahaan, tetapi perhatian nyata pertama bagi perusahaan adalah pengiriman : jika berfungsi, itu cukup baik, sampai ada anggaran yang tersedia untuk meningkatkan aplikasi, atau pelanggan kembali untuk mengeluh tentang buruk pertunjukan. Dalam situasi b2b untuk proyek adhoc, itu mungkin sangat jarang. Dalam b2c, atau di pasar yang sangat kompetitif (produk rak), mungkin akan lebih sering muncul, dengan efek langsung menaikkan bar entri untuk karyawan baru.
didierc

4
@didierc "Cukup bagus" juga yang memecahkan banyak hal.
Raphael

1
@didierc 1) Nah, orang-orang dengan latar belakang yang kuat di CS melakukan (semoga) memiliki intuisi yang baik untuk apa yang benar dan yang tidak, sedangkan pemecah masalah ad-hoc dapat melakukan kesalahan "sederhana". Memastikan bahwa eksekusi setelah banyak kompilasi persis apa yang ditetapkan sangat non-sepele, dan afaik masalah yang belum terpecahkan. 2) Tidak .
Raphael

9

Pertanyaannya cukup subyektif, jadi saya pikir jawabannya tergantung .

Tidak masalah jika Anda bekerja dengan sejumlah kecil data. Dalam kasus ini, biasanya baik-baik saja untuk menggunakan apa pun misalnya perpustakaan standar yang ditawarkan bahasa Anda.

Namun, ketika Anda berurusan dengan sejumlah besar data, atau karena alasan lain Anda bersikeras bahwa program Anda cepat, maka Anda harus memahami kompleksitas komputasi. Jika tidak, bagaimana Anda tahu bagaimana masalah harus diselesaikan, atau seberapa cepat bahkan mungkin untuk menyelesaikannya? Tetapi memahami teori saja tidak cukup untuk menjadi programmer yang benar-benar baik. Untuk menghasilkan kode yang sangat cepat, saya percaya, Anda juga harus memahami bagaimana misalnya mesin Anda bekerja (cache, tata letak memori, set instruksi), dan apa yang dilakukan kompiler Anda (kompiler melakukan yang terbaik, tetapi tidak sempurna).

Singkatnya, saya pikir memahami kompleksitas dengan jelas membuat Anda seorang programmer yang lebih baik.


1
Saya pikir Anda umumnya memiliki ide yang benar, tetapi "subyektif" tidak menggambarkan masalah ini secara memadai; "keadaan" akan menjadi kata yang lebih baik. Namun, seseorang dapat menulis program yang sangat lambat yang tidak beroperasi pada banyak data. Baru-baru ini saya menjawab pertanyaan tentang math.se tentang representasi / penyimpanan polinomial. Itu biasanya melibatkan sejumlah kecil data misalnya ~ polinomial 1000-term adalah tipikal; namun ada perbedaan besar dalam dunia nyata dalam kinerja (ratusan atau ribuan detik vs beberapa detik untuk multiplikasi) tergantung pada implementasinya.
Fizz

4

Ini tentu menjadi masalah jika seseorang yang mengembangkan algoritma signifikan tidak memahami kompleksitas algoritma. Pengguna suatu algoritma umumnya mengandalkan kualitas implementasi yang baik yang memiliki karakteristik kinerja yang baik. Meskipun kompleksitas bukan satu-satunya penyumbang karakteristik kinerja suatu algoritma, itu adalah kompleksitas yang signifikan. Seseorang yang tidak memahami kompleksitas algoritma cenderung mengembangkan algoritma dengan karakteristik kinerja yang bermanfaat.

Ini kurang masalah bagi pengguna suatu algoritma, dengan asumsi algoritma yang tersedia berkualitas baik. Ini berlaku untuk pengembang yang menggunakan bahasa yang memiliki pustaka standar yang signifikan, ditentukan dengan baik, standar - mereka hanya perlu tahu cara memilih algoritma yang memenuhi kebutuhan di sana. Masalahnya adalah di mana mereka adalah beberapa algoritma dari beberapa jenis (katakanlah, penyortiran) tersedia dalam perpustakaan, karena kompleksitas sering menjadi salah satu kriteria untuk memilih di antaranya. Pengembang yang tidak memahami kompleksitas kemudian tidak dapat memahami dasar untuk memilih algoritma yang efektif untuk tugas mereka.

Lalu ada pengembang yang fokus pada (karena ingin deskripsi yang lebih baik) masalah non-algoritmik. Misalnya, mereka dapat fokus pada pengembangan antarmuka pengguna yang intuitif. Pengembang seperti itu sering tidak perlu khawatir tentang kompleksitas algoritma meskipun, sekali lagi, mereka mungkin bergantung pada perpustakaan atau kode lain yang sedang dikembangkan dengan kualitas tinggi.


3

Itu tergantung, tetapi bukan pada jumlah data yang Anda kerjakan, tetapi pada jenis pekerjaan yang Anda lakukan, program yang Anda kembangkan.

Mari kita panggil programmer yang tidak tahu tentang kompleksitas konseptual noobish programmer.

Pemrogram noobish dapat melakukan:

  • mengembangkan database data besar - dia tidak harus tahu cara kerjanya di dalam, semua yang dia harus tahu adalah aturan tentang pengembangan database. Dia tahu hal-hal seperti: apa yang harus diindeks, ... di mana lebih baik untuk membuat redundansi dalam data, di mana itu tidak ...
  • membuat game - dia hanya harus mempelajari bagaimana beberapa mesin game bekerja dan mengikuti paradigma, game dan grafik komputer adalah masalah data yang cukup besar. Pertimbangkan 1920 * 1080 * 32bit = cca 7.9MB untuk gambar / bingkai tunggal ... @ 60 FPS setidaknya 475MB / s. Pertimbangkan, bahwa hanya satu salinan gambar layar penuh yang tidak perlu akan menghabiskan sekitar 500 MB memori throughput per detik. Tapi, dia tidak perlu peduli tentang itu, karena dia hanya menggunakan mesin!

Programmer noobish seharusnya tidak melakukan:

  • mengembangkan program kompleks yang sangat sering digunakan, tidak peduli ukuran data yang digunakannya, ... misalnya, data kecil tidak akan menyebabkan dampak nyata dari solusi yang tidak tepat selama pengembangan, karena akan lebih lambat daripada waktu kompilasi, dll. Jadi, 0,5 detik untuk satu program sederhana tidak banyak dari perspektif programmer noobish, Nah, pertimbangkan server server, yang menjalankan program ini dua puluh kali per detik. Dibutuhkan 10 nilai untuk dapat mempertahankan beban itu!
  • mengembangkan program untuk perangkat tertanam. Perangkat yang disematkan bekerja dengan data kecil, tetapi mereka harus seefisien mungkin, karena operasi yang berlebihan membuat konsumsi daya yang tidak perlu

Jadi, programmer noobish baik-baik saja, ketika Anda hanya ingin menggunakan teknologi. Jadi, ketika datang ke pengembangan solusi baru, teknologi khusus, dll. Maka lebih baik untuk mempekerjakan programmer tidak noobish.

Namun, jika perusahaan tidak mengembangkan teknologi baru, gunakan saja yang sudah dibuat. Membuang bakat untuk merekrut programmer yang terampil dan berbakat. Hal yang sama berlaku, jika Anda tidak ingin bekerja pada teknologi baru dan Anda baik-baik saja menempatkan ide pelanggan ke dalam desain dan program menggunakan kerangka kerja yang sudah dibuat, maka buang-buang waktu Anda, untuk mempelajari sesuatu yang Anda tidak akan pernah perlu, kecuali jika itu hobi Anda dan Anda suka tantangan logis.


1
Jawaban ini dapat ditingkatkan jika menggunakan label yang lebih netral, atau tanpa label sama sekali, sama seperti jawaban lain yang menggunakan istilah "programmer tidak kompeten."
Moby Disk

1
Saya tidak yakin apa yang Anda maksud dengan "kompleksitas konseptual". Pengalaman saya adalah bahwa orang-orang yang tidak cukup tahu tentang pohon atau hashtables tidak dapat membuat keputusan yang cerdas mengenai cara mengindeks (bagian dari) database besar.
Fizz

3

Saya agak ragu-ragu untuk menulis jawaban di sini, tetapi karena saya mendapati diri saya mengolok-olok beberapa orang lain [beberapa komentar saya tergerak untuk mengobrol], inilah bagaimana saya melihatnya ...

Ada tingkat / derajat pengetahuan untuk banyak hal dalam komputasi (dan dengan istilah ini saya kira kira penyatuan ilmu komputer dengan teknologi informasi). Kompleksitas komputasi tentunya adalah bidang yang luas (Apakah Anda tahu apa OptP itu? Atau apa yang dikatakan teorema Abiteboul-Vianu?) Dan juga mengakui banyak kedalaman: kebanyakan orang dengan gelar CS tidak dapat menghasilkan bukti ahli yang masuk ke dalam penelitian publikasi dalam kompleksitas komputasi.

n2

Sejujurnya saya berani membandingkan situasi mengetahui kapan harus menerapkan konsep kompleksitas komputasi (dan mengetahui kapan Anda dapat dengan aman mengabaikannya) dengan praktik yang agak umum (di luar dunia Jawa) menerapkan beberapa kode yang sensitif terhadap kinerja di C dan tidak sensitif terhadap kinerja hal-hal dengan Python dll. (Di samping itu, ini disebut dalam pembicaraan Julia "standar kompromi" .) Mengetahui kapan Anda tidak harus berpikir tentang kinerja menghemat waktu pemrograman Anda, yang juga merupakan komoditas yang cukup berharga.

Dan satu hal lagi adalah mengetahui kompleksitas komputasi tidak akan secara otomatis membuat Anda pandai mengoptimalkan program; Anda perlu memahami lebih banyak hal yang berhubungan dengan arsitektur seperti cache locality, [terkadang] pipelining, dan saat ini pemrograman paralel / multi-core juga; yang terakhir memiliki teori kompleksitas dan pertimbangan praktisnya sendiri; rasa yang terakhir dari kertas SOSP 2013 "Setiap skema penguncian memiliki ketenaran lima belas menit. Tidak satu pun dari sembilan skema penguncian yang kami anggap secara konsisten mengungguli yang lain, pada semua arsitektur target atau beban kerja. Sebenarnya, untuk mencari optimalitas, sebuah Algoritma kunci dengan demikian harus dipilih berdasarkan pada platform perangkat keras dan beban kerja yang diharapkan. "


1
Dalam jangka panjang, mengembangkan atau menemukan algoritma yang lebih baik biasanya lebih bermanfaat daripada mengubah bahasa pemrograman untuk bit kinerja-sensitif. Saya setuju dengan Anda bahwa ada hubungan yang kuat antara kurangnya pemahaman tentang kompleksitas dan optimasi prematur - karena mereka biasanya menargetkan bit yang kurang sensitif terhadap kinerja untuk optimasi.
Rob

1
Dalam praktiknya, algoritma Schlemiel the Painter (secara tidak sengaja) jauh lebih sering daripada penyortiran O (n ^ 2).
Peter Mortensen

-1

Jika Anda tidak tahu besar-O, Anda harus mempelajarinya. Ini tidak sulit, dan ini sangat berguna. Mulai dengan pencarian dan penyortiran.

Saya memperhatikan bahwa banyak jawaban dan komentar merekomendasikan profil , dan hampir selalu berarti menggunakan alat profil .

Masalahnya adalah, alat profiling ada di seluruh peta dalam hal seberapa efektif mereka untuk menemukan apa yang Anda butuhkan untuk mempercepat. Di sini saya telah membuat daftar dan menjelaskan kesalahpahaman yang diderita oleh para profiler.

Hasilnya adalah bahwa program, jika lebih besar dari latihan akademis, dapat berisi raksasa tidur , yang bahkan profiler otomatis terbaik tidak dapat mengekspos. Posting ini menunjukkan beberapa contoh bagaimana masalah kinerja dapat disembunyikan dari profiler.

Tetapi mereka tidak bisa bersembunyi dari teknik ini.


Anda mengklaim "Big-Oh" berguna tetapi kemudian Anda menganjurkan pendekatan yang berbeda. Juga, saya tidak melihat bagaimana belajar "Big-Oh" (matematika) dapat "mulai dengan mencari dan menyortir" (masalah algoritme).
Raphael

@ Raphael: Saya tidak menganjurkan pendekatan yang berbeda - itu ortogonal.Big-O adalah pengetahuan dasar untuk memahami algoritma, sedangkan menemukan masalah kinerja dalam perangkat lunak non-mainan adalah sesuatu yang Anda lakukan setelah kode ditulis dan dijalankan, bukan sebelumnya. (Kadang-kadang akademisi tidak mengetahui hal ini, sehingga mereka terus mengajar gprof, melakukan lebih banyak ruginya daripada kebaikan.) Dengan melakukan hal itu, Anda mungkin atau mungkin tidak menemukan bahwa masalahnya adalah penggunaan algoritma O (n * n), jadi Anda harus dapat mengenali itu. (Dan big-O hanyalah properti algoritma yang didefinisikan secara matematis, bukan subjek yang berbeda.)
Mike Dunlavey

"Dan big-O hanyalah properti algoritma yang didefinisikan secara matematis, bukan subjek yang berbeda." - Itu salah, dan sangat berbahaya. "Big-Oh" mendefinisikan kelas fungsi ; per se, itu tidak ada hubungannya dengan algoritma sama sekali.
Raphael

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.