-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various optimization in tracking #18457
Conversation
A new Pull Request was created by @VinInn (Vincenzo Innocente) for master. It involves the following packages: DataFormats/SiPixelCluster @perrotta, @civanch, @Dr15Jones, @ianna, @mdhildreth, @cmsbuild, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
The tests are being triggered in jenkins. |
inline float charge() const { | ||
float qm = 0.0; | ||
inline int charge() const { | ||
int qm = 0; | ||
int isize = thePixelADC.size(); | ||
for (int i=0; i<isize; ++i) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@VinInn - it can be simplified:
for( auto i : thePixelADC )
qm += i;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or
return std::accumulate(thePixelADC.begin(),thePixelADC.end(),int(0));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even better
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Pull request #18457 was updated. @perrotta, @civanch, @Dr15Jones, @ianna, @mdhildreth, @cmsbuild, @slava77, @davidlange6 can you please check and sign again. |
On 4/29/17 6:58 AM, Chris Jones wrote:
We've also seen related cases where |memset| was called on a memory
location that was then used to hold an object and the gcc compiler
optimized away the |memset| because they assumed constructors would
properly initialize the data that needed to be initialized.
Would it similarly outsmart you and remove memset if the data has no
default constructors?
[about vtable pointer, it's a matter of using the right offset instead
of a plain "this"]
…
How about adding comments to the initializer list for the uninitialized
member functions saying that they are intended to not be initialized
there for optization reasons? That way future maintainers of this class
will not forget about those members or unoptimize the code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18457 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcboNzuIHySMgogDJIuwo1-1U1TY8Kks5r00HxgaJpZM4NHVlo>.
|
@cmsbuild please test |
The tests are being triggered in jenkins. |
-1 Tested at: 974524a You can see the results of the tests here: I found follow errors while testing this PR Failed tests: UnitTests
I found errors in the following unit tests: ---> test testAlignmentOfflineValidation had ERRORS |
Comparison job queued. |
not from this PR |
Comparison is ready Comparison Summary:
|
The unit test failure is likely caused by #18330. It added that parameter, and I see the unit test first failing in CMSSW_9_1_X_2017-04-28-1100 where the PR was merged. |
+1
This PR looks safe for 91X which is essentially closed. |
I am only afraid the it may clash with changes in pixel geometry and localreco |
On 5/4/17 4:58 AM, Vincenzo Innocente wrote:
I am only afraid the it may clash with changes in pixel geometry and
localreco
OK
doing nothing (not merging now in 91X) should just advance this PR to
the next development release.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18457 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbiqc5Mm9FocwPqRlPOx4gxhiFT2cks5r2b1ggaJpZM4NHVlo>.
|
ok, let's merge as soon as the first 9_2_X IB appears... |
now that 9_2_X IB is out is this PR candidate for merging or the whole test & validation procedure should start from scratch? |
no? did something get reset?
… On May 5, 2017, at 11:14 AM, Vincenzo Innocente ***@***.***> wrote:
now that 9_2_X IB is out is this PR candidate for merging or the whole test & validation procedure should start from scratch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Not to my knowledge... |
so all is working as expected and nothing needs to start over
… On May 5, 2017, at 11:20 AM, Vincenzo Innocente ***@***.***> wrote:
Not to my knowledge...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
here, jenkins said (the fix is in #18617 ) |
Optimization in various areas, not affecting algorithm behavior.
initialStepPreSplitting made faster w/o affecting physics.
Expect negligible regressions due to numerics...
MTV:
ttbar 0PU with latest IB:
http://innocent.home.cern.ch/innocent/RelVal/pu0_TkSpeed91X/plots_ootb/effandfake1.pdf
ttbar PU50 with pre2
http://innocent.home.cern.ch/innocent/RelVal/pu50_fastTk91_2/plots_ootb/effandfake1.pdf