00:23:19 Oliver Schulz: Those limitations are pretty much universal to GPU programming, though. 00:23:31 Tamás Gál: indeed 00:23:40 Uwe Hernandez Acosta: +1 00:24:13 Philippe Gras: you asnswered to the questio I want to ask. :). 00:26:08 Oliver Schulz: Pere, just wanted to say that what you did here, and how quickly you did it, is very impressive. 00:28:57 Oliver Schulz: Regarding memory allocations, there's support for profiling that in Julia now. Easily available via`@profview_allocs` in the Julia VS-code plugin. 00:29:34 Jerry Ling: or use https://github.com/pfitzseb/ProfileCanvas.jl (because I don't use VS code) 00:31:24 Oliver Schulz: There is very interesting development regarding system images and first-time-to-plot going on: https://github.com/JuliaLang/julia/pull/44527 This 00:32:00 Oliver Schulz: This is a (long-term) path to packages being able to provide precompiled binary code. 00:35:23 Uwe Hernandez Acosta: There are also some efforts outside of the language core development, e.g. https://github.com/JuliaLang/PackageCompiler.jl 00:39:44 Oliver Schulz: The is work going on regarding self-contained executables, btw., but that'll still take a bit of time. It's on the compiler team roadmap, though. 00:52:45 Mosè Giordano: for example: maximum(x -> abs(x) - box.fDimentions, point) 00:55:48 Uwe Hernandez Acosta: thanks a lot for your talk, really impressive! 00:56:35 Jan Strube: Thank you, Pere. I’d like to second Oliver: Incredible amount of work. Very nice overview of this very demanding example. 00:57:33 Oliver Schulz: Same here - sorry if I sounded too critical about a few things, I am very impressed by Pere's work! 00:57:49 Tamás Gál: 💯 00:59:48 Jerry Ling: is the "apple to apple N^2" comparison in the repo? it should be: https://github.com/JuliaHEP/JetReconstruction.jl 01:00:35 Oliver Schulz: Regarding the impossibility of mutating stack values: This is basically a consequence of having automatic garbage collection in a language that supports multithreading: 01:01:18 Jerry Ling: MVector instead of SVector semantically support mutating (still stack allocated) 01:01:44 Jan Strube: Does this work in a GPU kernel? 01:02:32 Oliver Schulz: Immutable values can be copied arbitrarily between threads and stack-allocated because a copy can't be distinguished from the original. But if you want to mutate, a value becomes an "individual", so there must be only one of it. But separate threads have separate stacks ... 01:03:34 Jerry Ling: not sure, needs to do some study 01:03:35 Pere Mato Vila: I had problems with MVector in the kernel. 01:04:04 Pere Mato Vila: It is using trick to mutate memory positions. 01:04:32 Oliver Schulz: Yes, `MVector` is a bit of a strange beast (in light of what I just wrote) ... 01:05:48 Jan Strube: Wasn’t there a discussion of trying to reduce the cost of small stack allocations at some point? 01:07:45 Jerry Ling: https://github.com/JuliaLang/julia/pull/43573 but it probably doesn't help GPU, this is just a heuristics 01:08:43 Jan Strube: 👍 01:08:48 Oliver Schulz: MVector should be GPU-compatible though (see https://juliagpu.github.io/KernelAbstractions.jl/dev/). 01:16:51 Oliver Schulz: It is possible to modify values of immutable structs that are elements of a vector, e.g. via StructArrays. 01:18:14 Tamás Gál: 👍 01:18:41 Jerry Ling: you can do julia> mutable struct A const a::Int b::Int end not sure if it helps with performance though, question for Mose 01:19:10 Tamás Gál: yes that's a fairly new feature but i have not looked at the performance yet. looks a bit magical to me ;) 01:21:25 Oliver Schulz: I think the whole struct will still need to be stack-allocated, I think the "partial const" just allows for some compiler-optimizations. But I'm not 100% sure. 01:22:18 Jerry Ling: Ref() 01:23:40 Oliver Schulz: `Ref` is essentially a single-element zero-dimensional array, just without array math support. 01:25:01 Oliver Schulz: So semantically, a `Ref` is a mutable scalar value. 01:32:31 Oliver Schulz: Kudos to Jerry and Tamas for UnROOT! 01:33:02 Jan Strube: 💯 01:35:52 Oliver Schulz: Jerry, this is so impressive! 01:58:08 Oliver Schulz: Sorry, I have background noise, have to stay muted now. 02:02:50 Oliver Schulz: We can look at big packages/projects like DifferentialEquations regarding here 02:04:49 Uwe Hernandez Acosta: Agree, the whole SciML ecosystem is a good example for that. 02:06:31 Jerry Ling: I honestly would down to write a generator in Julia to replace Fortran :) but alas, that work doesn't publish so minimal people want to work on it 02:11:00 Oliver Schulz: A Julia wrapper for Geant4, incl. binary G4 artifacts via Pkg, may be much more feasible than a rewrite for now. 02:11:17 Oliver Schulz: Usin CxxWrap 02:11:17 Jerry Ling: yeah but you can't present that at CHEP 02:12:35 Oliver Schulz: What Julia could offer is easy and performant callbacks during G4 tracking, enabling user-friendly importance sampling. 02:12:44 Jerry Ling: btw the real-time analysis: https://github.com/JuliaHEP/LiteHF.jl/files/9973441/slides.pdf 02:13:16 Stefan Kluth: The code size reduction with VecGeom bei O(10) is impressive. Perhaps something like G4 could be done in julia with much reduced code size too. That would also be a profit for maintenance etc. 02:13:38 Pere Mato Vila: sure. I am convinced of it. 02:13:58 Stefan Kluth: But it means just wrapping G4 is useless 02:14:20 Jan Strube: I’m going to have to get to my next meeting. Great discussions, thanks! 02:14:44 Stefan Kluth: Can we somehow say for which kins of C++ code structure we would expect a large reduction of code complexity?