Seberapa sering CPU membuat kesalahan perhitungan?


22

Dalam Dijkstra's Notes on Structured Programming, dia banyak berbicara tentang kemampuan program komputer sebagai entitas abstrak. Sebagai akibat wajar, ia menyatakan bahwa pengujian tidak cukup. Misalnya, ia menunjukkan fakta bahwa tidak mungkin untuk menguji fungsi perkalian f (x, y) = x * y untuk setiap nilai besar x dan y di seluruh rentang x dan y. Pertanyaan saya menyangkut misc-nya. komentar pada "hardware buruk". Saya tahu esai ini ditulis pada tahun 1970-an ketika perangkat keras komputer kurang dapat diandalkan, tetapi komputer masih belum sempurna, sehingga mereka terkadang harus melakukan kesalahan perhitungan . Adakah yang tahu seberapa sering hal ini terjadi atau jika ada statistik tentang ini?



Inilah halaman wikipedia tentang bug Pentium FDIV , yang disebutkan oleh dua jawaban yang ada saat ini.
Cascabel

Kami bertahan tanpa adanya cadangan atau pengecekan kesalahan pada operasi CPU dasar, sehingga kami dapat dengan mudah memperkirakan batas atas untuk frekuensi kesalahan komputasi transient acak. Sebagian besar instruksi CPU melibatkan matematika (dalam menghitung alamat untuk operasi memori serta perhitungan), dan CPU modern melakukan miliaran operasi per detik, sebut saja> 1e14 operasi sehari. Jika 1 dari 10 kesalahan matematika akan memiliki efek yang jelas pada program (mungkin perkiraan rendah), dan kami tidak melihat kesalahan seperti itu setiap hari, tingkat kesalahan dasar untuk ALU harus <1e-13, dan saya akan menebak <1e-15.
Russell Borogove

@NickC: apakah Anda menyiratkan bahwa tidak ada yang praktis tentang pertanyaan ini? Jadi Anda pikir pertanyaan apakah perangkat keras berfungsi atau tidak tidak masalah? Bagaimana ketika itu benar-benar penting apakah program bekerja dengan baik (apakah pemrograman waktu nyata hanya teoretis, atau terlalu canggih untuk orang-orang di situs ini?)? Bagaimana dengan perangkat keras di mana satu pengguna dapat mencuri kunci dari pengguna lain karena informasi bocor melalui saluran samping? Sialan saya berharap ada tombol downvote untuk komentar.
Longpoke

1
@ Longpoke Me juga.
Nicole

Jawaban:


14

Kesalahan nyata / aktual di samping desain CPU, saya pikir Anda mencari SO ini Pertanyaan: Sinar Kosmik. Berapa probabilitas mereka akan memengaruhi suatu program . Saya tidak dapat memperoleh kutipan darinya karena SO diblokir lagi di kantor ( desahan ).

Mengabaikan hal di atas, saya ingat ada beberapa bug perhitungan FPU di Pentium awal, jadi mereka tentu saja tidak salah.

Saya tidak punya bukti kuat, tetapi usus saya mengatakan Anda mungkin harus lebih khawatir tentang bit Cache / RAM / Disk yang korup maka perhitungan menjadi salah.


40
SO diblokir di tempat kerja? Apakah seseorang di perusahaan Anda mencoba menyabot pengembangan perangkat lunak?
Nicole

3
Anda mengatakan bahwa seolah-olah hanya satu orang dan mereka belum berhasil ...;)
Dan McGrath

9
Saya tidak pernah bisa memahami alasan memblokir situs SFW di tingkat perusahaan. Karena mesin pencari adalah alat yang sangat berharga, Anda harus dapat melihat informasi yang mereka hasilkan.
Tim Post

@Dan, buka blokir. Anda harus bisa melakukan https-tunneling ke rumah.

4
Tertangkap melewati sistem hanya menyebabkan pemutusan hubungan kerja. Saya pindah ke AS dan mendapat pekerjaan baru.
Dan McGrath

6

Masalah besar dalam menjawab pertanyaan ini hari ini adalah bahwa produsen CPU membungkus errata untuk chip dalam NDA (NonDisclosure Agreement). Intel melakukan ini, IIRC.

Banyak produsen yang tidak terlalu rahasia mengeluarkan koreksi pada lembar data, tetapi tidak memberi tahu Anda apa yang berubah, jadi kecuali Anda lebih suka membandingkan ke-300 halaman, Anda akan kesulitan mengatakannya.

Ada banyak instruksi buruk di CPU, menonton laporan kernel Linux yang ditemukan pada saat boot cukup menarik.

Sangat terkait adalah kertas Google tentang kesalahan memori, mereka lebih umum daripada yang Anda pikirkan. "Kesalahan DRAM di Alam Liar: Studi Lapangan Skala Besar" Schoeder, Pinheiro dan Weber Awalnya diterbitkan di ACM SIGMETRICS pada tahun 2009. Diterbitkan ulang dalam Komunikasi ACM Feb 2011

Apa semua kesalahan memori ini berarti untuk pertanyaan Anda, adalah bahwa tanpa memori ECC, Anda tetap akan mendapatkan perhitungan yang salah.


5

Kembali ketika saya bekerja untuk vendor perangkat keras, diklaim bahwa tidak ada CPU yang pernah dibangun adalah bugfree. Dan itu hanya bug logika. Biasanya pabrikan menemukan sebagian besar dari mereka dan menghargai chip, atau menemukan pengaturan BIOS yang bekerja di sekitar mereka. Tetapi selain fakta hal-hal seperti sinar kosmik kadang-kadang membalik sedikit dalam memori (dan memori biasanya memiliki bit paritas atau sirkuit SECDED untuk menghemat daging Anda), selalu ada peluang terbatas bahwa sedikit akan dibaca dengan salah. Perhatikan bahwa bit bukan angka nol dan satu yang logis, tetapi hal-hal yang berisik seperti voltase dan arus, dan diberi noise hingga dalam sistem, selalu ada kemungkinan bit yang salah akan terbaca. Di masa lalu (sebagai programmer aplikasi), saya menemukan beberapa bug HW - baik dari jenis logika yang buruk, dan dari unit X di CPU Y kadang-kadang memberi saya jenis hasil yang buruk, saatnya untuk mendapatkan HW guys untuk mengganti berbagai chip. Sirkuit aktual melayang dengan waktu dan penggunaan, dan jika Anda siap untuk gagal, Anda bisa mulai mengambil kesalahan bit, terutama jika Anda overclocking, atau melebihi rentang operasi yang direkomendasikan.

Ini adalah masalah nyata untuk superkomputer, di mana perhitungan melibatkan 1e18 atau lebih operasi floating point direnungkan.


3

Konten berikut mungkin tentang kesalahan perhitungan dalam GPU.

Diberi waktu yang cukup, Intel i7-3610QM dan Nvidia GeForce GTX 660 akan tidak setuju satu sama lain mengingat instruksi yang sama. (cuda 5.5, compute_20, sm_20)

Jadi, satu yang tersisa untuk menyimpulkan bahwa salah satu dari keduanya membuat kesalahan.

Selama benchmark studi kelayakan simulasi partikel saya perhatikan bahwa setelah seribu atau lebih transformasi presisi ganda (transformasi termasuk dosa, cos, perkalian, pembagian, penambahan dan pengurangan) kesalahan mulai muncul.

Saya akan memberikan Anda sedikit kutipan angka untuk dibandingkan (angka pertama selalu CPU, GPU kedua)

-1.4906010142701069
-1.4906010142701074

-161011564.55005690
-161011564.55005693

-0.13829959396003652
-0.13829959396003658

-16925804.720949132
-16925804.720949136

-36.506235247679221
-36.506235247679228

-3.3870884719850887
-3.3870884719850896

(perhatikan bahwa tidak setiap urutan transformasi menghasilkan kesalahan)

Sementara kesalahan maksimum hampir dapat diabaikan (0.0000000000000401%)itu masih ada, dan berkontribusi terhadap kesalahan kumulatif.

Sekarang kesalahan ini mungkin disebabkan oleh perbedaan dalam implementasi salah satu pustaka intrinsik. Memang, sepertinya GPU lebih suka membulatkan atau memotong di mana CPU dibulatkan. Anehnya, ini hanya terjadi pada angka negatif.

Tetapi intinya adalah bahwa instruksi yang sama tidak selalu dijamin untuk memberikan hasil yang sama, bahkan pada mesin digital.

Saya harap ini berkontribusi.

EDIT sebagai sidenote: Dalam hal kesalahan aritmatika GPU, ini (ctrl + f "GPU Pertama dengan Dukungan Memori ECC") juga dapat menarik, meskipun tidak selalu relevan dengan kesalahan di atas.


Perhitungan floating point mungkin berbeda berdasarkan tempat penyimpanannya. Register FPU internal dari beberapa CPU memiliki panjang yang berbeda dari RAM, jadi tergantung dari mana ia memuat operan, ia dapat mencapai hasil yang berbeda. Untuk informasi lebih lanjut, saya sarankan floating-point-gui.de . Namun, ini bukan kesalahan perhitungan - ini adalah desain bagaimana floating point arithmetics bekerja.
Philipp

2
Bagi mereka yang tidak mengetahui cara kerja matematika FP, hanya untuk memperjelas pernyataan Philipp, perbedaan-perbedaan ini bisa jadi benar (karena perbedaan mereka bukan karena bug perangkat lunak atau bug perangkat keras). Perbedaan tersebut kemungkinan disebabkan oleh implementasi perangkat lunak atau implementasi perangkat keras. Kita harus menggunakan gagasan epsilon mesin tetap untuk menentukan apakah ini buggy: en.wikipedia.org/wiki/Machine_epsilon (pada dasarnya konstanta ini menggambarkan seberapa tepat operasi FP tunggal harus)
Thomas Eding

1

Dalam hal apa yang Anda anggap "CPU" yang sebenarnya (unit eksekusi, pipa .. dll) itu hampir tidak pernah terjadi. Ada masalah yang diketahui dengan salah satu rasa Pentium beberapa waktu lalu, tapi itu adalah satu-satunya yang pernah saya dengar. Sekarang, jika Anda mempertimbangkan set chip yang dibangun ke dalam prosesor atau setidaknya kemasan yang sama seperti pengontrol USB, TSEC, pengontrol DMA atau pengontrol memori, maka ada banyak errata di luar sana. Saya ragu ada semacam data statistik tentang itu.


0

Masalah "perangkat keras buruk" lainnya yang perlu dipertimbangkan dalam konteks ini adalah bahwa perangkat keras floating point secara inheren "lossy": ia memiliki presisi terbatas, dan dengan jumlah yang cukup besar (merujuk kembali ke kutipan Dijkstra asli) Anda tidak akan dapat membedakan antara xdan x + 1, atau bahkan x + 1000000. Anda bisa mendapatkan pustaka floating point presisi "tak terbatas", tetapi mereka lambat dan akhirnya masih dibatasi oleh memori yang tersedia.

Singkatnya, Dijkstra bekerja di bidang teori, dan perangkat keras / lunak nyata tidak cocok dengan cita-cita teoretis dengan sangat baik. (Ingat, "mesin Turing" asli menentukan pita kertas tanpa batas.)


2
Ini tidak selalu mempengaruhi provabilitas, yang merupakan konteks pertanyaan. Batas atas kerugian semacam ini dapat, dan seringkali, justru dipertanggungjawabkan secara teoritis. Dengan kata lain program masih dapat dibuktikan benar dalam margin kesalahan tertentu yang telah ditentukan. Di bidang-bidang tertentu saya menganggap siapa saja yang tidak mempertimbangkan masalah ini untuk tidak melakukan pekerjaan mereka dengan benar!
Elias Vasylenko

(1 - .7) * 100 harus 30 meskipun JavaScript akan kembali 30.000000000000004yang merupakan kesalahan. Apakah itu perangkat keras atau perangkat lunak, saya pribadi tidak yakin.
John
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.