Pada tahun 2018, saya berlatih Advent of Code (Anda dapat menonton aliran solusi saya di sini ). Setiap hari di bulan Desember, mereka memposting masalah kecil, dan Anda harus menulis program yang menyelesaikannya. Biasanya memakan waktu mulai dari beberapa menit hingga beberapa jam dan cukup menyenangkan, saya sarankan Anda mencobanya. Ketika tugas selesai, itu selalu tersedia, tidak hanya pada bulan Desember.
Saya menyadari bahwa ada dua jenis solusi: solusi yang dapat menghitung jawaban dalam beberapa milidetik, dan solusi yang membutuhkan jawaban selama beberapa tahun. Jika Anda mendapatkan opsi kedua, Anda melakukan sesuatu yang salah. Tidak ada gunanya menunggu, meskipun, secara teknis, itu mungkin benar juga.
Pengamatan menarik lainnya adalah tidak masalah perangkat keras apa yang Anda gunakan untuk meluncurkan. Jika solusinya cepat, itu akan cepat baik di laptop maupun di workstation yang dipompa. Tentu saja, ini bisa menjadi dua atau tiga kali lebih lambat, tetapi perbedaannya antara 10 md dan 30 md. Anda akan tetap mendapatkan jawaban Anda, jadi itu tidak terlalu penting.
Di sisi lain, jika solusinya lambat, Anda dapat menggunakan kekuatan pemrosesan apa pun, dan itu masih tidak akan cukup. Ini dapat memotong runtime dari tiga tahun (pada laptop) menjadi satu tahun (pada komputer paling kuat yang dapat saya buat). Apa bedanya? Lagipula itu terlalu lama.
Sekarang mari kita beralih ke perangkat lunak. Sangat mudah untuk menyebut solusi Advent Of Code salah ketika mereka lambat, karena kita tahu bahwa solusi cepat harus ada. Dengan masalah nyata, tidak ada yang menjaminnya.
Kecuali dalam beberapa kasus.
Cukup sering, sebenarnya.
Bahkan, saya akan mengatakan hampir selalu.
Ayo lihat. Saya memiliki perpustakaan bernama Datascript . Ini adalah struktur data / database persisten dan kebetulan diimplementasikan untuk dua platform: JS dan JVM. Selain itu, sebenarnya ditulis dalam Clojure dan sebagian besar basis kodenya digunakan oleh kedua platform. Ini berarti kita tahu bahwa kedua versi selalu melakukan hal yang sama. Ada lapisan kecil yang mencakup detail khusus platform seperti tipe data dan pustaka standar, tetapi sisanya bersifat umum. Bukannya satu versi adalah yang asli dan yang lainnya adalah port yang tidak efisien. Mereka berdua memainkan permainan yang sama.
Anda mungkin berpikir bahwa jika mereka berperilaku sama, kinerja mereka harus sama, bukan? Akan logis untuk berpikir demikian.
Mari kita lihat waktu aktual yang diperlukan untuk mengompilasi basis kode dan menjalankan rangkaian lengkap pengujian integrasi. Kita berbicara tentang basis kode yang lebih dari 9000 LOC, 4000 di antaranya adalah tes:
Clojure 1.10 di JVM:
- Waktu boot REPL: 1,5 detik
- Waktu kompilasi: 6,5 detik
- Waktu pengujian: 0,45 detik
ClojureScript 1.10.439 dengan kompilasi lanjutan:
- Waktu kompilasi: 78 detik
- Waktu tes: 1 detik
ClojureScript 1.10.439 tanpa kompilasi Google Closure:
- Waktu kompilasi: 24 detik
- Waktu tes: 1,3 detik
Jadi apa angka-angka ini memberitahu kita? Pada dasarnya, Anda dapat mengambil ~ 8 detik, 24 detik, atau 78 detik untuk memproses kode yang sama. Pilihan ada padamu. Selain itu, dengan menjalankan program yang sama, Anda bisa mendapatkan hasilnya dalam setengah detik, satu detik, atau hampir satu setengah detik.
“Tapi tunggu, Tonsky, mereka tidak bisa dibandingkan! Ini adalah dua perbedaan besar! Mereka dirancang untuk melakukan hal-hal yang sama sekali berbeda! Salah satunya bekerja di browser!"
Anda tentu saja bisa mendapatkan hasil. Biarkan saya mengingatkan Anda bahwa kami sedang mengkompilasi kode yang sama, dibuat untuk melakukan hal yang sama, menggunakan algoritme yang sama dan berjalan pada perangkat keras yang sama. Hasil akhirnya sama dalam kedua kasus: Anda mendapatkan respons atas kueri Anda di log data dalam waktu singkat atau dalam waktu lama. Anda bisa menghabiskan setengah hari Anda menunggu kompiler, atau Anda menghabiskannya bermain REPL, membangun sesuatu.
Apa yang telah dilakukan oleh kompiler ClojureScript / Google Closure begitu lama? Mereka membuang-buang waktumu, itu saja. Tentu saja, tidak ada yang harus disalahkan, tetapi pada akhirnya seluruh keputusan itu salah. Kami dapat melakukan hal yang sama lebih cepat, kami memiliki bukti, kami memiliki sarana untuk melakukan ini, tetapi kebetulan tidak. Tapi kami bisa. Jika Anda ingin. Overhead besar yang Anda bayar, Anda bayar dengan sia-sia. Anda tidak mendapatkan apa pun dari JS selain menggandakan runtime dan waktu pembuatan astronomis.
Hal yang sama berlaku untuk semua bahasa dengan waktu pembuatan yang sangat lama. Bukannya mereka tidak bisa lebih cepat. Mereka hanya memilih untuk tidak melakukannya. Apakah program C ++ atau Rust terlalu lama untuk dikompilasi? Yah, OCaml mungkin bisa mengkompilasi program yang setara dalam waktu kurang dari satu detik. Dan itu masih akan cepat di level mobil.
“Wah, wah, pelan-pelan! Ini bahkan lebih tidak adil! Sekarang bukan hanya dua perbedaan besar, sekarang seperti sikat gigi dan pesawat ruang angkasa. Anda benar-benar mengabaikan apa yang disediakan setiap bahasa. Ada alasan mengapa mereka menghabiskan begitu banyak waktu untuk menyusun, kau tahu?"
Aku tahu. Tapi tetap saja, saya pikir Anda bisa membandingkannya. Bagaimanapun, mereka semua adalah bahasa tujuan umum, dan pada akhirnya, yang penting adalah apakah Anda memiliki program kerja dan dapat memberikan jawaban dalam kerangka waktu yang wajar. Tidak masalah bagaimana pengembang sampai di sana. Anda bisa tenang memikirkannya, tetapi tidak ada yang peduli tentang itu.
Bayangkan: sebuah pesawat terbang dari Moskow ke Novosibirsk, jantung Siberia, yang menempuh jarak 2.800 kilometer dalam 4 jam. Ada juga kereta api yang menempuh jarak yang sama dalam tiga hari. Tidak ada pancuran di kereta, makanan buruk, tempat tidur yang tidak bisa Anda tiduri. Dan pesawat terbang adalah pesawat modern yang nyaman. Mana yang akan Anda pilih? Harga yang sama. Satu-satunya perbedaan adalah kenyamanan Anda dan waktu Anda.
Jika kita menganggap ini sebagai metafora pengembangan perangkat lunak, Anda akan terkejut bahwa programmer dengan senang hati mengambil kereta. Mereka bahkan berdebat sampai suara serak bahwa ada alasan yang tak terbantahkan untuk memilih kereta api. Tidak, mereka tidak keberatan jika kompiler meluangkan waktu untuk "bekerja". Ada cara yang lebih cepat untuk mencapai tujuan yang sama. Sangat mudah untuk menjadi bingung ketika berdebat tentang detail, tetapi ingat: kita semua berakhir di tempat yang sama , tidak peduli bahasa apa yang kita gunakan.
Browser? Cerita yang sama. HTML adalah cara yang agak tidak efisien untuk memposisikan piksel di layar. Komputer yang dapat menampilkan jutaan poligon dalam bingkai dapat mengalami kesulitan memuat halaman web. Seperti solusi Advent of Code, ini tidak bergantung pada kekuatan komputer Anda. Dan bahkan kode web yang sangat dioptimalkan berdasarkan Canvas dan WebAssembly ( Figma ) membuat penggemar Macbook saya berputar dalam keheningan total ketika saya meluncurkan Sketch saya sendiri.
- * menepuk penutup * PC ini mampu menjalankan Crysis 3 dalam 4K pada 144fps.
- Tapi bisakah itu menjalankan Atom?
Hanya ada batasan seberapa jauh keputusan yang salah ini bisa terjadi. Editor teks di Electron tidak dapat mengubah ukuran jendela secara real time dan melorot dalam bingkai saat Anda hanya memindahkan kursor. Slack pada iMac Pro akan sama lambat dan intensifnya memori seperti pada Macbook 12 inci.
Seluruh keputusan, "tumpukan web", umumnya salah . Hal yang sama dapat dilakukan lebih cepat dan lebih efisien - ada begitu banyak potensi yang terbuang. Saatnya untuk mengakuinya dan memulai dari awal. Ada editor teks cepat dan program komunikasi yang tersedia bahkan untuk netbook terlemah sekalipun.
Aku bisa terus dan terus. Ingatlah ini: Pikirkan tentang apa yang Anda dapatkan darinya. Apakah masalah dan sumber daya yang dihabiskan untuk itu sebanding? Sangat mudah untuk menemukan alasan mengapa segala sesuatunya seperti itu. Mereka semua mungkin valid, tetapi ini adalah alasan. Kami tahu program yang lebih cepat dimungkinkan dan itu membuat segalanya menjadi salah.