Repository navigation
Remove neppV and fptype_sv from API and decouple neppV from neppM (epochX) - #300
Merged
Merged
Conversation
…as5X in epochX/eemumu Ported everything as-is (in one single commit), including stuff that eventually needs to be cleaned up (e.g. it will probably be better to only support some given choices of neppM and neppV and fail otherwise) This essentially completes (except for backports) issue madgraph5#176 about removing neppV from the public API... Performance (see next commit) is almost the same. Probably 512y eemumu loses 1% because I have removed a few vectorizations on allMEs. Maybe I can get back a tiny bit even there.
valassi
marked this pull request as draft
November 30, 2021 17:47
Tiny performance drop probably because of removed vectorization in allMEs initialization?
…change, will revert" This reverts commit a2f3388.
…y tiny change, will revert (note: this time, unlike the "=0" changes, I see small changes in the symbols used, but not sure they are good)
…s" - very tiny change, will revert" This reverts commit a26e057.
…nual - eemumu auto is now identical
…- few minor changes, mainly for inline (but I do not care about inline as it is not really relevant for ggttgg...)
… the same performance
…and thus allow parallel "make -j"
…thus allow parallel "make -j"
…ly the same performance (next commit)
…argets to allow parallel "make -j" builds
…ds - regenerate 3 procs, sync eemumu manu
…ipt and add -makej option to enable make -j
…eThroughput script
…ithin fluctuations up and down
… within fluctuations up and down
valassi
marked this pull request as ready for review
December 2, 2021 11:38
valassi
changed the title
Member
Author
Member
Author
|
I have now closed issue #176 as this PR has completed it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a followup (in epochX) to PR #208 (in epoch1) about issue #176
Essentially it is about removing neppV and fptype_sv from the public APIs that we will offer users
The details of how I arrived to some pieces of code is in klas5 PR #208. In this new PR from klas5X, I have just immediately committed to epochX the results of old developpments in epoch1. I think that I will merge in any case also those epoch1 developments to keep the history.
Note also that this epochX status needs to be cleaned up. I am supporting many options (unlaigned data, neppM smaller than neppV etc) that we should not support in production code. We should just keep the fastest, which is aligned data, with neppM=neppV. I have already added some sanity checks, but I should cross check those, and keep only the strictly relevant ones (also because some sanity checks are expensive, eg on alignment of every buffer)