ROOT untuk Menganalisis Data Petabyte secara Ilmiah

 (root.cern)
1 poin oleh GN⁺ 2024-06-02 | 1 komentar | Bagikan ke WhatsApp
  • Mendukung pemrosesan data berskala besar dan analisis ilmiah yang dibutuhkan dalam riset berskala besar seperti fisika energi tinggi, dan saat ini lebih dari 2 eksabita data tersimpan dalam file ROOT
  • ROOT juga digunakan dalam penemuan Higgs, menjadikannya alat dengan contoh penggunaan nyata yang telah teruji dalam analisis data eksperimen
  • Dapat digunakan dan dimodifikasi secara bebas sebagai open source, serta menerima kontribusi pengguna melalui proses pengembangan terbuka
  • Interpreter C++ yang disertakan cocok untuk prototyping cepat, dan semua komponennya dapat diakses melalui dynamic binding Python
  • Juga mendukung Jupyter Notebook, sehingga analisis berbasis C++ dan Python dapat diperluas ke lingkungan notebook; kabar rilis, pelatihan, dan hackathon juga terus dipublikasikan

Peran ROOT dalam Analisis Data

  • ROOT adalah alat yang memungkinkan pemrosesan data dalam jumlah besar dan analisis ilmiah

Pengembangan Open Source dan Kontribusi

Cara Penggunaan Berbasis C++·Python·Notebook

Blog dan Kabar Rilis

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-02
Komentar Hacker News

  • Jadi teringat masa lalu. Saat bekerja di bidang fisika partikel, saya banyak memakai ROOT, dan punya hubungan benci tapi sayang dengannya
    Di satu sisi ada banyak utang teknis dan inersia yang aneh, tetapi di sisi lain ada cukup banyak hal yang lebih mudah dilakukan di ROOT dibanding pilihan yang lebih “modern” seperti matplotlib. Misalnya histogram, data yang sangat terstruktur dengan objek berisi field yang disimpan dalam “kolom”, menggambar fungsi secara langsung tanpa mengalokasikan array x/y secara terpisah, dan sebagainya
    API berorientasi objek yang intuitif juga menyenangkan. Rasanya lebih dekat ke C++ atau Java gaya lama dibanding method chaining di pandas/matplotlib, penyalahgunaan sintaks [], dan berbagai perilaku ajaib. Tidak elegan dan bertele-tele, tetapi dalam analisis ilmiah itu justru bisa menjadi kelebihan
    Ketika saya keluar sekitar 5 tahun lalu, ROOT sedang berubah; interpreter CINT lama sudah disingkirkan dan basis kodenya sudah dipindahkan ke berbasis clang. Setahu saya sekarang analisis bisa dijalankan di Jupyter dengan C++ atau Python, dan saya dengar kualitas kodenya juga jauh membaik

    • Hal terbaik dari ROOT adalah cara memuat datanya. TTree yang membaca potongan data berbasis kolom dari disk benar-benar ide bagus, dan setelah lulus lalu pindah ke industri pun saya terus mencari sesuatu yang bekerja dengan cara yang sama
    • Mungkin karena matplotlib tidak berpusat pada histogram, atau karena sekarang RAM sudah cukup, saya sering melihat scatter plot yang tidak berguna karena terlalu banyak titik saling bertumpuk. Menyakitkan untuk dilihat
    • Semua orang punya hubungan benci tapi sayang dengan ROOT. Agak seperti Sindrom Stockholm
    • Saya penasaran apakah Haskell juga cocok untuk membuat hal semacam ini
    • Sekarang, berkat ChatGPT, API matplotlib yang mengerikan tidak lagi sebesar dulu masalahnya

  • Tidak banyak alasan bagi analisis baru untuk memakai ROOT sebagai default. Lebih baik memakai pilihan yang lebih ramah pengguna dan lebih waras seperti uproot
    Mungkin ada workflow legacy, atau eksperimen tertentu yang menumpuk banyak patch kustom di atas ROOT, tetapi kalau hanya untuk analisis fisika, itu bisa jadi pilihan yang menyiksa diri sendiri
    Saya juga suka halaman 404-nya. Dan ini bukan soal room 404
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • Kritik umum terhadap uproot adalah kurang fleksibel ketika perhitungan per baris menjadi rumit. Itu karena loop for di Python terlalu lambat
      Dalam kasus seperti ini bisa memakai Numba, atau, jika kebetulan berjalan baik; kalau tidak, izinkan promosi tanpa malu: bisa memakai Julia: https://github.com/JuliaHEP/UnROOT.jl
      Diskusi HN sebelumnya tentang penggunaan Julia dalam fisika partikel: https://news.ycombinator.com/item?id=38512793

  • Melihat proyek perangkat lunak berskala besar yang dipakai untuk penemuan ilmiah itu keren
    Contoh lain, LIGO menggunakan GStreamer untuk mencari gelombang gravitasi: https://lscsoft.docs.ligo.org/gstlal/

    • Dalam kasus ini justru hampir kebalikannya. CERN membutuhkan framework analisis data, jadi CERN mengembangkan, memelihara, dan membukanya ke publik
      Namun saya tidak tahu apakah benar-benar ide bagus bagi orang luar untuk memakainya. Pengalaman saya mungkin sudah agak lama, tetapi dulu cukup kasar dan usang. Keuntungan besar dalam pekerjaan di CERN atau fisika partikel adalah bahwa ini secara de facto standar, sehingga kolaborasi internal jadi mudah
    • Keduanya contoh yang cukup berbeda. ROOT adalah framework analisis data yang kuat, tetapi meski kuat, ia tidak berhasil dibuat cukup umum dan mudah dipakai sehingga hampir tidak keluar dari fisika energi tinggi
      Sebaliknya GStreamer adalah platform dengan desain yang indah, dan karena arsitekturnya bagus, ia dapat dengan mudah diabstraksikan dan digunakan ulang untuk skenario yang sama sekali berbeda, yang mungkin tidak pernah dibayangkan oleh pembuat awalnya
    • Yang tidak keren adalah ROOT “dirancang” dan dibuat oleh orang-orang yang sama sekali tidak tahu cara menjalankan proyek perangkat lunak berskala besar
      Jejaknya terlihat di mana-mana. Ia monolit raksasa, jadi begitu mencoba melakukan sesuatu yang sedikit tidak biasa, Anda harus terus berkelahi dengannya. Untung saya tidak perlu sering memakainya, tetapi saya masih cukup sering bersentuhan dengannya
    • “Gelombang gravitasi ditemukan di LIGO dengan GStreamer”? Apa?!

  • Secara pribadi, ROOT mencoba melakukan terlalu banyak hal, desain API-nya buruk, dan yang terpenting, ROOT sebagai library dan ROOT sebagai program tidak dipisahkan
    Ada banyak global state, dan ada asumsi bahwa orang harus memakainya dengan cara program ROOT. ROOT 6 mulai memperbaiki sebagian, tetapi butuh waktu, dan menurut saya pribadi, karena terlalu dalam bergantung pada llvm dan clang, waktu build makin panjang dan proyeknya makin sulit diperbaiki
    Selama lama, dokumentasi format input/output juga buruk dan implementasinya hanya satu
    Sekarang, berkat groot, uproot, freehep, openscientist, dan lainnya, data ROOT bisa dibaca dan ditulis tanpa menarik seluruh ROOT. Menurut saya interoperabilitas data sangat penting. Itu wajib jika ingin punya harapan bahwa 20 atau 30 tahun lagi data unik itu masih bisa dibaca kembali
    https://go-hep.org/x/hep/groot
    Saya pengembang utama go-hep

    • Setahu saya uproot masih belum mengimplementasikan pembacaan TEfficiency dengan benar, dan jujur itu disayangkan

  • Ah, root… membuat saya bersyukur bahwa saya tidak perlu memakai versi sebelum 6 setiap hari

    • Root adalah salah satu alasan saya memutuskan untuk tidak mempelajari fisika partikel
    • Saya masih menunggu versi 7 yang katanya akhirnya akan membuat root bagus, meski harus mematahkan interface. Rasanya saya pertama kali mendengarnya sekitar 2016, dan itu benar-benar terasa seperti janji yang menguap begitu saja

  • Saya teringat malam-malam larut saat men-debug kode yang ditulis para fisikawan hebat tetapi tanpa latar belakang ilmu komputer

    • Sekitar 2013 saya bekerja di situs web pinjaman online, dan mereka mempekerjakan fisikawan partikel untuk membuat model prediksi risiko
      Mereka memakai ROOT untuk pemodelan dan membuat interface dengan Ruby, dan dari sudut pandang rekayasa perangkat lunak itu seperti monster. Namun dari sudut pandang statistik, hasilnya cukup bagus
      Itu jauh sebelum ekosistem Python naik daun, dan paket machine learning di R juga baru mulai muncul
    • Saya bisa membayangkan main() sepanjang 2000 baris

  • Root memang tulang punggung dari pekerjaan yang sangat besar dalam fisika partikel eksperimental, tetapi juga mimpi buruk bagi mahasiswa pascasarjana baru
    Ia sudah praktis tertanam dalam di fisika partikel, jadi sepertinya tidak akan berubah dalam waktu dekat

    • Sekarang ada pyroot dan uproot, sehingga mahasiswa pascasarjana baru punya pilihan yang lebih mudah dipelajari, dan tidak seburuk itu
      Masalahnya biasanya ada pada kode legacy yang harus dipelihara sebagai bagian dari layanan eksperimen

  • Bagian Root yang saya pakai adalah Cling, interpreter C++, dan Xeus untuk notebook Jupyter
    Suatu malam saya membandingkan n-body tercepat dari benchmarkgames di Xeus dan Python 3. Pada instance Binder yang sama, Xeus butuh 15,58 detik, sementara saat menjalankan kode Python tercepat dengan kernel Python3 butuh 5 menit. Output dari kedua eksekusi persis sama
    Bahkan jika overhead eksekusi C++ dinamis pada program ini diasumsikan sekitar 300%, Cling tetap sangat cepat. Saya tidak memakai SIMD atau vektorisasi, hanya kode dari benchmarkgames. Cling terutama saya pakai sebagai pengganti JIT cepat untuk bahasa yang dikompilasi ke C++

    • Saya memakai Cling untuk kompilasi JIT dialek Clojure native saya: https://github.com/jank-lang/jank
      Ini upaya untuk membawa C++ ke dunia Clojure, dan membawa Clojure serta pemrograman interaktif ke dunia C++

  • Kode sumber: https://github.com/root-project

  • “Men-debug skrip CERN ROOT dan program berbasis ROOT di Eclipse IDE”
    Astaga, saya jadi teringat mimpi buruk. Ini jelas menunjukkan bahwa hal-hal luar biasa bisa dibuat bahkan di lingkungan yang mengerikan

    • Saya tidak yakin apakah ini soal Eclipse