Akankah fungsi inti dalam QGIS mengeksploitasi multi-threading?

Setelah membaca Mengaktifkan pemrosesan multithreaded di QGIS? , Saya bertanya-tanya apakah QGIS 2.6 akan memasukkan ini ketika menjalankan berbagai proses. Saya memeriksa secara online dan saya hanya bisa menemukan bahwa rendering multi-threaded diperkenalkan ke QGIS 2.4 (saya berasumsi itu akan tersedia lagi di 2.6). Sekarang peta dapat digambar ulang dengan sangat cepat terutama ketika berhadapan dengan dataset besar.

Saya membaca bahwa cukup sulit untuk menyertakan multi-threading ke fungsionalitas inti dan bahwa pengguna disarankan untuk memanipulasi kode Python untuk mencapai hal ini, seperti dalam operasi Paralelisasi GIS di PyQGIS? .

Saya juga memeriksa permintaan fitur tetapi sudah ditutup selama 9 bulan oleh Tim Sutton dengan komentar terakhir adalah:

"Saya menutup ini - Martin Dobias memiliki implementasi di cabang yang akan digabung setelah QGIS 2.2"

Akankah beberapa fungsi dalam QGIS 2.6 mengeksploitasi multi-threading (atau apakah akan kembali difokuskan pada rendering) dan jika tidak, apakah itu akan berubah di QGIS 3.0?

— Yusuf
sumber

Multithreading tidak sesuai untuk sebagian besar tugas GIS, yang cenderung berorientasi pada aliran, sederhana, dan I / O. Sulitnya menyatukan hasil biasanya tidak sepadan dengan usaha untuk mengantri secara mandiri (sebaliknya melakukan tugas sederhana segera). Oleh karena itu, definisi "eksploitasi" harus diperdebatkan secara signifikan.

— Vince

@Vince - Terima kasih, saya mengerti bahwa multithreading bukan prioritas utama untuk banyak kasus penggunaan. Tetapi karena beberapa pekerjaan untuk mencapai hal ini telah dilakukan, saya bertanya-tanya apakah dukungan untuk ini (yang mungkin merupakan istilah yang lebih baik daripada "exploit") akan hadir dalam versi QGIS baru =)

— Joseph

@PolyGeo - Terima kasih, titik adil dan satu yang cukup cocok untuk format Tanya Jawab ini. Saya setuju :)

— Joseph

Jawaban:

Saya pikir jawaban untuk QGIS 3.0 dapat ditemukan dalam percakapan terakhir yang diposting di Nabble :

Apakah Pemrosesan dalam QGIS 3 mendukung paralelisasi?

Mengutip Nyall Dawson:

Jika Anda setelah paralelisasi dalam satu algoritma (misalnya fitur buffering menggunakan beberapa utas) maka saya tidak mengetahui adanya rencana untuk menangani hal ini.

— mgri
sumber

Temuan yang bagus! Meskipun saya sedikit bingung dengan kutipan yang mengikuti apa yang Anda kutip: "Cara yang bagus dan (secara teoritis) mudah untuk mendapatkan algoritma multithreaded, dan akan mudah untuk menyesuaikan banyak algoritma yang ada dengan ini (buffer, centroid, transform, translate, .... Pada dasarnya segala sesuatu yang beroperasi pada setiap fitur secara terpisah) . Sudah saya pahami bahwa sebagian besar algoritma beroperasi pada setiap fitur secara individual karena jika Anda tidak secara manual memilih fitur individual, algoritma secara otomatis memproses semuanya?

— Joseph

Saya pikir kutipan yang Anda kutip adalah tentang kemungkinan melakukan pengeditan langsung pada layer (alih-alih menghasilkan output baru): pada kenyataannya, berikut ini ia berbicara tentang kemungkinan melakukan operasi buffer langsung pada layer saat ini, tanpa pemrosesan lebih lanjut dari output yang dikembalikan.

— mgri

Poin bagus hmm. Saya berharap dev QGIS juga bisa berkomentar dan mengkonfirmasi ini :)

— Joseph

GIS SE bukan situs diskusi. Jika Anda menginginkan respons dari penyedia tertentu, saya sarankan Anda langsung menanyakannya.

— Vince

@ joseph Ada banyak algoritme (misalnya menghitung persimpangan garis atau fitur pelarutan) di mana seseorang tidak dapat beroperasi pada fitur individual.

— underdark

Rendering hanya pada saat ini (QGIS 2.6).

Martin dan saya telah berbicara tentang semacam API proses berulir generik tetapi hanya berbicara pada saat ini.

— Nathan W
sumber

Terima kasih Nathan, apakah menurut Anda usaha ini layak dikejar atau menambah / meningkatkan fungsi dianggap prioritas yang lebih tinggi? Ini hanya karena penasaran :)

— Joseph

Ini layak untuk dikejar, tapi saya tidak menduga itu tugas yang mudah.

— Nathan W