Profesor Niklaus Wirth benar. Pencipta bahasa Pascal, rekan penulis teknologi pemrograman terstruktur , dan pemenang Hadiah Turing 1995 mencatat:

"Memperlambat program jauh lebih cepat daripada mempercepat komputer"

Sejak itu, pernyataan ini dianggap sebagai hukum Wirth . Ini secara efektif meniadakan Hukum Moore, yang menyatakan bahwa jumlah transistor dalam prosesor telah berlipat ganda sejak sekitar 1965. Inilah yang ditulis Wirth di artikel "Call for Slim Software" :

“Sekitar 25 tahun yang lalu, editor teks interaktif hanya berukuran 8000 byte, dan kompilernya 32 kilobyte, sedangkan turunan modernnya membutuhkan megabyte. Apakah semua perangkat lunak yang membengkak ini menjadi lebih cepat? Tidak, justru sebaliknya. Jika bukan karena perangkat keras seribu kali lebih cepat, perangkat lunak modern sama sekali tidak dapat digunakan. "

Sulit untuk tidak setuju dengan ini.

Perangkat lunak obesitas

Masalah pengembangan perangkat lunak modern sangat akut. Wirth menunjukkan satu aspek penting: waktu. Dia menyarankan bahwa alasan utama software membengkak adalah kurangnya waktu pengembangan.



Saat ini ada alasan lain untuk obesitas dalam perangkat lunak - abstraksi. Dan ini adalah masalah yang jauh lebih serius. Pengembang tidak pernah menulis program dari awal, tetapi ini tidak pernah menjadi masalah sebelumnya.



Dijkstra dan Wirth mencoba meningkatkan kualitas kode dan mengembangkan konsep pemrograman terstruktur. Mereka ingin mengeluarkan pemrograman dari krisis, dan untuk beberapa waktu pemrograman dipandang sebagai keahlian nyata bagi para profesional sejati. Programmer memperhatikan kualitas program, menghargai kejelasan dan efisiensi kode.



Hari-hari itu sudah berakhir.



Dengan munculnya bahasa-bahasa tingkat tinggi seperti Java, Ruby, PHP, dan Javascript, pada tahun 1995, ketika Wirth menulis artikelnya, pemrograman menjadi lebih abstrak. Bahasa baru membuat pemrograman jauh lebih mudah dan memakan banyak waktu. Mereka berorientasi objek dan dibundel dengan hal-hal seperti IDE dan pengumpulan sampah.



Menjadi lebih mudah bagi pemrogram untuk hidup, tetapi mereka harus membayar semuanya. Semakin mudah untuk hidup, semakin sedikit untuk berpikir. Sekitar pertengahan 90-an, programmer berhenti memikirkan kualitas program mereka, tulis pengembang Robin Martin dalam artikelnya "Niklaus Wirth benar, dan itulah masalahnya . " Pada saat yang sama, penggunaan perpustakaan secara luas dimulai, yang fungsionalitasnya selalu lebih dari yang diperlukan untuk program tertentu.



Karena pustaka tidak dibangun untuk satu proyek tertentu, mungkin pustaka tersebut memiliki fungsionalitas lebih dari yang sebenarnya dibutuhkan. Tidak masalah, katamu. Namun, banyak hal bertambah dengan cukup cepat. Bahkan orang-orang yang menyukai perpustakaan tidak ingin menemukan kembali kemudinya. Ini mengarah pada apa yang disebut neraka ketergantungan. Nicola Duza menulis postingan tentang masalah ini di Javascript .



Masalahnya sepertinya bukan masalah besar, tetapi pada kenyataannya ini lebih serius dari yang Anda kira. Misalnya, Nikola Dusa menulis aplikasi daftar tugas yang sederhana. Ia bekerja di browser Anda dengan HTML dan Javascript. Menurut Anda, berapa banyak dependensi yang digunakannya? 13.000. Tiga belas. Ribu. Bukti .



Jumlahnya memang gila, tapi masalahnya hanya akan bertambah. Saat library baru dibuat, jumlah dependensi di setiap project juga akan meningkat.



Artinya, masalah yang diperingatkan Niklaus Wirth pada tahun 1995 hanya akan semakin parah seiring berjalannya waktu.



Apa yang harus dilakukan?



Robin Martin menyarankan bahwa cara yang baik untuk memulai adalah dengan membagi perpustakaan. Daripada membangun satu perpustakaan besar yang melakukan yang terbaik, buat saja banyak perpustakaan.



Jadi, programmer hanya perlu memilih perpustakaan yang dia butuhkan, mengabaikan fungsionalitas yang tidak akan dia gunakan. Tidak hanya menginstal lebih sedikit dependensi itu sendiri, tetapi pustaka yang digunakan juga akan memiliki lebih sedikit dependensi.

Akhir Hukum Moore

Sayangnya, miniaturisasi transistor tidak dapat berlangsung selamanya dan memiliki batasan fisiknya. Mungkin cepat atau lambat Hukum Moore akan berhenti beroperasi. Ada yang bilang ini sudah terjadi. Dalam sepuluh tahun terakhir, kecepatan clock dan kekuatan inti prosesor individu telah berhenti tumbuh seperti biasanya.



Meski terlalu dini untuk menguburnya. Ada sejumlah teknologi baru yang menjanjikan untuk menggantikan mikroelektronika silikon. Misalnya, Intel, Samsung dan perusahaan lain sedang bereksperimen dengan transistor berbasis struktur nano karbon (nanofilamen) serta chip fotonik.





Evolusi transistor. Ilustrasi: Samsung



Tetapi beberapa peneliti mengambil pendekatan yang berbeda. Mereka mengusulkan pendekatan pemrograman sistem baru untuk secara dramatis meningkatkan efisiensi perangkat lunak masa depan. Jadi, adalah mungkin untuk "memulai kembali" hukum Moore secara terprogram, tidak peduli betapa fantastisnya kedengarannya dalam terang pengamatan Nicklaus Wirth tentang obesitas dalam program. Tetapi bagaimana jika kita dapat membalikkan tren ini?

Teknik Akselerasi Perangkat Lunak

Baru-baru ini, majalah Science mempublikasikan artikel menarik dari para ilmuwan dari Laboratorium Ilmu Komputer dan Kecerdasan Buatan dari Institut Teknologi Massachusetts (CSAIL MIT). Mereka menyoroti tiga area prioritas untuk mempercepat komputasi lebih lanjut:

• perangkat lunak terbaik;
  
  
• algoritma baru;
  
  
• perangkat keras yang lebih dioptimalkan.

Penulis utama makalah penelitian Charles Leiserson menegaskan tesis perangkat lunak obesitas . Ia mengatakan manfaat miniatur transistor begitu besar sehingga selama beberapa dekade programmer mampu memprioritaskan pembuatan kode yang lebih mudah untuk ditulis daripada mempercepat eksekusi. Inefisiensi dapat ditoleransi karena chip komputer yang lebih cepat selalu menggantikan obesitas perangkat lunak.



“Namun saat ini, kemajuan lebih lanjut di berbagai bidang seperti pembelajaran mesin, robotika, dan realitas virtual akan membutuhkan daya komputasi yang sangat besar yang tidak dapat lagi disediakan oleh miniaturisasi,” kata Leiserson. "Jika kami ingin memanfaatkan potensi penuh dari teknologi ini, kami harus mengubah pendekatan kami terhadap komputasi."



Pada bagian perangkat lunak, diusulkan untuk mempertimbangkan kembali strategi penggunaan perpustakaan dengan fungsionalitas yang berlebihan, karena ini merupakan sumber ketidakefisienan. Penulis merekomendasikan untuk berkonsentrasi pada tugas utama - meningkatkan kecepatan eksekusi program, dan bukan pada kecepatan penulisan kode.



Dalam banyak kasus, kinerja memang bisa ditingkatkan ribuan kali lipat, dan ini tidak berlebihan. Sebagai contoh, peneliti mengutip perkalian dua buah matriks berukuran 4096 × 4096. Mereka mulai dengan implementasi dengan Python sebagai salah satu bahasa tingkat tinggi yang paling populer. Misalnya, berikut adalah implementasi empat baris di Python 2:

for i in xrange(4096):
for j in xrange(4096):
for k in xrange(4096):
C[i][j] += A[i][k] * B[k][j]

Kode tersebut memiliki tiga loop bersarang, dan algoritme solusi didasarkan pada kurikulum aljabar sekolah.



Namun ternyata pendekatan naif ini terlalu tidak efisien untuk daya komputasi. Di komputer modern, ini akan berjalan selama sekitar tujuh jam, seperti yang ditunjukkan pada tabel di bawah.





Transisi ke bahasa pemrograman yang lebih efisien telah meningkatkan kecepatan eksekusi kode secara dramatis. Misalnya, program Java akan berjalan 10,8 kali lebih cepat, sedangkan program C akan berjalan 4,4 kali lebih cepat dari Java. Jadi, beralih dari Python ke C berarti eksekusi program 47x lebih cepat.



Dan ini baru awal pengoptimalan. Jika Anda menulis kode dengan mempertimbangkan kekhasan perangkat keras yang akan menjalankannya, Anda dapat meningkatkan kecepatan sebanyak 1.300 kali lagi. Dalam percobaan ini, kode pertama kali dijalankan secara paralel pada semua 18 inti CPU (versi 4), kemudian kami menggunakan hierarki cache prosesor (versi 5), menambahkan vektorisasi (versi 6), dan menerapkan instruksi Ekstensi Vektor Lanjutan (AVX) khusus di versi 7. Versi terbaru yang dioptimalkan kode hanya membutuhkan 0,41 detik, bukan 7 jam, lebih dari 60.000 kali lebih cepat dari kode Python asli.



Terlebih lagi, pada kartu grafis AMD FirePro S9150, kode yang sama berjalan hanya dalam 70ms, 5,4 kali lebih cepat dari versi 7 yang paling dioptimalkan pada prosesor serba guna, dan 360.000 kali lebih cepat dari versi 1.



Dalam hal algoritme, para peneliti mengusulkan pendekatan tiga cabang yang melibatkan eksplorasi area masalah baru, penskalaan algoritme, dan mengadaptasinya untuk lebih memanfaatkan perangkat keras modern.



Misalnya, algoritme Strassen untuk perkalian matriks dengan tambahan 10% mempercepat versi tercepat dari kode nomor 7. Untuk masalah lain, algoritme baru memberikan peningkatan kinerja yang lebih besar. Misalnya, diagram berikut menunjukkan kemajuan yang dibuat dalam efisiensi algoritme untuk menyelesaikan masalah aliran maksimum antara tahun 1975 dan 2015. Setiap algoritma baru meningkatkan kecepatan komputasi secara harfiah beberapa kali lipat, dan di tahun-tahun berikutnya dioptimalkan lebih lanjut.





Efisiensi algoritme untuk menyelesaikan masalah aliran maksimum pada graf dengan n = 10 ¹² simpul dan m = n ¹¹ sisi.



Dengan demikian, peningkatan algoritme juga berkontribusi untuk "meniru" hukum Moore secara terprogram.



Terakhir, dalam hal arsitektur perangkat keras, peneliti menganjurkan untuk mengoptimalkan perangkat keras agar masalah dapat diselesaikan dengan transistor yang lebih sedikit. Pengoptimalan melibatkan penggunaan prosesor yang lebih sederhana dan pembuatan perangkat keras yang disesuaikan dengan aplikasi tertentu, seperti GPU yang diadaptasi untuk grafik komputer.



“Peralatan yang disesuaikan dengan area tertentu bisa jauh lebih efisien dan menggunakan transistor yang jauh lebih sedikit, memungkinkan aplikasi berjalan puluhan atau ratusan kali lebih cepat,” kata Tao Schardl, salah satu penulis makalah penelitian. "Secara lebih umum, pengoptimalan perangkat keras selanjutnya akan merangsang pemrograman paralel dengan membuat area tambahan pada chip untuk penggunaan paralel."



Tren paralelisasi sudah terlihat. Seperti yang ditunjukkan pada diagram, dalam beberapa tahun terakhir, kinerja CPU meningkat semata-mata karena peningkatan jumlah inti.





Performa SPECint dari core individu dan prosesor single dan multi-core dari tahun 1985 hingga 2015. Unit dasarnya adalah mikroprosesor DX 80386 1985



Untuk operator pusat data, bahkan peningkatan terkecil dalam kinerja perangkat lunak dapat menghasilkan keuntungan finansial yang besar. Tidak mengherankan, perusahaan seperti Google dan Amazon kini memimpin inisiatif untuk mengembangkan CPU khusus mereka sendiri. Prosesor tensor (neural) TPU Google yang pertama dirilis , dan chip AWS Graviton berjalan di pusat data Amazon .



Seiring waktu, para pemimpin industri dapat diikuti oleh pemilik pusat data lain, agar tidak kalah efisiensi dari pesaing.



Para peneliti menulis bahwa di masa lalu, peningkatan kinerja yang eksplosif dalam prosesor tujuan umum telah membatasi ruang lingkup untuk pengembangan prosesor khusus. Sekarang tidak ada batasan seperti itu.



“Peningkatan produktivitas akan membutuhkan alat, bahasa pemrograman, dan perangkat keras baru untuk memungkinkan desain yang lebih efisien dengan mempertimbangkan kecepatan,” kata Profesor Charles Leiserson, rekan penulis penelitian. "Ini juga berarti bahwa pemrogram perlu lebih memahami bagaimana perangkat lunak, algoritme, dan perangkat keras saling cocok, daripada melihatnya secara terpisah."



Di sisi lain, para insinyur sedang bereksperimen dengan teknologi yang dapat lebih meningkatkan kinerja CPU. Ini adalah komputasi kuantum, tata letak 3D, sirkuit mikro superkonduktor, komputasi neuromorfik, penggunaan graphene alih-alih silikon, dll. Namun sejauh ini teknologi ini berada pada tahap percobaan.



Jika kinerja CPU benar-benar berhenti berkembang, maka kita akan menemukan diri kita dalam realitas yang sama sekali berbeda. Mungkin kita benar-benar harus mempertimbangkan kembali prioritas pemrograman kita, dan spesialis assembler akan sangat berharga.

---

Periklanan

Butuh server yang kuat ? Perusahaan kami menawarkan server epik - server virtual dengan CPU AMD EPYC, frekuensi inti CPU hingga 3,4 GHz. Konfigurasi maksimum akan mengesankan siapa pun - 128 inti CPU, RAM 512 GB, NVMe 4000 GB.