Mengapa saya harus peduli dengan kinerja dan efisiensi mikro?

Banyak pertanyaan dan jawaban pada halaman C / C ++, secara khusus atau tidak langsung membahas masalah kinerja mikro (seperti overhead dari fungsi tidak langsung vs langsung vs inline), atau menggunakan algoritma O (N ² ) vs O (N log N) pada daftar 100 item.

Saya selalu kode tanpa perhatian tentang kinerja mikro, dan sedikit perhatian tentang kinerja makro, fokus pada kode yang mudah dipelihara, dapat diandalkan, kecuali atau sampai saya tahu saya memiliki masalah.

Pertanyaan saya adalah mengapa sejumlah besar programmer begitu peduli? Apakah ini benar-benar masalah bagi sebagian besar pengembang, apakah saya hanya cukup beruntung untuk tidak perlu terlalu khawatir tentang hal itu, atau apakah saya seorang programmer yang buruk?

Dalam praktiknya, kinerja jarang merupakan masalah yang perlu dikelola pada tingkat perincian itu. Sebaiknya perhatikan situasi jika Anda tahu Anda akan menyimpan dan memanipulasi data dalam jumlah besar, tetapi sebaliknya, Anda benar, dan lebih baik, menjaga hal-hal sederhana.

Salah satu perangkap termudah untuk jatuh ke dalam - terutama di C dan C ++ di mana Anda memiliki kontrol berbutir halus - adalah mengoptimalkan terlalu dini, dan pada tingkat yang terlalu halus. Secara umum aturannya adalah: A) jangan optimalkan sampai Anda tahu Anda memiliki masalah, dan B) jangan mengoptimalkan apa pun yang Anda belum terbukti sebagai area masalah dengan menggunakan profiler.

Sebuah konsekuensi wajar untuk B) adalah: programmer terkenal buruk dalam memprediksi di mana kemacetan kinerja mereka, meskipun, untuk satu, mereka pikir mereka baik dalam hal itu. Gunakan profiler, dan optimalkan bagian-bagian yang lambat, atau ubah algoritme jika satu bagian kode terlalu sering dipanggil, sehingga menyebabkan masalah.

Saya pikir semua yang ada di daftar Anda adalah optimasi mikro, yang seharusnya tidak dilihat secara umum, kecuali untuk

menggunakan algoritma O (n * n) vs O (NlogN) pada daftar 100 item

yang saya pikir harus dilihat. Tentu, daftar itu adalah 100 item sekarang, dan semuanya cepat untuk n kecil , tapi saya akan segera bertaruh bahwa kode yang sama akan digunakan kembali untuk beberapa juta daftar baris, dan kode itu masih akan memiliki untuk bekerja secara wajar.

Memilih algoritma yang tepat tidak pernah merupakan optimasi mikro. Anda tidak pernah tahu jenis data apa yang kode yang akan digunakan untuk dua bulan atau dua tahun kemudian. Berbeda dengan "mikro-optimasi" yang mudah diterapkan dengan bimbingan profiler, perubahan algoritma sering membutuhkan desain ulang yang signifikan untuk memanfaatkan algoritma baru secara efektif. (Misalnya beberapa algoritma mengharuskan input data diurutkan, yang mungkin memaksa Anda untuk memodifikasi bagian signifikan dari aplikasi Anda untuk memastikan data tetap diurutkan)

Beberapa waktu yang lalu, di pekerjaan pertama saya, saya menulis kode untuk embedded system. Sistem ini menggunakan mikroprosesor 8086, dan memiliki memori terbatas. Kami menggunakan kompiler Intel C. Satu sistem yang saya bangun diperlukan untuk mengakses susunan struktur 3-d. Saya membangunnya persis seperti yang dikatakan buku itu kepada saya: panggil malloc untuk 3 dimensi, lalu alokasikan baris untuk dimensi berikutnya, lalu calloc untuk simpul akhir.

Itu cukup rumit (bagi saya pada saat itu), saya harus melakukan fitting curve, kontrol proses ANOVA dan analisis Chi-squared. Tidak ada perpustakaan yang melakukan ini untuk kami; kami harus menulis semuanya dan memasukkan semuanya ke 8086.

Sistem berjalan seperti anjing. Setelah profiling cepat, saya menemukan bahwa salah satu masalah terbesar adalah pengalokasi. Untuk memperbaiki masalah, saya meninggalkan semua panggilan ke malloc dan melakukan manajemen memori saya sendiri dari satu blok besar memori.

Dalam kasus lain pada pekerjaan yang sama, pelanggan mengeluh tentang waktu respons pada sistem kontrol proses statistik mereka. Tim sebelum saya telah merancang sistem "perangkat lunak PLC" di mana operator dapat menggunakan logika boolean untuk menggabungkan sinyal dan tripping switch. Mereka menulisnya dalam bahasa yang disederhanakan, apa yang kita sebut "bahasa spesifik domain" hari ini. seingat saya itu tampak seperti ((A1 + B1) > 4) AND (C1 > C2)dan sebagainya.

Desain asli mengurai dan menafsirkan string itu setiap kali dievaluasi. Pada prosesor kami yang sangat sedikit, ini menghabiskan banyak waktu, dan itu berarti pengontrol proses tidak dapat memperbarui secepat proses sedang berjalan.

Saya mengambil pandangan baru dan memutuskan bahwa saya bisa menerjemahkan logika itu menjadi kode assembly, saat runtime. Saya menguraikannya sekali dan kemudian setiap kali dijalankan, aplikasi memanggil fungsi yang dihasilkan secara dinamis. Agak seperti beberapa virus lakukan hari ini, saya kira (tapi saya tidak; benar-benar tahu). Hasilnya adalah peningkatan kinerja 100 kali lipat, yang membuat pelanggan dan bos saya benar-benar bahagia.

Kode baru hampir tidak dapat dipelihara, karena saya telah membangun kompiler kustom . Tetapi keunggulan kinerja jauh melebihi kerugian pemeliharaan.

Baru-baru ini saya bekerja pada sistem yang perlu mengurai lalat XML, secara dinamis. File yang lebih besar akan membutuhkan lebih banyak waktu. Ini sangat sensitif terhadap kinerja; parse yang terlalu lambat akan menyebabkan UI menjadi benar-benar tidak dapat digunakan.

Hal-hal semacam ini muncul setiap saat.

Jadi .... terkadang Anda menginginkan kode yang mudah dikelola dan mudah ditulis. Terkadang Anda menginginkan kode yang berjalan cepat. Pengorbanan adalah keputusan rekayasa yang perlu Anda buat, pada setiap proyek.

Jika Anda memproses gambar besar dan mengulangi setiap piksel, maka penyesuaian kinerja dapat menjadi sangat penting.

Biarkan saya memberi tahu Anda sedikit tentang mengapa di balik budaya.

Jika Anda lebih dekat ke 40 dari pada 20, dan Anda telah memprogram untuk mencari nafkah selama bertahun-tahun dewasa Anda, maka Anda menjadi dewasa ketika C ++ benar-benar satu-satunya permainan di kota, aplikasi desktop adalah norma, dan perangkat keras masih perangkat lunak yang sangat tertinggal dalam hal kemampuan bandwidth / kinerja.

• Kami dulu harus melakukan trik pemrograman bodoh untuk dapat membaca file besar (> 2G) ...
• Kami dulu khawatir tentang ukuran yang dapat dieksekusi ...
• Kami dulu khawatir tentang berapa banyak memori yang dikonsumsi oleh program kami ...
• Kami secara teratur membuat keputusan algoritme waktu vs ruang angkasa ...
• Bahkan di back-end, kami harus menulis program CGI di C atau C ++ untuk apa pun untuk menangani no yang layak. dari RPS ... Itu beberapa kali lipat lebih cepat.
• Kami biasa menjalankan tes berdasarkan kemampuan kinerja antara delphi / c ++ / vb!

Sangat sedikit orang yang khawatir tentang hal-hal ini hari ini.

Namun, 10 tahun yang lalu Anda masih harus khawatir tentang perangkat lunak Anda yang diunduh melalui modem 56kb, dan dijalankan pada PC berusia 5 tahun ... Apakah Anda ingat betapa buruknya PC pada tahun 1996? Pikirkan dalam hal 4GB hard drive, prosesor 200Mhz, dan 128Mb RAM ...

Dan server 10 tahun yang lalu? Server "generasi berikutnya" Dell berharga $ 2000, dan datang dengan 2 (!) Prosesor pentium 1Ghz, 2Gb atau Ram, dan hard drive 20Gb.

Itu hanya ballgame yang berbeda , dan semua insinyur "senior" yang memiliki 10 tahun pengalaman (orang-orang cenderung menjawab pertanyaan Anda), memotong gigi mereka di lingkungan itu.

sudah ada 10 jawaban di sini dan ada yang benar-benar bagus, tetapi karena ini adalah kesayangan pribadi saya ...

pengoptimalan prematur yang a) membutuhkan lebih banyak waktu untuk dilakukan daripada solusi sederhana b) memperkenalkan lebih banyak kode di mana solusi sederhana akan menjadi setengah dari ukuran dan setengah dari kompleksitas dan c) membuat hal-hal yang kurang dapat dibaca adalah BENAR-BENAR harus dihindari. Namun, jika pengembang memiliki pilihan antara menggunakan std :: map atau std :: vector dan ia memilih koleksi yang salah dari ketidaktahuan murni untuk kinerja yang sama buruknya jika tidak lebih buruk dari optimasi prematur. Bagaimana jika Anda dapat sedikit mengubah kode Anda hari ini, mempertahankan keterbacaan, menjaga kompleksitas yang sama, tetapi membuatnya lebih efisien, apakah Anda akan melakukannya? Atau Anda akan menyebutnya "optimasi prematur"? Saya menemukan bahwa banyak orang bahkan tidak akan memikirkannya dengan cara apa pun.

Suatu ketika saya adalah orang yang menyarankan "optimasi mikro" yang membutuhkan sedikit perubahan dan saya diberi respons yang sama seperti yang Anda katakan, "Anda tidak boleh mengoptimalkan terlalu dini. Mari kita mulai bekerja dan kita akan mengubahnya nanti jika ada masalah kinerja ". Butuh beberapa rilis sebelum kami memperbaikinya. Dan ya itu masalah kinerja.

Walaupun optimasi awal mungkin tidak baik, saya pikir itu sangat bermanfaat jika orang menulis kode dengan memahami apa yang akan dilakukan kode itu dan tidak mengabaikan pertanyaan yang menghasilkan notasi O (x) sebagai "optimasi". Ada banyak kode yang dapat Anda tulis sekarang dan dengan sedikit pemikiran tentang kinerja hindari 80% masalah di ujung jalan.

Juga pertimbangkan bahwa banyak masalah kinerja tidak akan terjadi di lingkungan Anda dan tidak segera. Beberapa kali Anda akan memiliki pelanggan yang mendorong batas atau pengembang lain memutuskan untuk membangun di atas kerangka kerja Anda dan menambah jumlah objek 10 kali lipat. Dengan beberapa tentang kinerja sekarang, Anda dapat menghindari mendesain ulang yang sangat mahal nanti. Dan jika masalah ditemukan setelah perangkat lunak dirilis secara resmi, bahkan perbaikan sederhana menjadi 20 kali lebih mahal untuk diterapkan.

Jadi sebagai kesimpulan, menjaga kinerja dalam pikiran setiap saat membantu mengembangkan kebiasaan baik. Yang sama pentingnya dengan memiliki tulisan bersih, sesederhana mungkin dan kode terorganisir.

Saya menduga bahwa banyak yang Anda lihat adalah kesalahan pengambilan sampel sederhana. Ketika orang berhadapan dengan situasi langsung, mereka menulis kode dan itulah akhirnya. Mereka mengajukan pertanyaan ketika mereka berhadapan dengan sesuatu yang relatif rumit, seperti perlu mengoptimalkan, terutama dalam situasi di mana belum tentu bahwa optimasi akan diperlukan.

Yang mengatakan, pasti ada beberapa optimasi prematur yang terlibat juga. Benar atau tidak, C dan C ++ memiliki reputasi untuk kinerja, yang cenderung menarik orang-orang yang peduli tentang kinerja - termasuk mereka yang dapat melakukan optimasi sebanyak untuk kesenangan seperti karena itu benar-benar diperlukan.

Beberapa jawaban lain menyebutkan embedded system , dan saya ingin memperluas ini.

Ada banyak perangkat yang mengandung prosesor low-end, misalnya: pengontrol ketel di rumah Anda, atau kalkulator saku sederhana, atau lusinan keripik di dalam mobil modern.

Untuk menghemat uang, ini mungkin memiliki jumlah flash (untuk menyimpan kode) dan RAM yang tampak kecil bagi mereka yang hanya memiliki kode tertulis untuk PC atau smartphone. Untuk menghemat daya, mereka dapat berjalan pada kecepatan clock yang relatif rendah.

Sebagai contoh, keluarga mikrokontroler STM32 bergerak dari 24 MHz, 16 KB flash dan 4 KB RAM , hingga 120 MHz, 1 MB flash dan 128 KB RAM .

Saat menulis kode untuk chip seperti ini, akan menghemat banyak waktu jika Anda ingin membuat kode Anda seefisien mungkin. Jelas, optimasi prematur tetap merupakan ide yang buruk; tetapi dengan latihan, Anda belajar bagaimana masalah umum dapat diselesaikan dengan cepat dan / atau dengan sumber daya minimal, dan kode sesuai.

Ini menjadi dasarnya bahasa tingkat rendah, ketika salah satu berjalan ke kasus kinerja patologis di mana salah satu detail yang tidak akan peduli 99% dari waktu yang menyebabkan para bottleneck, yang benar-benar memiliki kesempatan untuk langsung bekerja di sekitar masalah (tidak seperti kebanyakan lainnya bahasa); tetapi tentu saja, sering kali, cara melakukannya secara paling efektif tidak segera terlihat. Karenanya setengah dari pertanyaan optimasi mikro yang aneh / menarik ditanyakan di sini.

Setengah lainnya hanya berasal dari mereka yang penasaran tentang seberapa dekat mereka dengan logam. Ini menjadi bahasa tingkat rendah pada dasarnya, setelah semua ...

Kinerja selalu menjadi topik hangat saat Anda berurusan dengan C dan C ++. Mengenai seberapa jauh seseorang harus melangkah, Anda selalu bisa menjadi gila sampai-sampai ASM sebaris, atau menggunakan aritmatika pointer untuk iterasi yang lebih cepat. Namun, ada titik di mana seseorang menghabiskan begitu banyak waktu untuk mengoptimalkan sehingga bekerja untuk mengembangkan program secara keseluruhan terhenti.

Saat menangani masalah ini, ada kinerja programmer dan kinerja kode. Yang mana dari ini untuk fokus akan selalu memunculkan pertanyaan menarik. Pada akhirnya pertanyaan yang paling penting adalah seberapa nyata hal itu bagi pengguna. Apakah pengguna akan bekerja dengan data yang menciptakan array dengan ratusan atau ribuan elemen? Dalam hal ini, pengkodean untuk menyelesaikan sesuatu dengan cepat mungkin membuat pengguna Anda mengeluh bahwa operasi standar program lambat.

Lalu ada pengguna yang akan bekerja dengan sejumlah kecil data. Beberapa file di sana-sini, tempat melakukan hal-hal seperti penyortiran dan operasi file tidak akan terlihat bagi pengguna jika Anda menggunakan fungsi tingkat yang lebih tinggi yang membuat Anda lebih mudah untuk mempertahankannya dengan mengorbankan beberapa kinerja.

Ini hanyalah contoh kecil dari masalah yang akan Anda hadapi. Hal-hal lain termasuk perangkat keras pengguna target. Anda harus lebih khawatir tentang kinerja lebih banyak jika Anda berurusan dengan sistem tertanam, maka jika pengguna Anda memiliki, katakanlah, mesin dual core dengan gigs of ram.

Mengapa programmer sangat peduli? Ada ide-ide konyol mengisi kepala mereka, seperti menyelesaikan masalah kinerja sebelum mereka tahu mereka memilikinya, dan tidak memahami ketika mereka menebak .

Ini sulit karena, dalam pengalaman saya, ada beberapa masalah kinerja yang harus dipikirkan sebelumnya. Butuh pengalaman untuk mengetahui siapa mereka.

Yang mengatakan, metode yang saya gunakan mirip dengan Anda, tetapi tidak sama:

1. Mulailah dengan desain sesederhana mungkin. Secara khusus, struktur data harus dinormalisasi dan seminimal mungkin. Sejauh ia memiliki redundansi yang tak terhindarkan, orang harus menghindari pemberitahuan sebagai cara untuk membuatnya konsisten. Lebih baik mentolerir ketidakkonsistenan sementara, dan memperbaikinya dengan proses berkala.

2. Ketika program sedang dalam pengembangan, lakukan penyetelan kinerja secara berkala, karena masalah kinerja memiliki cara yang diam-diam merayap masuk. Metode yang saya gunakan adalah jeda acak , karena saya pikir itu yang terbaik.

Inilah contoh pukulan demi pukulan tentang apa yang saya maksud.

Sejujurnya, itu tergantung pada apa tujuan Anda dan apakah Anda pemrograman secara profesional atau sebagai hobi.

Saat ini, komputer modern adalah mesin yang sangat kuat. Terlepas dari operasi dasar apa yang Anda putuskan untuk dilakukan, apakah Anda mencoba untuk mengoptimalkan mikro atau tidak, mereka dapat membuat pekerjaan mereka sangat cepat. Tetapi tentu saja, jika Anda melakukan sesuatu yang lain (misalnya, superkomputasi untuk bidang-bidang seperti fisika atau kimia), Anda mungkin ingin mengoptimalkan sebanyak yang Anda inginkan.

Para programmer MIT awal tidak dilahirkan untuk membuat hal-hal yang luar biasa; Mereka mulai menyederhanakan dan memberi daya pada algoritma yang ada. Kebanggaan mereka adalah membuat 2 + 2 memberi empat dalam dua detik kurang dari algoritma yang ada (itu hanya contoh, Anda mendapatkan ide). Mereka terus-menerus mencoba menggunakan lebih sedikit kartu punch di mesin TI-83 mereka untuk kinerja.

Juga, jika Anda memprogram untuk sistem embedded, maka Anda tentu harus mengawasi kinerja mikro. Anda tidak ingin memiliki jam digital lambat yang berdetik 5 milidetik detik lebih awal dari jam digital lainnya.

Akhirnya, jika Anda seorang programmer hobi maka tentu tidak ada salahnya mengoptimalkan detail terkecil meskipun program Anda cepat itu. Ini tidak diperlukan, tetapi tentu saja sesuatu yang dapat Anda kerjakan dan ambil kesempatan untuk mempelajari lebih lanjut. Jika Anda bekerja secara profesional dalam sebuah perangkat lunak, Anda tidak dapat mengambil kemewahan itu kecuali sangat diperlukan.

menggunakan algoritma O (N2) vs O (NlogN) pada daftar 100 item.

Saya berada dalam situasi yang sama baru-baru ini. Saya memiliki berbagai item. Dalam kasus yang diharapkan, ada dua item (!) Dalam daftar, dan bahkan dalam kasus terburuk saya tidak mengharapkan lebih dari empat atau mungkin delapan.

Saya perlu mengurutkan daftar itu. Ternyata, mengganti std::sortdengan jaringan penyortiran (pada dasarnya banyak bersarang if) memangkas sebagian besar waktu berjalan (saya tidak ingat nomornya tapi itu kira-kira 10-20%). Ini adalah manfaat besar dari optimasi mikro, dan kode ini benar-benar kritis terhadap kinerja.

Tentu saja, saya hanya melakukan ini setelah membuat profil. Tetapi intinya adalah, jika saya menggunakan bahasa yang tidak nyaman dan berbelit-belit seperti C ++ (belum lagi aturannya yang rumit dan rumit untuk resolusi kelebihan beban), maka saya ingin menuai manfaat penuh.

Penggunaan energi kumulatif

Ada satu jawaban yang menurut saya selalu hilang dari diskusi ini dan yang sedikit mengganggu saya - penggunaan energi kumulatif .

Tentu, mungkin tidak masalah jika Anda menulis program Anda dalam bahasa tingkat tinggi yang ditafsirkan, dan membiarkannya berjalan di browser dengan beberapa lapisan tipuan, atau jika loop Anda membutuhkan 0,01 detik, bukan 0,001 detik. Tidak ada yang akan melihat, yaitu, tidak ada pengguna individu akan melihat.

Tetapi ketika puluhan ribu, atau bahkan jutaan pengguna dalam beberapa kasus menggunakan kode Anda, semua itu menambah inefisiensi tambahan. Jika alat Anda mencegah CPU memasuki kondisi tidur hanya sepuluh detik per hari, dan sejuta pengguna menggunakannya, algoritma Anda yang tidak efisien hanya menghabiskan 140 kWh ^[1] per hari.

Saya jarang melihat ini dibahas, dan saya pikir itu menyedihkan. Saya sangat curiga bahwa angka-angka itu jauh lebih buruk untuk kerangka kerja populer, seperti Firefox, dan aplikasi web interaktif yang bagus, dan itu akan menarik untuk diteliti.

^{[1] Saya baru mengarangnya, 10 juta detik kali 50 Watt. Angka pastinya tergantung pada banyak hal.}

Kadang-kadang Anda hanya memiliki algoritma yang tidak bisa lebih baik daripada waktu linear yang masih memiliki permintaan kinerja yang kuat.

Contohnya adalah pemrosesan video di mana Anda tidak dapat membuat gambar / bingkai lebih terang sebagai contoh dasar tanpa mengulangi setiap piksel (well, saya kira Anda bisa dengan semacam struktur hierarki yang menunjukkan properti yang diwarisi oleh anak-anak yang akhirnya turun ke ubin gambar untuk simpul daun, tetapi kemudian Anda akan menunda biaya perulangan yang lebih tinggi melalui setiap piksel ke penyaji dan kode mungkin akan lebih sulit dipertahankan daripada filter gambar yang paling dioptimalkan secara mikro).

Ada banyak kasus seperti itu di bidang saya. Saya cenderung melakukan loop kompleksitas-linear yang harus menyentuh segala sesuatu atau membaca semuanya daripada yang mendapat manfaat dari segala jenis struktur data atau algoritma yang canggih. Tidak ada pekerjaan yang dapat dilewati ketika semuanya harus disentuh. Jadi pada saat itu jika Anda berurusan dengan kompleksitas linear, Anda harus membuat pekerjaan yang dilakukan lebih murah dan lebih murah.

Jadi dalam kasus saya optimisasi yang paling penting dan umum sering representasi data dan tata letak memori, multithreading, dan SIMD (biasanya dalam urutan ini dengan representasi data menjadi yang paling penting, karena memengaruhi kemampuan untuk melakukan dua yang terakhir). Saya tidak mengalami begitu banyak masalah yang bisa diselesaikan oleh pohon, tabel hash, algoritma pengurutan, dan hal-hal semacam itu. Kode harian saya lebih sesuai, "untuk setiap hal, lakukan sesuatu."

Tentu saja itu adalah kasus lain untuk dibicarakan ketika optimasi diperlukan (dan yang lebih penting, ketika tidak), mikro atau algoritmik. Tetapi dalam kasus khusus saya, jika jalur eksekusi yang kritis memerlukan optimasi, peningkatan kecepatan 10x + sering dicapai oleh optimasi tingkat mikro seperti multithreading, SIMD, dan menata ulang susunan memori dan pola akses untuk meningkatkan lokalitas referensi. Tidak sering saya dapat, misalnya, mengganti semacam gelembung dengan introsort atau semacam radix atau deteksi tabrakan kompleksitas kuadratik dengan BVH sehingga banyak menemukan hotspot yang, katakanlah, manfaat dari pemisahan bidang panas / dingin.

Sekarang dalam kasus saya, bidang saya sangat kritis terhadap kinerja (raytracing, mesin fisika, dll) sehingga raytracer yang lambat namun benar-benar sempurna yang membutuhkan 10 jam untuk membuat gambar sering dianggap tidak berguna atau lebih cepat daripada yang cepat yang sepenuhnya interaktif tetapi menampilkan gambar yang paling jelek dengan sinar yang bocor di mana-mana karena kurangnya sinar kedap air / persimpangan tri. Kecepatan bisa dibilang metrik kualitas utama dari perangkat lunak tersebut, bahkan bisa dibilang lebih dari benar sampai titik tertentu (karena "kebenaran" adalah ide kabur dengan raytracing karena semuanya mendekati, asalkan tidak menabrak atau semacamnya). Dan ketika itu masalahnya, jika saya tidak memikirkan efisiensi di muka, saya merasa saya harus benar-benar mengubah kode pada level desain paling mahal untuk menangani desain yang lebih efisien. Jadi jika saya tidak

Game adalah bidang lain yang mirip dengan milikku. Tidak masalah seberapa benar logika gim Anda atau seberapa basis kode Anda yang dapat dipertahankan dan direkayasa dengan cemerlang jika gim Anda berjalan dengan kecepatan 1 frame per detik seperti tampilan slide. Di bidang-bidang tertentu kurangnya kecepatan sebenarnya bisa membuat aplikasi tidak berguna bagi penggunanya. Tidak seperti game, tidak ada metrik "cukup baik" di area seperti raytracing. Para pengguna selalu menginginkan lebih banyak kecepatan, dan persaingan industri terutama dalam mencari solusi yang lebih cepat. Ini tidak akan pernah cukup baik sampai saat itu juga, di mana game akan menggunakan pelacak jalur. Dan mungkin itu masih belum cukup baik untuk VFX, karena para seniman mungkin ingin memuat miliaran poligon dan melakukan simulasi partikel dengan tabrakan sendiri di antara miliaran partikel pada 30+ FPS.

Sekarang jika itu kenyamanan, meskipun begitu saya masih menulis sekitar 90% dari kode dalam bahasa scripting (Lua) tanpa khawatir tentang kinerja apa pun. Tetapi saya memiliki jumlah kode yang luar biasa besar yang sebenarnya perlu di-loop melalui jutaan hingga milyaran hal, dan ketika Anda mengulang-ulang jutaan hingga milyaran, Anda mulai melihat perbedaan epik antara kode single-threaded yang naif yang mengaktifkan cache miss dengan setiap iterasi vs. katakanlah, kode vektor berjalan di paralel mengakses blok yang berdekatan di mana tidak ada data yang tidak relevan dimuat ke dalam garis cache.

Seperti yang Anda sebutkan, kepedulian tentang masalah kinerja mikro tidak ada artinya sebelum Anda memperhitungkan beberapa masalah yang sebenarnya disebabkan oleh masalah ini

Sangat tidak mungkin untuk menjawab pertanyaan ini secara umum. Sebagian besar perangkat lunak yang sedang dibangun saat ini adalah situs web internal dan aplikasi LOB, dan untuk pemrograman semacam itu alasan Anda cukup tepat. Di sisi lain, jika Anda menulis sesuatu seperti driver perangkat atau mesin gim, tidak ada optimasi yang "prematur"; kemungkinan perangkat lunak Anda akan berjalan pada sistem yang sangat berbeda dengan batasan perangkat keras yang berbeda. Dalam hal ini Anda harus merancang untuk kinerja dan pastikan Anda tidak memilih algoritma yang kurang optimal.

Saya pikir masalah programmer, yang sangat peduli dengan kinerja adalah, bahwa kadang-kadang dalam hidupnya, dia perlu menulis kode mikro-kinerja, mungkin sangat mendesak, dan dia belajar, belajar, belajar, dan pada akhirnya dia tahu banyak hal dan trik.

Dan sekarang sulit untuk dilupakan, dan tanpa pengukuran sebelumnya, yang menunjukkan, bahwa dia tidak perlu khawatir, dia berada di sisi yang aman, menggunakan kode cepat.

Selalu menyenangkan untuk menunjukkan pengetahuan mendalam Anda, keterampilan Anda dan beberapa trik, dan menggunakan kembali sesuatu yang telah Anda pelajari. Itu membuat Anda merasa berharga, dan waktu, dihabiskan untuk belajar, menjadi layak.

Kadang-kadang dalam hidup saya, saya belajar peningkatan awalan lebih cepat ...

for (int i = 0; i < MAX; ++i)

... dari penambahan postfix:

for (int i = 0; i < MAX; i++)

Sekarang jika MAX rendah, itu tidak masalah, dan jika ada pekerjaan nyata dalam loop, itu tidak masalah juga. Tetapi tidak ada alasan untuk menggunakan versi postfix, bahkan jika kompilator hari ini mengoptimalkan kode mereka sendiri.

Mungkin para pencari kinerja memerlukan tujuan tambahan, selain menulis 'kode kerja', seperti 'kode kerja dan mudah dibaca' untuk memiliki pedoman dalam banyak pilihan.

Apakah saya hanya cukup beruntung untuk tidak perlu terlalu khawatir tentang hal itu, atau apakah saya seorang programmer yang buruk?

Apakah Anda peduli dengan kebutuhan Anda? Jika kinerja bukan keharusan maka jangan khawatir. Menghabiskan waktu yang signifikan untuknya adalah merugikan majikan Anda.

Sampai taraf kinerja selalu merupakan persyaratan. Jika Anda dapat memukulnya tanpa memikirkannya, Anda dibenarkan karena tidak memikirkannya.

Secara pribadi, saya paling sering didorong oleh kinerja ketika tes saya butuh waktu lama untuk lulus. Saya terlalu tidak sabar untuk menunggu 5 menit sementara serangkaian tes berlalu. Tapi itu biasanya diselesaikan dengan mengutak-atik tes.

Pertanyaan saya adalah mengapa sejumlah besar programmer begitu peduli? Apakah ini benar-benar masalah bagi sebagian besar pengembang,

Ada sejumlah besar programmer yang dibenarkan dalam hal seberapa peduli mereka. Ada sejumlah besar yang tidak. Mari kita bicara tentang mereka yang tidak.

Salah satu hal pertama yang dipelajari programmer di sekolah, setelah bagaimana membuat hal-hal benar-benar berfungsi, adalah notasi O besar. Banyak dari mereka mempelajari pelajaran dengan benar dan dengan demikian berfokus pada hal-hal yang secara dramatis dipengaruhi oleh n. Yang lain tidak mendapatkan matematika dan hanya mengambil pelajaran bahwa begitu berhasil perlu cepat. Lebih buruk lagi, beberapa siswa ini tidak pernah belajar hal lain tentang apa yang penting dilakukan dengan kode Anda selain membuatnya bekerja dan membuatnya bekerja cepat. Pelajaran yang terlewatkan: membuatnya dapat dibaca, rancang dengan baik, jangan bermain-main di dalamnya tanpa alasan.

Knuth benar: optimasi prematur adalah akar dari semua kejahatan. Tapi begitu berhasil apa langkah selanjutnya? Cepat kan? TIDAK! Langkah selanjutnya bisa dibaca. Dapat dibaca adalah langkah pertama, berikutnya, tengah, dan terakhir. Banyak orang yang saya temukan melakukan optimasi kinerja yang tidak dibutuhkan sedang melempar keterbacaan di bawah bus.

Beberapa bahkan mendapatkan sensasi sesat dari betapa tidak terbacanya kode mereka. Mereka harus menderita melihat sulit untuk memahami kode yang dibuat oleh orang lain jadi sekarang giliran mereka di payback.

Saya tahu ini karena saya biasa melakukan ini. Saya pernah refactored 5 baris yang dapat dibaca dengan sempurna jika struktur turun ke ekspresi boolean satu baris yang tidak dapat dipahami dan dengan bangga mengirimkannya kepada profesor saya berharap untuk mengesankan karena saya bisa membuat sesuatu yang begitu kompak dan mengintimidasi. Saya tidak mendapatkan pujian yang saya harapkan.

Jika kode tetap dapat dibaca membuatnya cepat nanti mudah. Itu sebabnya Knuth menekankan "prematur" bukan "tidak dibutuhkan". Karena yakin, lebih cepat lebih baik. Tetapi lebih baik hanya lebih baik tergantung pada apa yang Anda korbankan untuk itu. Jadi tunggu sampai Anda tahu kinerja apa yang benar-benar Anda butuhkan sebelum Anda berkorban untuk itu. Keterbacaan pengorbanan enggan karena setelah hilang, sulit untuk kembali.

Di luar keterbacaan adalah seluruh dunia desain perangkat lunak. Tentang apa situs ini. Beberapa tidak memiliki petunjuk apa yang harus dilakukan sejauh desain. Jadi karena mereka tidak dapat mengesankan dengan desain, mereka membuat kekacauan yang tidak dapat dipahami sehingga orang tidak tahu bahwa mereka tidak tahu. Karena tidak ada yang pernah memperbaiki kode mereka, itu pasti kode yang bagus, kan?

Bagi sebagian orang, kinerja adalah alasan utama untuk melakukan apa pun yang mereka inginkan. Programmer memiliki banyak kekuatan dan otonomi. Kepercayaan telah diberikan pada mereka. Jangan menyalahgunakan kepercayaan.