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
Remove service named EnableFloatingPointExceptions #19065
Remove service named EnableFloatingPointExceptions #19065
Conversation
This was discussed and decided at the Core meeting on 30 May 2017. We do not want to use resources maintaining this service for several reasons. First of all, as far as we know no one uses or has used this service and it has been around for more than 10 years. Its unit test is broken. It does not work properly in the new multithreaded environment and would be difficult to fix, the precision control parts of it are obsolete with modern processors, and it does not work properly with some architectures.
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages: DataFormats/MuonDetId @smuzaffar, @civanch, @Dr15Jones, @ianna, @mdhildreth, @cmsbuild, @rekovic, @kpedro88, @mulhearn, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
On 6/1/17 7:55 AM, W. David Dagenhart wrote:
First of all, as far as we
know no one uses or has used this service and it has been
around for more than 10 years.
I used it.
The last time was in 2015, and before that in 2009 (at least from the
times that I have a record of).
What is the alternative?
|
@@ -46,9 +46,6 @@ | |||
firstRun = cms.untracked.uint32(1) | |||
) | |||
|
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.
@wddgit - could you, please, remove the whole file? It's been replaced by SimG4Core/PrintGeomInfo
+1 Note, none of these Geometry test configurations is tested in a release integration. It is fine to merge the PR as is I can clean up the obsolete configuration later. |
At the meeting, I was wondering if anyone would say they had used this when the PR came out. I did remove every reference to the service in repository hoping any actual user would notice. As far as I know there is no alternative to the service other than manually coding this functionality yourself for whatever test you want to do. If people think maintaining this service is worth the effort, then it probably would not be very hard to fix the service so enabling floating point exceptions works when the job is configured to have only one thread and only on LINUX. The precision control part is truly obsolete on modern processors and should be deleted. To make it work properly in multithreaded jobs would take some thought. I do not know if it is just difficult or impossible ... Chris may want to comment on this when he returns from vacation on June 12th. I have not spent time investigating why it fails on AARCH64. It does use glibc functions and has special code enabled for the case #ifdef APPLE so that those functions are defined there ... |
On 6/1/17 8:32 AM, W. David Dagenhart wrote:
At the meeting, I was wondering if anyone would say they had used this
when the PR came out. I did remove every reference to the service in
repository hoping any actual user would notice. As far as I know there
is no alternative to the service other than manually coding this
functionality yourself for whatever test you want to do. If people think
maintaining this service is worth the effort, then it probably would not
be very hard to fix the service so enabling floating point exceptions
works when the job is configured to have only one thread and only on
LINUX.
My use cases were related to debugging of issues that eventually
appeared as NaNs
and also some attempts to cleanup cases that trigger FPEs.
… The precision control part is truly obsolete on modern processors
and should be deleted. To make it work properly in multithreaded jobs
would take some thought. I do not know if it is just difficult or
impossible ... Chris may want to comment on this when he returns from
vacation on June 12th.
I have not spent time investigating why it fails on AARCH64. It does use
glibc functions and has special code enabled for the case #ifdef *APPLE*
so that those functions are defined there ...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#19065 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbpKWD3_r4LnX_BzjDsgh66HzoUAmks5r_tmegaJpZM4NtGbx>.
|
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
This was discussed and decided at the Core meeting
on 30 May 2017. We do not want to use resources maintaining
this service for several reasons. First of all, as far as we
know no one uses or has used this service and it has been
around for more than 10 years. Its unit test is broken. It
does not work properly in the new multithreaded environment
and would be difficult to fix, the precision control
parts of it are obsolete with modern processors, and it
does not work properly with some architectures.