Bisakah saya menggunakan semua 4 core CPU Raspberry Pi?


11

Saya bertanya-tanya apakah ada cara sederhana untuk "menyalakan" semua 100% CPU sehingga saya dapat menjalankan proses lebih cepat (seperti perhitungan python).

1) Apakah ini mungkin?

2) Apakah ada cara mudah untuk kembali normal?

3) Apakah ada cara untuk menggunakan lebih sedikit CPU jika diinginkan?

Saya sedang memikirkan interaksi baris perintah seperti:

pi@raspberry:~ $ sudo turnOnFourCores python run.py


1
Jawaban singkatnya adalah Tidak
Steve Robillard

16
Jawaban panjangnya adalah "Jika sesederhana itu, itu akan menjadi default"
Shadow

18
Kedua komentar Anda menyesatkan dan bisa menyiratkan bahwa Pi memiliki 4 core tetapi hanya pernah menggunakan 1. jawaban yang lebih baik adalah bahwa semua empat core ADALAH sudah, tapi itu Python (dan program lain, dalam hal ini) hanya akan menggunakan lebih dari 1 inti kecuali mereka multi-threaded. Python masih dapat secara efektif terjebak menggunakan inti tunggal bahkan dengan multi-threading karena kunci juru bahasa global, tapi itu sedikit di luar lingkup pertanyaan ini.
Sohcahtoa82

13
Untuk memperjelas, saya pikir OP memiliki kesalahpahaman tentang cara kerja multi-core CPU, dan jawaban Anda hanya memperkuat kesalahpahaman mereka.
Sohcahtoa82

6
Cara termudah untuk membuat program Python lebih cepat adalah menulis ulang dalam bahasa yang dikompilasi (atau setidaknya membuat waktu tugas-tugas penting menggunakan modul ac).
Milliways

Jawaban:


21

Secara default, komputer mana pun akan mencoba menggunakan semua core-nya kapan saja. Namun, itu hanya dapat mencapai ini ketika aplikasi multi-threaded. Jika tidak (yaitu skrip Python yang tidak menggunakan threadingmodul), maka itu hanya dapat digunakan secara maksimal, satu inti. Ini setara dengan 25% CPU pada CPU empat inti. Jika Anda ingin memodifikasi skrip Anda untuk menggunakan banyak core, Anda dapat membagi perhitungan Anda menjadi beberapa bagian, dan membuat multi-utas seperti yang ditunjukkan dalam dokumentasi Python .

Memperbarui:

Saat Anon menjawab , ini tidak akan berhasil tanpa bekerja dengan GIL Python (Global Interpreter Lock). Ini memungkinkan tugas untuk beroperasi (tampaknya) pada saat yang sama, tetapi tidak memungkinkan kode untuk dijalankan di beberapa core. Jika Anda menggunakan modul yang ditulis dalam C (mis. Numpy), mereka dapat memungkinkan Anda untuk menggunakan beberapa core berkeliling batasan itu. Selain itu, jika itu bukan opsi, Python menawarkan multiprocessing , yang memungkinkan Anda untuk menjalankan tugas apa pun pada banyak core.


Pembaruan - yang benar - menjelaskan mengapa bagian pertama dari jawabannya salah sehubungan dengan Python. Anda hanya bisa mengatasi keterbatasan Python ini dengan menulis modul C atau bahasa yang dikompilasi, di mana Anda tidak lagi menulis Python sama sekali. Jika kinerja sangat penting, pergi ke bahasa yang dikompilasi adalah jawaban yang tepat. (Multiprocessing tidak sama dari perspektif penggunaan sumber daya.)
Brick

4
@Brick Hanya untuk memperjelas, bahasa yang dikompilasi tentu bukan persyaratan untuk multithreading yang benar dalam proses. Heck, bahkan Python GIL adalah detail implementasi (diberikan, untuk CPython populer) - ada penerjemah Python lain yang akan multithread dengan senang hati, misalnya Jython dan IronPython.
Bob

4
Menambah kebingungan, Python adalah disusun; dalam kasus CPython mengkompilasi ke bytecode CPython yang dijalankan di VM CPython. Untuk Jython, ini dikompilasi ke bytecode Java yang dijalankan di JVM. Dan akhirnya, IronPython mengkompilasi ke CIL, yang menargetkan runtime .NET. Jadi, "pergi ke bahasa yang dikompilasi" untuk kinerja tidak terlalu masuk akal;)
marcelm

komputer mana pun akan mencoba menggunakan semua inti ketika bisa. Tidak juga, ia hanya akan menggunakan semua core-nya (atau melakukan hal lain) ketika disuruh . Perbedaan itu mungkin tampak jelas atau bahkan merendahkan bagi yang berpengalaman, tetapi sepertinya OP perlu menghargai bahwa itu tidak terjadi secara otomatis.
otomatis

13

Saya bertanya-tanya apakah ada cara sederhana untuk "menyalakan" semua 100% CPU sehingga saya dapat menjalankan proses lebih cepat (seperti perhitungan python).

Tidak dalam arti bahwa saya pikir Anda menyiratkan. Ini bukan masalah khusus untuk pi, juga, itu adalah kendala logis.

Semua komputer sendiri saat ini tidak memiliki banyak kapasitas untuk menentukan bahwa suatu proses yang berjalan sebagai satu utas dapat dijalankan secara paralel. Perhatikan bahwa pada titik ketika mereka mungkin memiliki kapasitas ini, tidak akan ada kebutuhan untuk programmer komputer, karena sistem komputer yang dapat melakukan ini mungkin juga menulis kode sendiri 1 ..

Pertimbangkan ungkapan matematika sederhana berikut:

(4 + 2) * 17 / (3 + 6)

Ada beberapa potensi untuk dihitung secara paralel, tetapi secara logis terbatas. Saya akan mengatakan tidak ada gunanya lebih dari dua utas, dan bahkan sebagian besar hanya satu:

#1 a) 4 + 2 b) 6 * 17 c) 102 / 9
#2 a) 3 + 6

Utas # 2 berkontribusi dengan menghitung 3 + 6 = 9, digunakan pada langkah C dengan utas # 1, menyimpannya satu langkah. Tapi itu sejauh paralelisme akan berguna sampai di sini. Sementara utas # 2 dapat menghitung 17/9 sementara # 1 melakukan 6 * 17, melakukan itu tidak ada gunanya, karena Anda sekarang memiliki dua jalur berbeda untuk tujuan yang sama yang tidak dapat digabungkan kembali. Yaitu, # 2 bisa tetap bekerja:

b) 17 / 9 c) 1.888 * 6

Dan berakhir dengan hasil yang sama dengan utas # 1 (11.333), tetapi mereka tidak saling membantu melampaui langkah A, oleh karena itu memiliki dua dari mereka mengejar tujuan ini adalah buang-buang waktu.

(Perhatikan bahwa contoh ini bukan yang literal; ini bermaksud untuk menunjukkan prinsip logis. Skala di mana tugas di-threaded dalam kode pengguna jauh lebih besar, tetapi Anda tidak perlu pelajaran nyata dalam pemrograman multi-threaded untuk pegang idenya di sini.)

Mengeksploitasi banyak prosesor memerlukan kode yang ditulis untuk melakukannya. Anda tidak bisa begitu saja mengambil apa pun dan berkata, "oh gunakan semua 4 core dan lakukan lebih cepat!". Bukan itu yang akan terjadi. Secara logis, banyak (..atau sebagian besar) masalah dan tugas melibatkan langkah-langkah yang tidak dapat terjadi secara paralel, mereka harus terjadi secara berurutan.


1. Tetapi lihat komentar Felix Dombek di bawah ini; Saya bukan ahli AI. Mungkin juga patut dicatat bahwa sesuai komentar Peter Corde, set dan prosesor instruksi kontemporer dapat dieksploitasi oleh OS untuk mengoptimalkan hal-hal berbutir halus secara paralel, dan pipa perangkat keras melakukan ini juga, meskipun tidak lintas core (satu core memiliki lebih dari satu hal yang terjadi, beroperasi pada aliran instruksi di berbagai titik sebelum eksekusi akhir mereka). Saya mencoba untuk tetap berpegang pada topik utas pengguna di sini karena saya pikir itu kurang lebih apa yang Anda peroleh.


4
Saya telah menulis banyak kode numerik paralel, dan ini agak menyesatkan untuk detailnya. Anda tidak memparalelkan pada tingkat operasi aritmatika individual seperti ini. (Jika kita memperluas di luar Raspberry Pi, beberapa compliers dan prosesor sudah akan memparalelkan beberapa bahkan di luar struktur threading.) Anda memparalelkan seluruh tugas dalam potongan yang lebih besar.
Brick

4
@Brick "Anda tidak memparalelkan pada tingkat operasi aritmatika individual seperti ini." -> Tentu saja tidak, tetapi saya akan membuatnya lebih eksplisit bahwa ini adalah analogi, bukan pelajaran tentang mur dan baut pemrograman multi-utas.
goldilocks

4
Paralelisme dalam perhitungan yang Anda gunakan sebagai contoh dilokalkan sedemikian rupa sehingga akan menciptakan paralelisme tingkat instruksi dalam program yang menghitungnya, dan CPU dengan eksekusi out-of-order dapat mengeksploitasi paralelisme itu sendiri.
Peter Cordes

2
RPi3 menggunakan superscalar 2-lebar berurutan en.wikipedia.org/wiki/ARM_Cortex-A53 , jadi dengan penjadwalan instruksi yang cermat kompiler masih dapat mengeksploitasi ILP dengan meletakkan dua addinstruksi di samping satu sama lain sehingga keduanya dapat berjalan dalam satu sama lain siklus jam. Multiply dan bagi sisanya berikut akan diserialisasi oleh dependensi data, seperti yang Anda tunjukkan.
Peter Cordes

1
Menentukan bagian yang dapat diparalelkan tidak selalu membutuhkan AI yang kuat. Dalam pengertian "umum", itu mungkin; tetapi mudah dibayangkan bahwa komputer dapat menggunakan beberapa pendekatan heuristik yang sebagian besar berfungsi dalam banyak kasus praktis. Seperti, komputer tidak membuktikan teorema terakhir Fermat, tetapi tentu saja ada program yang membuktikan teorema. Perhatikan bahwa kompiler modern untuk bahasa pemrograman sudah melakukan banyak penyusunan ulang kode sebagai bagian dari langkah-langkah optimasi mereka, yang melibatkan penalaran atas bagian yang dapat diparalelkan.
Felix Dombek

7

Tidak untuk python.

Orang lain menyarankan Anda untuk melihat threading, yang merupakan jawaban yang valid untuk sebagian besar bahasa, tetapi mereka tidak memperhitungkan bahwa Anda menggunakan python.

Python GIL tidak memungkinkan Anda untuk secara efektif menggunakan banyak inti.


3
GIL membuatnya sedikit lebih sulit untuk menggunakan semua 4 core. Sama sekali tidak membuatnya mustahil, atau bahkan benar-benar menantang.
Nama Palsu

5

Menggunakan banyak core membutuhkan secara eksplisit mengekspos paralelisme level-thread ke OS, yang biasanya mengharuskan programmer untuk menulis program multi-threaded. (Atau untuk menjalankan program single-threaded beberapa kali pada input yang berbeda, seperti kompilasi dengan make -j4)

Kompiler untuk beberapa bahasa mendukung paralelisasi otomatis. Sebagai contoh, C atau C ++ dengan OpenMP dapat mengkompilasi for()loop biasa ke dalam program yang memulai banyak utas.

#pragma omp parallel for
for(int i = 0; i < 1000000; ++i)
{
   A[i] = B[i] * constant + C[i];
}

Tapi tetap saja, ini harus terjadi ketika Anda menulis atau menyusun program. Tidak ada cara untuk perangkat keras dan OS saat ini untuk menggunakan banyak core untuk mempercepat program single-threaded.


Terkait: Bagaimana cara menjalankan satu utas pada beberapa inti? : jawaban: mereka tidak. Tetapi ada jenis paralelisme lain, seperti paralelisme tingkat Instruksi yang ditemukan dan dieksploitasi oleh inti CPU tunggal untuk menjalankan utas tunggal lebih cepat dari satu instruksi pada satu waktu.

Jawaban saya atas pertanyaan itu masuk ke beberapa perincian tentang bagaimana CPU modern menemukan dan mengeksploitasi paralelisme tingkat instruksi yang berbutir halus. (Sebagian besar berfokus pada x86). Itu hanya bagian dari cara kerja CPU normal, dengan memiliki beberapa instruksi dalam satu penerbangan sekaligus, dan bukan sesuatu yang perlu Anda aktifkan secara khusus. (Ada penghitung kinerja yang dapat memungkinkan Anda melihat berapa banyak instruksi per jam yang berhasil dijalankan CPU Anda saat menjalankan program, atau tindakan lainnya.)

Perhatikan bahwa RPi3 menggunakan inti CPU ARM Cortex-A53 yang dipesan . Setiap inti adalah superscalar 2-lebar (2 instruksi per jam sebagaimana diizinkan ILP), tetapi tidak dapat menyusun ulang instruksi untuk menemukan lebih banyak paralelisme tingkat instruksi dan menyembunyikan latensi.

Namun, CPU masih dalam tahap pipeline, sehingga jumlah total instruksi dalam penerbangan (mulai dari mengambil dan mendekode hingga ke tahap penulisan kembali pada akhir pipa) sangat signifikan. Ketika dependensi data tidak membatasi hal-hal, mungkin ada 2 instruksi di setiap tahap pipa yang sedang dikerjakan CPU, dengan throughput 2 instruksi per jam. (Itulah artinya 2-lebar.)

Itu tidak dapat menjalankan instruksi yang rusak, tetapi dengan pemesanan instruksi yang hati-hati (biasanya oleh kompiler) ia masih dapat menyembunyikan latensi dari suatu instruksi yang membutuhkan banyak siklus agar hasilnya siap. (mis. memuat bahkan jika hit di cache atau multiply akan membutuhkan banyak siklus, vs. penambahan yang siap pada siklus berikutnya). Caranya adalah dengan memesan instruksi asm sehingga ada beberapa instruksi independen antara yang menghasilkan hasil dan yang menggunakannya.

Memiliki perangkat lunak (kompiler) menjadwalkan instruksi secara statis lebih rapuh daripada memiliki perangkat keras yang dapat memesan ulang secara internal sambil mempertahankan ilusi berjalan dalam urutan program. Sangat sulit bagi kompiler untuk melakukan pekerjaan sebaik bahkan jendela kecil yang tidak sesuai pesanan untuk menyusun ulang instruksi karena cache-misses tidak dapat diprediksi, dan sulit untuk menganalisis rantai ketergantungan di seluruh panggilan fungsi pada waktu kompilasi. Dan jumlah register terbatas tanpa penggantian nama perangkat keras.


Semua ini adalah kenyamanan kecil ketika kode Anda berjalan lebih lambat dari yang Anda inginkan. Tentu ada banyak hal keren di bawah tenda di Cortex-A53, tapi ada lebih banyak barang keren di bawah tenda di Cortex-A57 (seperti eksekusi out-of-order hingga 3 instruksi per jam), dan lebih banyak lagi di CPU x86 besar seperti Skylake (belum lagi perbedaan kecepatan clock).

Cortex-A53 cukup fantastis dibandingkan dengan https://en.wikipedia.org/wiki/Classic_RISC_pipeline seperti MIPS asli yang akan Anda pelajari di kelas arsitektur komputer, tetapi menurut standar modern itu cukup rendah.


1
"Tidak ada cara untuk perangkat keras dan OS saat ini untuk menggunakan banyak core untuk mempercepat program single-threaded." tidak benar benar. Sebagai contoh, dalam satu program Java berulir tunggal, Java dapat melakukan semua itu GC dan analisis run-time / kompilasi pada core CPU tambahan. Analisis runtime adalah masalah besar karena dapat memutuskan untuk membuat beberapa optimasi berdasarkan menjalankan jalur kode tanpa biaya "untaian tunggal" apa pun dan dapat mempercepatnya dengan apa yang dipelajari dari analisis. Meskipun secara umum poin Anda bagus.
Bill K

@ Billill Agar adil, "program" dalam konteks itu adalah java, tidak myapp.jar, dan tentu saja tidak ada utas tunggal.
goldilocks

1
Benar, saya baru saja menunjukkan bahwa tergantung pada bagaimana runtime dirancang "kode yang Anda tulis", meskipun single threaded, dapat mengambil keuntungan dari core tambahan tanpa secara eksplisit mengkodekannya sebagai aplikasi multi-threaded. Python bisa menyediakan runtime yang lebih kuat juga, tetapi itu akan menjadi semacam gunanya. Ini bukan lompatan besar - saya pikir bahkan java hanya menggunakan seperti 1/2 inti tambahan untuk membantu dengan aplikasi berulir tunggal.
Bill K

" Tidak ada cara bagi perangkat keras dan OS saat ini untuk menggunakan banyak inti untuk mempercepat program berulir tunggal. " Dan segera setelah itu Anda menjelaskan bagaimana perangkat keras menjalankan instruksi secara paralel.
Thomas Weller

3
@ThomasWeller Ya, tetapi untuk menjadi pemilih pipelining prosesor tidak menggunakan banyak core; itu terkandung dalam satu inti, tetapi memungkinkan untuk bekerja pada beberapa aliran instruksi. Yaitu, itu adalah bentuk paralelisme, tetapi itu bukan bentuk multi-core threading.
goldilocks

4

Ini bukan bagaimana CPU bekerja ... sama sekali.

Seperti saat ini berdiri, CPU Anda benar-benar mampu berjalan pada penggunaan 100%, dengan asumsi bahwa itu tidak dicekik karena masalah suhu terkait pada 80 derajat Celcius atau lebih. Yang sedang berkata, Anda tidak (umumnya) ingin melihat CPU Anda dipatok pada 100%. Jika Anda secara rutin menggunakan utilisasi CPU 100%, kemungkinan Anda memiliki terlalu banyak untuk ditangani oleh prosesor Anda. Ini akan menyebabkan gagap dan pengalaman pengguna yang umumnya tidak bahagia.

Untuk membandingkan dengan sesuatu yang lebih fisik, utilisasi CPU Anda sangat mirip mobil. Mobil itu kemungkinan mampu melaju 100 mph, tetapi ada kemungkinan besar speedometer Anda membaca sesuatu secara signifikan di bawahnya. Ketika di kota, Anda mungkin tidak akan pernah bisa mencapai sekitar 25 mph. Namun itu tidak mengubah bahwa mobil dapat melaju 100 mph. Anda belum cukup menekan akselerator dengan cukup keras.

Jika Anda hanya membuat RPi melakukan lebih banyak hal (mendorong lebih banyak pada akselerator), Anda akan melihat angka utilisasi CPU naik. Sebagai contoh, perhatikan pemanfaatan CPU ketika Anda menjalankan perintah yesdi jendela terminal (Ingat bahwa ctrl+cmengakhiri perintah terminal). Ini akan meningkatkan CPU Anda sebesar 25% karena memaksimalkan salah satu dari empat core CPU Anda.


5
Saya pikir jawaban ini menyesatkan di mana dikatakan bahwa Anda umumnya tidak ingin CPU Anda berjalan pada utilisasi 100%. Ada banyak aplikasi intensif numerik di mana Anda benar-benar ingin utilisasi 100% karena Anda telah mendedikasikan mesin (atau mesin) untuk perhitungan. Untuk mendapatkan waktu superkomputer yang sebenarnya, Anda seringkali harus membuktikan bahwa kode Anda dioptimalkan dengan cukup baik untuk melakukan ini, jika tidak mereka akan menyangkal Anda sebagai pemborosan sumber daya. Jika Anda memiliki gugus Pi, Anda tidak mendapatkan kinerja komputer super, jelas, tetapi itu mungkin membuatnya lebih penting untuk memaksimalkan penggunaan, tidak kurang!
Brick

3
Saya agak setuju dengan Brick dalam arti bahwa ini tampaknya tersirat di sini bahwa jika prosesor berada pada 25%, itu karena untuk menghemat gas atau mematuhi batas kecepatan;) atau untuk bersikap sopan dan bukan sumber daya babi. Anda mungkin ingin memperjelas bahwa itu umumnya karena tugas apa pun yang menunggu pada I / O sebagian besar waktu. Hal-hal yang dapat menjalankan satu inti sepanjang jalan akan. Apa yang (idealnya) menjaga agar tidak mengganggu antarmuka pengguna adalah mengiris waktu - tetapi secara realistis, masih cukup mudah untuk membuat mesin inti tunggal kecil macet.
goldilocks

Pemanfaatan CPU 100% umumnya tidak menyebabkan UX yang buruk. Bahkan 1000% bisa cukup baik karena sebagian besar program tidak dibatasi oleh CPU tetapi oleh faktor lain. Satu-satunya program yang menjadi lambat karena beban CPU yang ekstrem adalah program yang benar-benar menggunakan CPU sepanjang waktu.
Oskar Skog

4

Jawaban lain memang memberikan perincian yang baik, tetapi tampaknya tidak menjawab pertanyaan Anda secara khusus.

  1. Ya, jika program (dan sistem operasi) diprogram untuk menghitung beberapa inti. ('Threading' adalah istilah dalam pemrograman di sini)
  2. Mesin menggunakan sebanyak atau sesedikit mungkin dari masing-masing inti yang dibutuhkan, untuk menyelesaikan tugas. jadi tidak perlu mengubah apa pun.
  3. Anda dapat menetapkan batas penggunaan maksimum, tetapi tidak perlu dalam penggunaan normal. lihat jawaban di sini: - /unix/151883/limiting-processes-to-not-exceed-more-than-10-of-cpu-usage

NB:

Jika Anda ingin meningkatkan kinerja pi secara keseluruhan, Anda mungkin ingin melihat Overclocking. Ini memungkinkan CPU berjalan pada tingkat yang lebih cepat. Kelemahannya adalah peningkatan produksi panas, masa pakai prosesor yang lebih rendah, dan peningkatan konsumsi daya.


2

Jika mungkin saya akan parameterisasi skrip dan jalankan dalam proses Python yang terpisah. Sebagai contoh:

cat parameters.txt | xargs -n1 -P4 python run.py

Alternatif lain adalah pustaka multiprosesor yang telah disebutkan, yang memungkinkan Anda melakukan proses fork-and-join python. Tetapi itu juga mengharuskan Anda untuk memiliki daftar parameter (seperti nama file) yang ingin Anda jalankan perhitungannya.


Bagian pertama: Ya, menganggap masalah yang dihadapi paralel dengan memalukan .
Peter Mortensen

Ahaa benar, saya hanya akrab dengan kolam pemrosesan multiprosesing maptetapi ternyata ia juga memiliki banyak konstruksi memori bersama yang cukup canggih.
NikoNyrh


0

Jika Anda ingin menguji RPI Anda. Anda dapat menjalankan stressseperti di sini , lalu Anda dapat melihat bagaimana CPU Anda digunakan htop. Ini berguna karena Anda dapat melihat apakah sumber daya Anda cukup, jika tidak cukup RPI Anda akan mencoba menggunakan terlalu banyak arus (arus listrik) dan itu akan mati.

Di sisi lain, jika Anda ingin menggunakan skrip python, Anda harus melihat joblibmana yang bagus ketika Anda ingin memparalelkan proses, dan dengan demikian Anda akan menggunakan jumlah prosesor yang Anda inginkan.


0

Walaupun semua jawaban ini benar dengan cara yang berbeda, memang benar bahwa sistem operasi akan secara otomatis menggunakan inti yang berbeda untuk menyebarkan beban. Anda dapat melihat ini dengan program python sederhana (temp.py katakanlah)

while True:
  x = 1.0

buka terminal dari desktop RPi Anda dan ketik $ topyang akan menampilkan kerja prosesor. Kemudian buka terminal lain dan python3 temp.pydan Anda akan melihat pekerjaan python3 naik ke waktu prosesor 100%. Kemudian buka terminal lain dan ulangi prosesnya dan lihat bagaimana Anda naik hingga 400%. Jadi pada satu tingkat seperti yang dikomentari @Shadow, sesederhana itu dan itu adalah default. Namun merancang program yang dapat menggunakan pemrosesan paralel adalah non-sepele seperti yang telah dijelaskan orang lain.


0

Jawabannya adalah YA tegas! Anda sederhana harus menulis program Anda untuk mengenalinya dan menggunakannya. Program yang melakukan ini dapat menggunakan core. Saya menulis milik saya untuk melakukan ini di Jawa dan dengan demikian saya bisa.

Jawaban di atas dari pengembang Python memiliki konsep yang sangat terbatas dari jawaban ini sehingga bisa sangat membingungkan tetapi jawabannya adalah YA dan hanya YA!


Bisakah Anda jelaskan?
SDsolar

0

Karena OP tidak menentukan python dalam pertanyaannya, saya ingin menyarankan dua bahasa modern yang berfungsi dengan baik pada Raspberry Pi dan memiliki cara yang sangat mudah untuk menggunakan konkurensi.

Favorit saya saat ini adalah bahasa Rust. Saya telah menulis dan menyusun program di Pi. Karat bagus karena mencegah banyak jenis bug penunjuk dan kondisi ras, yang membuat penulisan kode bersamaan lebih mudah dan aman. Rust dimaksudkan sebagai bahasa pemrograman sistem, tetapi dapat melakukan hampir semua hal yang dapat dilakukan C.

Bahasa lain seperti itu adalah Go (juga disebut Golang untuk memudahkan pencarian). Go dibuat oleh tim Google, dan merupakan bahasa yang cukup matang. Sangat mudah untuk membuat coroutine di Go, yang mereka sebut "Go rutinitas."

Kedua bahasa ini dapat mengkompilasi kode pada Raspberry Pi, bahkan Pi Zero. Namun, keduanya dapat dikompilasi silang dari komputer yang lebih cepat yang bagus untuk program besar.

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.