Closed felixhekhorn closed 11 months ago
Interestingly enough python does not to seem affected:
$ (timedatectl | head -n 1) && (pineko compare data/appl_subgrids/CMS_1JET_8TEV-CMS_1JET_8TEV.pineappl.lz4 data/appl_subfktables/200-CMS_1JET_8TEV-CMS_1JET_8TEV.pineappl.lz4 2 0 NNPDF40_nnlo_as_01180 > /dev/null) && (timedatectl | head -n 1)
Local time: Wed 2022-03-30 17:52:28 CEST
Local time: Wed 2022-03-30 17:53:43 CEST
this sounds like truly the CLI (and not the PineAPPL library behind)
Remember that Rust binaries are mostly statically compiled, so the version of the library might differ between Python interface and the CLI. If you're sure it's the same (because you recompiled both), than of course this does not apply.
Compilation warnings are all related to --features=fastnlo
, since the fastNLO library bindings are wider than what it's strictly needed (that's not bad, since it's a first iteration and we might need it in the future).
If you don't need to convert fastNLO grids, you can avoid that feature, and you shouldn't get as many warnings.
I agree that truly seems like a performance bug, could you check that you have the same problem also for the grid at process scale?
The fastNLO warnings I can't get rid off, they originate from the fastNLO toolkit headers, but it's annoying I agree.
Remember that Rust binaries are mostly statically compiled, so the version of the library might differ between Python interface and the CLI. If you're sure it's the same (because you recompiled both), than of course this does not apply.
This is a good point, please check that. I might've introduced a performance regression at some point.
Quick fact list: after the evolution
pineappl v0.5.1-7-ge043241-dirty
on dom
-> factor 76The last two factors are roughly consistent, so in other words the size of the grid is driven by the change of the flavour basis into the evolution basis. The difference in time is much more, so there could be something wrong with the PDF cache.
Is there any trivial optimization that is missing for those grids? Or is there anything we can do to optimize them?
The FK table optimization is missing, I believe (Nf4Sym
).
After this optimization step the file size drops from 328M to 150M (factor 2.2), and the execution time from 6m17.859s to 2m19.145s (factor 2.7) on my local machine.
Much better, but still much slower than the original one. It's true we're dealing with an intrinsic property of the object itself, since evolution is entangling everything, by an unpredictable amount.
I wonder if there is anything more we can do for further optimizing it... (I don't see it manifest)
The FK table optimization is missing, I believe (
Nf4Sym
).
just to confirm this is true
After this optimization step the file size drops from 328M to 150M (factor 2.2), and the execution time from 6m17.859s to 2m19.145s (factor 2.7) on my local machine.
okay, I take it you can reproduce to some extend the problem locally
still, I don't understand why python does not seem to be affected - is there some easy debugging I can do?
still, I don't understand why python does not seem to be affected - is there some easy debugging I can do?
What do you run exactly and which version of PineAPPL do you use?
as said, I did a pull so:
$ pineappl --version
pineappl v0.5.2-3-g3789a89
I agree that truly seems like a performance bug, could you check that you have the same problem also for the grid at process scale?
no at process level I get:
$ (timedatectl | head -n 1) && (pineappl convolute data/appl_subgrids/CMS_1JET_8TEV-CMS_1JET_8TEV.pineappl.lz4 NNPDF40_nnlo_as_01180 > /dev/null ) && (timedatectl | head -n 1)
Local time: Mon 2022-04-04 11:35:58 CEST
Local time: Mon 2022-04-04 11:36:05 CEST
$ du -h data/appl_subgrids/CMS_1JET_8TEV-CMS_1JET_8TEV.pineappl.lz4
12M data/appl_subgrids/CMS_1JET_8TEV-CMS_1JET_8TEV.pineappl.lz4
as said, I did a pull so:
$ pineappl --version pineappl v0.5.2-3-g3789a89
But that's the CLI version, if you're using Python I need PineAPPL's Python interface version. Also what do you run exactly?
okay, so just did
$ maturin develop --release
[...]
Compiling pineappl v0.5.2 (/media/FK/pineappl/pineappl)
Compiling numpy v0.14.1
Compiling pineappl_py v0.5.2 (/media/FK/pineappl/pineappl_py)
Finished release [optimized] target(s) in 19.79s
and it seemed indeed to have done the job:
$ ls env/lib/python3.10/site-packages/pineappl -l
total 10008
-rw-r--r-- 1 felix nnpdf 516 Apr 4 11:40 bin.py
-rw-r--r-- 1 felix nnpdf 1688 Apr 4 11:40 fk_table.py
-rw-r--r-- 1 felix nnpdf 9715 Apr 4 11:40 grid.py
-rw-r--r-- 1 felix nnpdf 762 Apr 4 11:40 import_only_subgrid.py
-rw-r--r-- 1 felix nnpdf 70 Apr 4 11:40 __init__.py
-rw-r--r-- 1 felix nnpdf 379 Apr 4 11:40 lumi.py
-rwxr-xr-x 1 felix nnpdf 10200296 Apr 4 11:40 pineappl.cpython-310-x86_64-linux-gnu.so
drwxr-sr-x 2 felix nnpdf 4096 Apr 4 11:40 __pycache__
-rw-r--r-- 1 felix nnpdf 254 Apr 4 11:40 subgrid.py
-rw-r--r-- 1 felix nnpdf 430 Apr 4 11:40 utils.py
further more
$ pip list | grep pineappl
pineappl 0.5.2
and then rerunning the command from https://github.com/N3PDF/pineappl/issues/134#issuecomment-1083320997 (so two! convolutions) I still get the roughly one minute ...
@felixhekhorn it seems that scale variations make the difference - I don't know why yet, but it's a start. Can you please try to convolute with the CLI with -s 1
to disable them?
@felixhekhorn it seems that scale variations make the difference - I don't know why yet, but it's a start. Can you please try to convolute with the CLI with
-s 1
to disable them?
yes, this seems to be confirmed:
$ (timedatectl | head -n 1) && (pineappl convolute data/appl_subfktables/200-CMS_1JET_8TEV-CMS_1JET_8TEV.pineappl.lz4 NNPDF40_nnlo_as_01180 -s 1 > /dev/null ) && (timedatectl | head -n 1)
Local time: Mon 2022-04-04 11:59:16 CEST
Local time: Mon 2022-04-04 12:00:39 CEST
(still using the unoptimized grid ...)
lhapdf
fault, since pineappl
is attempting to evaluate the PDF at Q0/2
@felixhekhorn it seems that scale variations make the difference - I don't know why yet, but it's a start. Can you please try to convolute with the CLI with
-s 1
to disable them?
LHCB_DY_13TEV_DIELECTRON
: I get 3s with no scale variation and 19s with full
- doing a local test on
LHCB_DY_13TEV_DIELECTRON
: I get 3s with no scale variation and 19s with full
to be more quantitative:
-s 1
2s-s 3
8s-s 7
19s-s 9
24snow, to be fair this is almost expected, since the number of convolutions scales linearly with the number of scales - so I wonder whether we look at a non-issue here ... and instead just a non-correct usage of the CLI, then I wonder whether we should somehow flag the FK tables to deny scale variations ...
@felixhekhorn I'm still a bit concerned about the scaling, but I agree this isn't much of an Issue. Not printing scale variation when you can't reliably predict them is probably more important; I'd opened https://github.com/N3PDF/pineappl/issues/46 for that but I wonder if what I wrote is true. When we have FK tables we can certainly disable scale-variations.
I wonder whether we should somehow flag the FK tables to deny scale variations ...I wonder whether we should somehow flag the FK tables to deny scale variations ...
I think FK tables match exactly #46
This is no longer a problem as pineappl convolute
doesn't calculate scale uncertainties anymore.
On dom I did
git pull
$ cargo install --features=fastnlo --path pineappl_cli --root /media/FK/env
as written in the README. This generates a bunch of warnings (-Wunused-parameter
,-Wmaybe-uninitialized
) which maybe you want to avoid and eventuallycheck the size as suggested:
so no, it is bigger then 2M
double check the things is actually replaced:
check the grid size:
now measuring convolute I get: