Mengapa Go sangat lambat (dibandingkan dengan Java)?


109

Seperti yang bisa kita lihat dari The Computer Language Benchmarks Game pada tahun 2010:

  • Go rata-rata 10x lebih lambat dari C.
  • Go 3x lebih lambat dari Java !?

Bagaimana ini bisa terjadi, mengingat kompiler Go menghasilkan kode native untuk dieksekusi?
Kompiler yang belum matang untuk Go? Atau ada masalah intrinsik dengan bahasa Go?

EDIT:
Sebagian besar jawaban menyangkal kelambatan intrinsik Go languge, mengklaim bahwa masalahnya ada di kompiler yang belum matang.
Oleh karena itu saya telah membuat beberapa tes sendiri untuk menghitung bilangan Fibonacci : Algoritma berulang berjalan di Go (freebsd, 6g) dengan samekecepatan seperti di C (dengan opsi O3). Rekursif tumpul berjalan di Go 2 timeslebih lambat daripada di C (dengan opsi -O3; dengan -O0 - sama). Tapi saya belum pernah melihat 10x jatuh seperti di Benchmarks Game.


36
Agar adil, C adalah ASM yang menyamar, dan Java memiliki beberapa optimisasi serius di bawah tenda hari ini.
Matthew Scharley

16
Mungkin tolok ukur juga tidak mencerminkan kekuatan Go. Mungkin tolok ukur lain sebenarnya lebih cepat dari ini. Selain itu, seringkali bukan kinerja tetapi keterbacaan kode yang paling penting.
extraneon

7
@extraneon: Saya setuju. Ingat, Go dirancang untuk Google dan Google secara rutin menjalankan kode pada 2 juta inti. Game Benchmarks hanya menggunakan 4 core, saya yakin.
Jörg W Mittag

4
@extraneon: Saya setuju secara umum, tetapi Go secara khusus dirancang dengan mempertimbangkan kecepatan, seperti dalam, "program yang dihasilkan berjalan hampir secepat kode C atau C ++ yang sebanding."
shosti

4
Pertanyaan Anda beranggapan terlalu banyak: "Sebagian besar jawaban menolak kelambatan intrinsik Go bahasa" adalah frasa yang salah untuk digunakan dalam pertanyaan. Apakah Anda memiliki pertanyaan untuk ditanyakan, atau pernyataan untuk dibuat? Silakan lihat c2.com/cgi/wiki?HostileStudent untuk memahami kesalahan Anda.
Chris

Jawaban:


102

Kompiler 6g dan 8g tidak terlalu optimal, jadi kode yang mereka hasilkan tidak terlalu cepat.

Mereka dirancang untuk berjalan cepat sendiri dan menghasilkan kode yang tidak masalah (ada sedikit pengoptimalan). gccgomenggunakan pass pengoptimalan GCC yang ada, dan mungkin memberikan perbandingan yang lebih berguna dengan C, tetapi gccgo belum melengkapi fitur.

Angka benchmark hampir seluruhnya tentang kualitas implementasi. Mereka tidak memiliki banyak hal yang harus dilakukan dengan bahasa seperti itu, kecuali sejauh implementasi menghabiskan waktu proses fitur bahasa pendukung yang tidak benar-benar dibutuhkan oleh benchmark. Dalam sebagian besar bahasa yang dikompilasi, kompiler yang cukup pintar secara teori dapat menghapus apa yang tidak diperlukan, tetapi ada saatnya Anda mencurangi demo, karena sangat sedikit pengguna bahasa yang sebenarnya akan menulis program yang tidak menggunakan fitur itu. . Memindahkan segala sesuatunya tanpa menghapusnya sepenuhnya (misalnya memprediksi tujuan panggilan virtual di Java yang dikompilasi JIT) mulai menjadi rumit.

FWIW, tes saya sendiri yang sangat sepele dengan Go ketika saya melihatnya (putaran penambahan bilangan bulat, pada dasarnya), gccgo menghasilkan kode menuju akhir yang cepat dari rentang antara gcc -O0dan gcc -O2untuk C. Go yang setara tidak lambat secara inheren, tetapi kompiler belum melakukan semuanya. Tidak mengherankan untuk bahasa yang berumur 10 menit.


7
Selain itu, mungkin saja program Go di Game Benchmarks Bahasa Komputer tidak dioptimalkan seperti C dan Java.
el.pescado

Bagaimana dengan gcc -O0 dan gcc -O3? Apakah ada niat bahwa penyusun akan "melakukan segalanya"?
igouy

@igouy: yah, saya cukup yakin bahwa ada niat gccgo akan melakukan pengumpulan sampah, yang saat ini tidak. Masih ada beberapa fitur untuk dimasukkan ke dalam kompiler g juga, misalnya mereka saat ini tidak menggunakan utas host dengan baik (khususnya, penjadwal goroutine tidak pre-emptive). Selain itu, saya tidak tahu rencana Google, apakah g compiler akan sangat dioptimalkan, atau hanya gccgo yang akan melakukannya.
Steve Jessop

1
@xitrium: Saya pikir tujuan Go adalah bahwa implementasi tidak boleh diharuskan menjadwalkan secara kooperatif, mereka dapat melakukan pre-empt jika mereka mau. Lihat contoh code.google.com/p/go/issues/detail?id=543 , yang belum ditutup sebagai "tidak masuk akal, memperbaiki apa yang disebut bug ini akan bertentangan dengan definisi bahasa Go", yang seharusnya terjadi jika Implementasi Go dilarang untuk mendahului :-) Masalah ini diperparah oleh fakta bahwa secara default Go hanya menggunakan satu thread host tidak peduli berapa banyak goroutine yang dapat dijalankan.
Steve Jessop

6
Jawabannya mungkin agak ketinggalan jaman sampai sekarang. Baru-baru ini, beta pertama Go 1.1 dirilis , mereka menyatakan bahwa kinerja program yang dikompilasi meningkat sekitar 30% hingga 40%. Seseorang tolong lakukan tes ini lagi.
fuz

51

Pada rilis Go FAQ berikutnya , sesuatu yang mirip dengan berikut ini akan muncul.

Performa

Mengapa Go berkinerja buruk pada benchmark X?

Salah satu tujuan desain Go adalah mendekati kinerja C untuk program-program yang sebanding, namun pada beberapa tolok ukur kinerjanya cukup buruk, termasuk beberapa dalam tes / bench. Paling lambat bergantung pada pustaka yang versi kinerja sebanding tidak tersedia di Go. Misalnya, pidigits bergantung pada paket matematika multi-presisi, dan versi C, tidak seperti Go, menggunakan GMP (yang ditulis dalam assembler yang dioptimalkan). Tolok ukur yang bergantung pada ekspresi reguler (regex-dna, misalnya) pada dasarnya membandingkan paket regexp sementara dari Go dengan pustaka ekspresi reguler yang matang dan sangat dioptimalkan seperti PCRE.

Game benchmark dimenangkan dengan penyetelan ekstensif dan versi Go dari sebagian besar benchmark membutuhkan perhatian. Jika Anda mengukur program C dan Go yang sebanding (pelengkap terbalik adalah salah satu contoh), Anda akan melihat kedua bahasa tersebut memiliki performa mentah yang jauh lebih dekat daripada yang ditunjukkan oleh rangkaian ini.

Namun, masih ada ruang untuk perbaikan. Kompilernya bagus tapi bisa lebih baik, banyak perpustakaan membutuhkan kinerja besar, dan pengumpul sampah belum cukup cepat (bahkan jika ya, berhati-hati agar tidak menghasilkan sampah yang tidak perlu bisa berdampak besar).

Dan inilah beberapa detail lebih lanjut tentang The Computer Benchmarks Game dari utas milis terbaru.

Pengumpulan sampah dan penampilan di gccgo (1)

Pengumpulan sampah dan penampilan di gccgo (2)

Penting untuk dicatat bahwa Game Benchmarks Komputer hanyalah sebuah game. Orang-orang dengan pengalaman dalam pengukuran kinerja dan perencanaan kapasitas secara hati-hati menyesuaikan dengan beban kerja realistis dan aktual; mereka tidak bermain-main.


1
Dan di sini beberapa detail dari utas yang sama yang telah Anda kecualikan - groups.google.com/group/golang-nuts/msg/2e568d2888970308
igouy

3
Penting untuk dicatat bahwa "benchmark adalah tempayan" - bukan hanya benchmark yang dipublikasikan sebagai permainan benchmark - shootout.alioth.debian.org/flawed-benchmarks.php
igouy

18
(dan semuanya ...) Tentu ini adalah "permainan" , tetapi ketika saya melihat bahwa Go hanya dua kali lebih lambat dari yang tercepat pada tolok ukur ini, kesan pertama saya adalah "wow, Go sepertinya cepat" , karena saya tahu tolok ukur ini cacat. Sebaliknya, ketika saya melihat Ruby 65 kali lebih lambat dari yang tercepat, saya berpikir "tidak akan menggunakan Ruby untuk usaha intensif saya selanjutnya secara bersamaan-numerik" . Jadi ini mungkin sebuah "permainan", tapi ada beberapa kebenaran di dalamnya jika Anda menganggapnya dengan sebutir garam.
SyntaxT3rr0r

Perencanaan kapasitas memiliki aspek yang sangat penting: biaya. Apakah Anda akan membutuhkan X box atau 2 * X membuat perbedaan besar pada akhirnya. Dan karena tidak ada yang bisa memperkirakan apa yang akan berjalan di masa depan pada itu, taruhan terbaik adalah melihat beban kerja yang berbeda. Saya telah memeriksa beberapa implementasi ini dan menemukan sebagian besar OK. Menurut saya hasilnya bisa dijadikan dasar estimasi.
Agoston Horvath

Umumnya, sistem dunia nyata dibatasi oleh IO bukan oleh CPU. Oleh karena itu, apakah Go 2x atau 5x lebih lambat hampir tidak membuat perbedaan sebesar perencanaan kapasitas seperti failover, load balancing, caching, topologi database dan sejenisnya. Inilah mengapa aplikasi pada skala YouTube mampu menjalankan banyak sistem mereka dengan Python.
Sujoy Gupta

34

Jawaban saya tidak terlalu teknis seperti jawaban orang lain, tapi menurut saya masih relevan. Saya melihat tolok ukur yang sama di Game Benchmarks Komputer ketika saya memutuskan untuk mulai mempelajari Go. Tapi sejujurnya saya pikir semua tolok ukur sintetis ini tidak ada gunanya dalam hal memutuskan apakah Go cukup cepat untuk Anda.

Saya telah menulis server pesan dengan Python menggunakan Tornado + TornadIO + ZMQ baru-baru ini, dan untuk proyek Go pertama saya, saya memutuskan untuk menulis ulang server di Go. Sejauh ini, setelah server mendapatkan fungsionalitas yang sama dengan versi Python, pengujian saya menunjukkan peningkatan kecepatan sekitar 4,7x dalam program Go. Ingat, saya baru membuat kode di Go mungkin selama seminggu, dan saya telah membuat kode dengan Python selama lebih dari 5 tahun.

Go hanya akan menjadi lebih cepat karena mereka terus mengerjakannya, dan saya pikir itu benar-benar tergantung pada bagaimana kinerjanya dalam aplikasi dunia nyata dan bukan benchmark komputasi kecil. Bagi saya, Go ternyata menghasilkan program yang lebih efisien daripada yang bisa saya hasilkan dengan Python. Itulah pendapat saya tentang jawaban atas pertanyaan ini.


3
Menurut Anda, seberapa lambat Anda akan menulis kode Go daripada Python?
Erik Engheim

7
@AdamSmith - Saya akan mengatakan saya akan menulis kode Go lebih lambat daripada Python hanya karena saya telah mengkode Python selama 7+ tahun dan hanya sedikit Go. Tetapi dalam hal Go versus bahasa terkompilasi yang diketik secara statis, saya yakin saya akan menulis Go lebih cepat daripada yang lain. Secara pribadi, saya merasakan hal yang paling mendekati kesederhanaan Python dengan kecepatan antara C dan C ++
jdi

5
Saya punya cerita serupa. Saya baru saja mulai belajar Go, dan menurut Benchmarks Game, Go lebih lambat daripada JavaScript V8. Ternyata program saya yang merupakan operasi biner intens berjalan 10x lebih cepat dengan kode Go yang tidak dioptimalkan daripada di VM V8 yang sangat dioptimalkan. Go mungkin lebih lambat daripada C dalam banyak operasi, namun tidak ada yang menulis situs web dalam C. Go sudah merupakan opsi yang sangat layak, dan hanya akan menjadi lebih baik, karena perpustakaan, kerangka kerja, dan alat baru muncul.
jika __name__ adalah None

1
@ user962247 ini adalah pernyataan selimut yang gila dan salah. Saya telah menulis Go selama bertahun-tahun sekarang dan itu sangat cepat. Tidak ada yang mengklaim itu akan mengalahkan C / C ++ / Java pada setiap tolok ukur sintetis yang memungkinkan. Tapi itu menang di beberapa (lihat situs permainan benchmark). Ambillah dari seseorang yang sebenarnya telah menulis kode produksi Go selama bertahun-tahun. Cepat dan produktif.
jdi


6

Banyak hal telah berubah.

Saya pikir jawaban yang benar saat ini untuk pertanyaan Anda adalah untuk membantah anggapan bahwa berjalan lambat. Pada saat Anda mengajukan pertanyaan, penilaian Anda telah dibenarkan, tetapi go telah mendapatkan banyak landasan dalam hal kinerja. Sekarang, ini masih tidak secepat C, tetapi tidak ada yang mendekati 10x lebih lambat, secara umum.

Game benchmark bahasa komputer

Pada saat penulisan ini:

source  secs    KB      gz      cpu     cpu load

reverse-complement
1.167x
Go      0.49    88,320  1278    0.84    30% 28% 98% 34%
C gcc   0.42    145,900 812     0.57    0% 26% 20% 100%

pidigits
1.21x
Go      2.10    8,084   603 2.10    0% 100% 1% 1%
C gcc   1.73    1,992   448 1.73    1% 100% 1% 0%

fasta
1.45x
Go      1.97    3,456   1344    5.76    76% 71% 74% 73%
C gcc   1.36    2,800   1993    5.26    96% 97% 100% 97%

regex-dna
1.64x
Go      3.89    369,380 1229    8.29    43% 53% 61% 82%
C gcc   2.43    339,000 2579    5.68    46% 70% 51% 72%

fannkuch-redux
1.72x
Go      15.59   952 900 62.08   100% 100% 100% 100%
C gcc   9.07    1,576   910 35.43   100% 99% 98% 94%

spectral-norm
2x
Go      3.96    2,412   548 15.73   99% 99% 100% 99%
C gcc   1.98    1,776   1139    7.87    99% 99% 100% 99%

n-body
2.27x
Go      21.73   952 1310    21.73   0% 100% 1% 2%
C gcc   9.56    1,000   1490    9.56    1% 100% 1% 1%

k-nucleotide
2.40x
Go      15.48   149,276 1582    54.68   88% 97% 90% 79%
C gcc   6.46    130,076 1500    17.06   51% 37% 89% 88%

mandelbrot
3.19x
Go      5.68    30,756  894 22.56   100% 100% 99% 99%
C gcc   1.78    29,792  911 7.03    100% 99% 99% 98%

Padahal, itu menderita secara brutal pada patokan pohon biner:

binary-trees
12.16x
Go      39.88   361,208 688 152.12  96% 95% 96% 96%
C gcc   3.28    156,780 906 10.12   91% 77% 59% 83%

Sekarang setara dengan Java, tetapi bukankah Go dibuat secara eksplisit agar lebih cepat daripada Java, sementara digunakan untuk hal yang sama (aplikasi jaringan sisi server)?
MaxB

1
@MaxB no itu tidak dibuat dengan tujuan menjadi lebih cepat dari Java. Itu dibuat dengan tujuan memiliki kinerja yang baik, kompilasi lebih cepat daripada C ++, dan lebih mudah dan konkurensi asli untuk memungkinkan pengembang menjadi lebih produktif. Mengalahkan kecepatan waktu proses bahasa lain bukanlah faktor pendorong.
jdi

5

Terlepas dari efisiensi Go yang tidak begitu baik terkait penggunaan siklus CPU, model konkurensi Go jauh lebih cepat daripada model thread di Java, misalnya, dan dapat dibandingkan dengan model thread C ++.

Perhatikan bahwa dalam tolok ukur thread-ring , Go 16x lebih cepat daripada Java. Dalam skenario yang sama, Go CSP hampir sebanding dengan C ++, tetapi menggunakan memori 4x lebih sedikit.

Kekuatan besar bahasa Go adalah model konkurensinya, Communicating Sequential Processes, CSP, ditentukan oleh Tony Hoare di tahun 70-an, mudah diterapkan dan disesuaikan untuk kebutuhan yang sangat serentak.


2

Ada dua alasan dasar mengapa Java lebih cepat daripada Go dan C ++, dan bisa lebih cepat daripada C dalam banyak kasus:

1) Kompiler JIT. Itu dapat menyebariskan panggilan fungsi virtual melalui beberapa level, bahkan dengan kelas OO, berdasarkan profil runtime. Ini tidak mungkin dilakukan dalam bahasa yang dikompilasi secara statis (meskipun kompilasi ulang yang lebih baru berdasarkan profil yang direkam dapat membantu). Ini sangat penting untuk sebagian besar tolok ukur yang melibatkan algoritme berulang.

2) GC. Alokasi memori berbasis GC hampir gratis, dibandingkan dengan malloc. Dan hukuman 'gratis' dapat diamortisasi di seluruh waktu proses - sering kali dilewati karena program berakhir sebelum semua sampah perlu dikumpulkan.

Ada ratusan (ribuan?) Pengembang yang sangat berbakat yang membuat GC / JVM efisien. Berpikir bahwa Anda dapat "membuat kode lebih baik dari semuanya" adalah suatu kebodohan. Ini adalah masalah ego manusia pada intinya - manusia sulit menerima bahwa dengan pelatihan yang tepat oleh manusia berbakat, komputer akan bekerja lebih baik daripada manusia yang memprogramnya.

Btw, C ++ bisa secepat C jika Anda tidak menggunakan dan fitur OO, tetapi kemudian Anda cukup dekat dengan hanya pemrograman di C untuk memulai.

Yang terpenting, "perbedaan kecepatan" dalam tes ini biasanya tidak ada artinya. Biaya IO lebih banyak daripada perbedaan kinerja, dan desain yang tepat yang meminimalkan biaya IO selalu menang - bahkan dalam bahasa yang ditafsirkan. Sangat sedikit sistem yang terikat dengan CPU.

Sebagai catatan terakhir, orang menyebut "permainan benchmark bahasa komputer" sebagai "ukuran ilmiah". Tesnya benar-benar cacat, Misalnya, jika Anda melihat tes Java untuk nbody. Ketika saya menjalankan tes pada OS / perangkat keras yang sama, saya mendapatkan sekitar 7,6 detik untuk Java, dan 4,7 detik untuk C - yang masuk akal - bukan 4x kelambatan laporan pengujian. Ini adalah umpan-klik, berita palsu, yang dirancang untuk menghasilkan lalu lintas situs.

Sebagai catatan terakhir, catatan terakhir ... Saya menjalankan pengujian menggunakan Go, dan hasilnya 7,9 detik. Fakta bahwa ketika Anda mengklik Go, itu membandingkannya dengan Java, dan ketika Anda mengklik Java, itu membandingkannya dengan C, seharusnya menjadi tanda bahaya bagi teknisi yang serius.

Untuk perbandingan dunia nyata dari Java, Go, dan C ++, lihat https://www.biorxiv.org/content/10.1101/558056v1 peringatan spoiler, Java menjadi yang teratas dalam kinerja mentah, dengan Go menjadi yang teratas dengan penggunaan memori gabungan dan waktu dinding.


salah. C ++ IS secepat C, apalagi kalau pakai OOP, itulah pell akte kelahirannya. lebih banyak abstraksi (seperti dalam kelas) TANPA DEGRADASI KINERJA RUNTIME, DENGAN ZERO EXTRA BYTES MEMORY. Jika Anda tidak mengetahuinya, tetaplah bermain-main dengan java, c #, go, python, dan lain

// Btw, C ++ bisa secepat C jika Anda tidak menggunakan dan fitur OO //, tetapi kemudian Anda cukup dekat dengan hanya pemrograman dalam C // untuk memulai. jika Anda mengatakan itu, Anda hanya memiliki sedikit petunjuk tentang c ++, demi Anda sendiri, jangan gunakan. c dan c ++ benci sihir dan pikiran abad pertengahan, bersifat takhayul, seperti oh saya dengar, baca di internet, itu pasti benar ... menjauhlah dari c dan c ++, mereka akan membalas Anda teman saya (nasihat jujur)

c adalah leluhur dari c ++. banyak orang masih menggunakannya ... c ++ adalah c yang lebih baik, di mana Anda dapat melakukan lebih banyak tanpa membayar harganya. penulis java, c # dan go tidak mendapatkannya, tentu saja, mereka mendapatkannya, tetapi apa yang dapat mereka lakukan?!? sama tentang kompatibel dengan kode (c) yang ada. lautan kehidupan nyata kode c! python adalah mainan yang bagus, selamat menikmati, saya berharap mereka melakukannya dengan benar, tetapi nah, zen dari python seharusnya dimulai dengan "compiler is your friend" ...

>> menunjukkan pemakaian CPU pada 30% untuk program Java << Tidak —— "1% 0% 0% 100%".
igouy

1
@igouy Saya mengakui bahwa itu adalah kesalahan yang mungkin saya buat - ketika saya melihat beban, saya menafsirkan dalam istilah 'beban sistem', dan dengan asumsi, pengguna / sistem / io / menganggur - kesalahan saya, dan itu adalah kesalahan yang substansial.
robert engels

1

Saya pikir fakta yang sering diabaikan adalah, bahwa kompilasi JIT dapat> kompilasi statis terutama untuk fungsi atau metode terikat akhir (runtime). Hotspot JIT memutuskan pada RUNTIME metode mana yang akan disebariskan, bahkan mungkin menyesuaikan tata letak data dengan ukuran cache / arsitektur CPU yang sedang dijalankannya. C / C ++ secara umum dapat memperbaiki (dan secara keseluruhan masih akan berkinerja lebih baik) dengan memiliki akses langsung ke perangkat keras. Untuk Go, hal-hal mungkin terlihat berbeda karena levelnya lebih tinggi dibandingkan dengan C, tetapi saat ini tidak memiliki sistem / compiler pengoptimalan waktu proses. Naluri saya memberi tahu saya, Go bisa lebih cepat daripada Java karena Go tidak memaksakan pengejaran pointer sebanyak itu dan mendorong lokalitas struktur data yang lebih baik + memerlukan lebih sedikit alokasi.


1

Faktanya, Go tidak hanya elegan dan efisien pada waktu desain, tetapi juga performa super pada saat berjalan. Kuncinya adalah menggunakan sistem operasi yang benar yaitu LINUX. Hasil profil kinerja di bawah Windows dan Mac OS, karena tidak ada kata yang lebih baik, satu atau dua kali lipat lebih rendah.


0

di bawah linux, waktu proses go super cepat, sangat sebanding dengan c / c ++. runtime go di bawah windows dan unix tidak berada di liga yang sama

perbandingan dengan java tidak begitu penting, go adalah untuk pengembangan sistem dan aplikasi (seperti java lebih seperti kerah biru untuk pengembangan aplikasi saja). tidak akan masuk secara detail, tetapi ketika hal-hal seperti kubernetes dituliskan, Anda menyadari bahwa itu bukan mainan ramah konsultan perusahaan

Saya tidak ingat Google pernah menyebutkan sekali pun tentang kompromi yang Anda maksud. go adalah desain yang baik, sederhana, elegan dan efisien untuk merancang sistem dan program tingkat aplikasi, memiliki petunjuk, alokasi memori yang efisien dan deallocation, menghindari komplikasi yang timbul dari warisan implementasi yang begitu mudah untuk tidak digunakan, memberi Anda rutinitas bersama dan modern lainnya cara untuk menulis aplikasi berkinerja tinggi dalam waktu dan anggaran. sekali lagi, go super cepat di bawah linux, yang memang dirancang untuk itu (sangat senang melakukannya)


-4

Baik Java dan C lebih eksplisit dengan definisi data dan metode (fungsi) mereka. C diketik secara statis, dan Java kurang begitu dengan model pewarisannya. Ini berarti cara penanganan data cukup banyak ditentukan selama kompilasi.

Go lebih implisit dengan definisi data dan fungsinya. Fungsi bawaan lebih bersifat umum, dan kurangnya hierarki tipe (seperti Java atau C ++) membuat Go kehilangan kecepatan.

Perlu diingat bahwa tujuan Google untuk bahasa Go adalah memiliki kompromi yang dapat diterima antara kecepatan eksekusi dan kecepatan pengkodean. Saya pikir mereka mencapai titik yang bagus pada upaya awal mereka, dan hal-hal hanya akan meningkat dengan lebih banyak pekerjaan yang dilakukan.

Jika Anda membandingkan Go dengan bahasa yang diketik secara lebih dinamis yang keunggulan utamanya adalah kecepatan pengkodean, Anda akan melihat keunggulan kecepatan eksekusi Go. Go 8 kali lebih cepat dari perl, dan 6 kali lebih cepat dari Ruby 1.9 dan Python 3 pada benchmark yang Anda gunakan.

Pertanyaan yang lebih baik untuk ditanyakan adalah Go merupakan kompromi yang baik dalam kemudahan pemrograman versus kecepatan eksekusi? Jawaban saya adalah ya dan seharusnya menjadi lebih baik.


20
"kurangnya tipe hierarki (seperti Java atau C ++) memberikan Go kerugian kecepatan" —apa?
Erik Kaplun

6
"Go lebih implisit dengan definisi data dan fungsinya." Salah. Apakah maksud Anda bagaimana tipe dapat mengimplementasikan metode tanpa menjelaskannya? Kompilator mendeteksi tipe - keanggotaan antarmuka. Ini cepat. "Fungsi bawaan lebih bersifat umum" tidak, fungsi bawaan, seperti yang lainnya, dikompilasi. Hal yang sama terjadi dengan template C ++. "kurangnya hierarki tipe (seperti Java atau C ++) membuat Go kehilangan kecepatan" - salah, hierarki tipe tidak ada hubungannya dengan eksekusi waktu proses.
Malcolm
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.