26 Apr
2019
26 Apr
'19
1:56 p.m.
Hi,
Am I able to safely comment out all those exception handling codes provided
they're provided for the defensive purposes? I ask because I am trying to
insert offloading directives into the NEST code base wherever I can.
Thanks,
Itaru.
29 Apr
29 Apr
11:49 p.m.
Dear Itaru,
Could you be more specific about where you would like to remove exception handling code
and why? In general, I would be rather reluctant to remove exception handling code.
Best,
Hans Ekkehard
On 26 Apr 2019, at 13:56, Itaru Kitayama
<itaru.kitayama(a)gmail.com> wrote:
Hi,
Am I able to safely comment out all those exception handling codes provided
they're provided for the defensive purposes? I ask because I am trying to
insert offloading directives into the NEST code base wherever I can.
Thanks,
Itaru.
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home http://arken.nmbu.no/~plesser
1 May
1 May
7:33 a.m.
Hans,
Not limited to this part of code, though for example, we have in
nestkernle/simulation_manager.cpp
[...]
#pragma omp target teams distribute parallel for
for(int i=0;i<len;i++)
{
// We update in a parallel region. Therefore, we need to catch
// exceptions here and then handle them after the parallel region.
//try
//{
if ( not( *node )->is_frozen() )
{
( *node )->update( clock_, from_step_, to_step_ );
}
//}
/*catch ( std::exception& e )
{
// so throw the exception after parallel region
exceptions_raised.at( tid ) = lockPTR< WrappedThreadException >(
new WrappedThreadException( e ) );
}*/
++node;
}
OpenMP offload doesn't support exception handling on devices, so any loop
that can be offloadable, but
contains exception handling, can we safely comment out?
Itaru.
On Tue, Apr 30, 2019 at 6:49 AM Hans Ekkehard Plesser <
hans.ekkehard.plesser(a)nmbu.no> wrote:
Dear Itaru,
Could you be more specific about where you would like to remove exception
handling code and why? In general, I would be rather reluctant to remove
exception handling code.
Best,
Hans Ekkehard
On 26 Apr 2019, at 13:56, Itaru Kitayama
<itaru.kitayama(a)gmail.com>
wrote:
Hi,
Am I able to safely comment out all those exception handling codes
provided
they're provided for the defensive purposes?
I ask because I am trying to
insert offloading directives into the NEST code base wherever I can.
Thanks,
Itaru.
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home http://arken.nmbu.no/~plesser
9:53 p.m.
Dear Itaru,
Short answer: For experimental purposes, you can remove those try-catch blocks and NEST
will continue to work.
Longer answer:
Handling exceptions in multithreaded code is difficult in C++, since C++ does not support
exception handling across threads, at least not when using OpenMP threads. To handle
potential exceptions safely, we therefore handle exceptions inside each thread-parallel
context, store them and then re-throw them as soon as we reach a single-threaded context.
This allows us to provide proper error messages. If you remove the error-handling code and
an exception is thrown in a parallel context, NEST will crash, because the exception is
never caught.
Typical situations where such exceptions could occur is during parallel connection if
trying to make invalid connections, or when encountering numerical instabilities, e.g. due
to the exponential term in aeif neurons.
To ensure proper error handling in NEST, we need to keep the per-thread error handling in
the master branch, but for experimental purposes it can be removed without changing the
way NEST works.
Best,
Hans Ekkehard
On 1 May 2019, at 07:33, Itaru Kitayama
<itaru.kitayama(a)gmail.com> wrote:
Hans,
Not limited to this part of code, though for example, we have in
nestkernle/simulation_manager.cpp
[...]
#pragma omp target teams distribute parallel for
for(int i=0;i<len;i++)
{
// We update in a parallel region. Therefore, we need to catch
// exceptions here and then handle them after the parallel region.
//try
//{
if ( not( *node )->is_frozen() )
{
( *node )->update( clock_, from_step_, to_step_ );
}
//}
/*catch ( std::exception& e )
{
// so throw the exception after parallel region
exceptions_raised.at( tid ) = lockPTR< WrappedThreadException >(
new WrappedThreadException( e ) );
}*/
++node;
}
OpenMP offload doesn't support exception handling on devices, so any loop that can be
offloadable, but
contains exception handling, can we safely comment out?
Itaru.
On Tue, Apr 30, 2019 at 6:49 AM Hans Ekkehard Plesser
<hans.ekkehard.plesser(a)nmbu.no> wrote:
Dear Itaru,
Could you be more specific about where you would like to remove exception handling code
and why? In general, I would be rather reluctant to remove exception handling code.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home http://arken.nmbu.no/~plesser
On 26 Apr 2019, at 13:56, Itaru Kitayama
<itaru.kitayama(a)gmail.com> wrote:
Hi,
Am I able to safely comment out all those exception handling codes provided
they're provided for the defensive purposes? I ask because I am trying to
insert offloading directives into the NEST code base wherever I can.
Thanks,
Itaru.
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home http://arken.nmbu.no/~plesser
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
2 May
2 May
7:45 a.m.
Hans,
Thanks for your detailed answer. I think I never encountered an event where
an exception was thrown in real life,
so as you suggest I'll go ahead and remove as needed.
Thanks,
Itaru.
On Thu, May 2, 2019 at 4:53 AM Hans Ekkehard Plesser <
hans.ekkehard.plesser(a)nmbu.no> wrote:
Dear Itaru,
Short answer: For experimental purposes, you can remove those try-catch
blocks and NEST will continue to work.
Longer answer:
Handling exceptions in multithreaded code is difficult in C++, since C++
does not support exception handling across threads, at least not when using
OpenMP threads. To handle potential exceptions safely, we therefore handle
exceptions inside each thread-parallel context, store them and then
re-throw them as soon as we reach a single-threaded context. This allows us
to provide proper error messages. If you remove the error-handling code and
an exception is thrown in a parallel context, NEST will crash, because the
exception is never caught.
Typical situations where such exceptions could occur is during parallel
connection if trying to make invalid connections, or when encountering
numerical instabilities, e.g. due to the exponential term in aeif neurons.
To ensure proper error handling in NEST, we need to keep the per-thread
error handling in the master branch, but for experimental purposes it can
be removed without changing the way NEST works.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home http://arken.nmbu.no/~plesser
On 1 May 2019, at 07:33, Itaru Kitayama
<itaru.kitayama(a)gmail.com>
wrote:
Hans,
Not limited to this part of code, though for example, we have in
nestkernle/simulation_manager.cpp
[...]
#pragma omp target teams distribute parallel for
for(int i=0;i<len;i++)
{
// We update in a parallel region. Therefore, we need to catch
// exceptions here and then handle them after the parallel
region.
//try
//{
if ( not( *node )->is_frozen() )
{
( *node )->update( clock_, from_step_, to_step_ );
}
//}
/*catch ( std::exception& e )
{
// so throw the exception after parallel region
exceptions_raised.at( tid ) = lockPTR< WrappedThreadException
(
new WrappedThreadException( e ) );
}*/
++node;
}
OpenMP offload doesn't support exception handling on devices, so any
loop that
can be offloadable, but
contains exception handling, can we safely
comment out?
Itaru.
On Tue, Apr 30, 2019 at 6:49 AM Hans Ekkehard Plesser <
hans.ekkehard.plesser(a)nmbu.no> wrote:
Dear Itaru,
Could you be more specific about where you would like to remove
exception handling
code and why? In general, I would be rather reluctant to
remove exception handling code.
Best,
Hans Ekkehard
> On 26 Apr 2019, at 13:56, Itaru Kitayama <itaru.kitayama(a)gmail.com>
wrote:
>
> Hi,
> Am I able to safely comment out all those exception handling codes
provided
> they're provided for the defensive
purposes? I ask because I am trying
to
insert
offloading directives into the NEST code base wherever I can.
Thanks,
Itaru.
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home http://arken.nmbu.no/~plesser
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
1819
days inactive
1825
days old
4 comments
2 participants
participants (2)
-
Hans Ekkehard Plesser -
Itaru Kitayama