Ctags: ctag paralel

Halo,

sementara implementasi paralel yang dibangun dapat menarik, ini sudah memungkinkan untuk memparalelkan memperbarui basis kode besar dengan meluncurkan ctag yang berbeda pada direktori yang berbeda dan kemudian menggabungkan file yang dihasilkan (yang dapat dilakukan hanya dengan menjatuhkan baris yang dimulai dengan ! dari semua file kecuali satu dan menggunakan sort --merge pada semua file sesudahnya).

Namun, saya tidak yakin Anda akan mendapatkan percepatan apa pun dari ctag yang diparalelkan, karena saya berharap mesin modern terikat dengan I/O. Itu perlu diprofilkan untuk memastikannya.

@mawww Saya yakin https://github.com/ggreer/the_silver_searcher tidak akan setuju :wink:

Menjalankan banyak ctag akan sangat sulit untuk dikoordinasikan dari emacs standar https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

@mawww Saya yakin https://github.com/ggreer/the_silver_searcher tidak akan setuju :wink:

Poin bagus.

Menjalankan banyak ctag akan sangat sulit untuk dikoordinasikan dari emacs standar https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

Pembungkus skrip shell sudah bisa berjalan jauh, tapi ya mungkin lebih efisien untuk mengintegrasikannya langsung ke dalam ctags.

@fommil Posting blog orang itu tentang masalah ini tidak begitu jelas dari mana ia mulai ke mana perginya (baik, Anda dapat membacanya yang tersirat, tapi yah), dan bagaimanapun juga itu benar-benar tidak banyak. Dan saya tidak bermaksud untuk mengabaikan salah satu karyanya, tapi saya tidak akan sepenuhnya mempercayai hasil dari seseorang yang tampaknya baru saja belajar tentang multithreading (terutama karena seberapa banyak mutex yang disalahgunakan menghancurkan kinerja apa pun yang dapat diberikan MT) . Tidak mengatakan dia tidak sepenuhnya benar, tetapi saya harus diyakinkan :)
Dan perhatikan bagaimana pengujiannya sendiri menunjukkan bahwa pada mesinnya terlalu banyak utas pekerja dengan cepat menjadi lebih buruk daripada tidak ada paralelisasi sama sekali. Ini lucu, tetapi cenderung sangat bergantung pada perangkat keras, OS, dan data untuk diproses, jadi mungkin lebih masuk akal daripada "baik, menggunakan utas N tampaknya berkinerja lebih baik dalam pengujian saya".

Juga, alasan lain mengapa itu tidak begitu menarik bagi saya adalah karena saya tidak hanya tidak percaya itu akan memberi kita begitu banyak, tetapi itu akan menjadi pekerjaan yang rawan kesalahan dalam jumlah besar. Saat ini basis kode CTags sama sekali tidak dalam bentuk untuk mendukung utas penguraian tag paralel. Semua yang Anda _mungkin_ dapat pisahkan dengan relatif mudah adalah init/directory traversal dan _one single_ parser thread.
Dan akhirnya, saya yakin kami memiliki pengoptimalan yang lebih masuk akal untuk dilakukan di mana saja di basis kode (dan terutama di parser).

Jadi tentu saja, multithreading mungkin _dapat_ memiliki _beberapa_ manfaat jika digunakan dengan baik, tetapi sepertinya bukan peningkatan yang paling menarik.

Juga, alasan lain mengapa itu tidak begitu menarik bagi saya adalah bahwa […] itu akan menjadi pekerjaan yang rawan kesalahan dalam jumlah besar. Saat ini basis kode CTags sama sekali tidak dalam bentuk untuk mendukung utas penguraian tag paralel. Semua yang Anda _mungkin_ dapat pisahkan dengan relatif mudah adalah init/directory traversal dan _one single_ parser thread.

BTW, saya tidak bermaksud bahwa meningkatkan area ini dalam kode bukanlah ide yang baik, saya pikir itu (terutama untuk kemungkinan libctag di masa depan). Maksud saya jika kinerja adalah tujuannya, itu mungkin (saat ini) tidak sepadan dengan usaha, dan ada area yang lebih penting untuk difokuskan.

BTW, menjalankan profiler dan membuat profil banyak sekali data dalam trilyun cara mungkin akan menarik.

Paralel GNU dapat membantu Anda.

Seperti yang disebutkan sebelumnya , mengoptimalkan membaca dapat sedikit mempercepat ctag.

Eksekusi parser secara paralel dapat mempercepat banyak hal jika I/O berasal dari cache (dan ini sering kali terjadi saat Anda menjalankan ctags pada direktori dari editor).

@pragmaware IMO, perpustakaan tidak boleh bercabang.

Jika Anda membaca teks bahasa Jepang, lihat artikelnya, https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(Setelah menulis komentar ini, saya menemukan repositori git untuk ptags (https://github.com/dalance/ptags). Halaman ini ditulis dalam bahasa Inggris.)

Ini melaporkan alat bernama ptags yang dikembangkan penulis. Alat ini ditulis dalam Rust dan membungkus ctags.
Ini menjalankan ctags paralel untuk set input.
Saya tidak menjarah internalnya. Namun, itu jelas menjalankan beberapa proses ctag.

Hasilnya cukup mengesankan. 5 kali lebih cepat dari pemrosesan tunggal. Jumlah CPU tidak ditulis. Ukuran memori mungkin cukup (=128GB). Penulis menjalankan 10 kali ptags untuk set input yang sama untuk membuat cache halaman menjadi panas.

Meskipun hal-hal ini harus dilakukan dalam pembungkus seperti ptags, sulit untuk mengabaikan hasil yang bagus ini.
Saya meretas dengan cepat. https://github.com/masatake/ctags/tree/parallel
Opsi yang baru diperkenalkan --_parallel menjalankan beberapa proses ctag di _parallel.

Jumlah proses pekerja, 8, adalah kode keras. PC catatan saya memiliki 8 core.
MEMORI adalah 32 GB. Input target adalah pohon sumber kernel Linux terbaru.
.ctags saya cukup berbulu.

Hasilnya hampir sama: 2 ~ 3 kali lebih cepat.

[yamato@master]~/var/ctags-github% cat run.sh
cat run.sh
for i in $(seq 1 5); do
    echo "#"
    echo "# TRAIL #$i"
    echo "#"
    echo "# parallel 8"
    time  ./ctags    --_parallel -R  ~/var/linux > /dev/null
    echo "# single"
    time  ./ctags -o - --sort=no -R  ~/var/linux > /dev/null
done
[yamato@master]~/var/ctags-github% bash run.sh 
bash run.sh 
#
# TRAIL #1
#
# parallel 8

real    0m29.073s
user    3m5.791s
sys 0m32.347s
# single

real    1m21.397s
user    1m14.601s
sys 0m6.521s
#
# TRAIL #2
#
# parallel 8

real    0m29.746s
user    3m4.601s
sys 0m32.175s
# single

real    1m26.660s
user    1m19.176s
sys 0m7.191s
#
# TRAIL #3
#
# parallel 8

real    0m28.290s
user    3m2.524s
sys 0m31.081s
# single

real    1m21.927s
user    1m14.775s
sys 0m6.896s
#
# TRAIL #4
#
# parallel 8

real    0m28.644s
user    3m3.839s
sys 0m31.756s
# single

real    1m13.319s
user    1m7.294s
sys 0m5.843s
#
# TRAIL #5
#
# parallel 8

real    0m29.274s
user    3m9.387s
sys 0m32.363s
# single

real    1m13.621s
user    1m7.487s
sys 0m5.941s
[yamato@master]~/var/ctags-github% 

(Saya membandingkan kedua file tag. Tidak ada perbedaan.)

Jauh dari memuaskan, tetapi ini adalah tempat yang baik untuk memulai.

Saya bertanya-tanya apakah output pekerja harus dikumpulkan atau tidak.

hai @masatake Saya mencoba untuk menutup semua tiket terbuka saya yang tidak saya rencanakan untuk dikerjakan. Jika Anda tertarik untuk mengerjakan tiket ini, bisakah Anda menyalin teks ke tiket baru?

Saya akan mengerjakan item ini di masa depan. Saya ingin tetap membuka item ini karena catatan diskusi di sini akan sangat berharga bagi saya.

@masatake Anda masih dapat menautkan ke tiket ini dari yang baru dan menyimpan sejarah lengkapnya. Ini akan sangat membantu saya, karena saya mencoba membersihkan tab "Masalah" saya untuk pekerjaan baru dan saya tidak ingin kekacauan seperti tiket ini menghalangi.

@fommil , saya tidak melihat bagaimana Anda dapat menimpa @masatake , yang merupakan kekuatan pendorong di balik Universal Ctags, dengan 2.700 komit versus jumlah komit Anda nol. Setelah Anda membuka bug (atau, dalam bahasa GitHub, "masalah"), bug ini menjadi milik proyek. Saya yakin Anda dapat menghapusnya dan tidak menerima email apa pun tentangnya.

Pembukaan kembali.

@dtikhonov @masatake tolong tutup tiket ini. Ini adalah satu-satunya tiket di tampilan https://github.com/issues saya yang tidak relevan dengan pekerjaan saya.

Tidak mungkin untuk menghapus tiket dari tampilan ini kecuali tiket ditutup. Bahkan jika saya berhenti berlangganan.

Memang, saya tidak menyadari bahwa pemilik repo akan memiliki kontrol ini ketika saya membuat tiket, jika tidak saya tidak akan melakukannya.

jika Anda ingin mengerjakan ini, silakan buat tiket baru dan referensikan tiket ini, semua diskusi dipertahankan. Atau cukup salin tempel konten https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 ke tiket baru.

Saya tidak berpikir ini banyak untuk saya tanyakan.

Bisakah Anda membuat akun GitHub temporal hanya untuk copy-paste?
Jadi Anda bisa melakukan copy-paste sendiri.
Kemudian, Anda dapat menghapus akun tersebut.

tentu, jika itu satu-satunya cara untuk memperbaikinya, saya bisa melakukannya.

selesai! Terima kasih telah mengizinkan saya menutup tiket ini. Ini membersihkan tugas TODO saya secara signifikan.