[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Switch to std::atomic?
From: |
Rik |
Subject: |
Switch to std::atomic? |
Date: |
Fri, 13 Sep 2019 14:29:05 -0700 |
jwe,
I have been looking at the performance of Octave and one of the slow points
has been the atomic operations. This led me to look at the actual code in
oct-refcount.h quoted below.
#if (defined (OCTAVE_ENABLE_ATOMIC_REFCOUNT) \
&& (defined (__GNUC__) || defined (_MSC_VER)))
# if defined (__GNUC__)
# define OCTAVE_ATOMIC_INCREMENT(x) __sync_add_and_fetch (x, 1)
# define OCTAVE_ATOMIC_DECREMENT(x) __sync_add_and_fetch (x, -1)
# define OCTAVE_ATOMIC_POST_INCREMENT(x) __sync_fetch_and_add (x, 1)
# define OCTAVE_ATOMIC_POST_DECREMENT(x) __sync_fetch_and_add (x, -1)
# elif defined (_MSC_VER)
# include <intrin.h>
# define OCTAVE_ATOMIC_INCREMENT(x) \
_InterlockedIncrement (static_cast<long *> (x))
# define OCTAVE_ATOMIC_DECREMENT(x) \
_InterlockedDecrement (static_cast<long *> (x))
# define OCTAVE_ATOMIC_POST_INCREMENT(x) \
_InterlockedExchangeAdd (static_cast<long *> (x))
# define OCTAVE_ATOMIC_POST_DECREMENT(x) \
_InterlockedExchangeAdd (static_cast<long *> (x))
# endif
So, only with gcc (or something close to it like clang) or on Windows do we
have true atomic instructions. If these conditions aren't met then
ordinary, non-atomic operations are substituted which won't work if
plotting or the GUI are used.
Would it make sense to switch to using std::atomic<octave_idx_type>? In
that case, Octave would be portable to any machine with a valid C++ runtime
library, and we certainly require that. The std::atomic class overloads
the (pre-, post-)(increment, decrement) operators so one could write more
readable code with count++ rather than OCTAVE_ATOMIC_POST_INCREMENT(count).
Just an idea, but I don't want to go ahead if there is some larger reason
we shouldn't do this.
--Rik
- Switch to std::atomic?,
Rik <=
- Re: Switch to std::atomic?, John W. Eaton, 2019/09/25
- Re: Switch to std::atomic?, John W. Eaton, 2019/09/25
- Is fork() broken in octave 5.1 ?, Kay Nick, 2019/09/26
- Re: Is fork() broken in octave 5.1 ?, Mike Miller, 2019/09/26
- Re: Is fork() broken in octave 5.1 ?, Kay Nick, 2019/09/26
- Re: Is fork() broken in octave 5.1 ?, Mike Miller, 2019/09/26
- Re: Is fork() broken in octave 5.1 ?, John W. Eaton, 2019/09/26
- Re: Is fork() broken in octave 5.1 ?, Dr. K. nick, 2019/09/27
- Re: Switch to std::atomic?, John W. Eaton, 2019/09/26
- Re: Switch to std::atomic?, Dmitri A. Sergatskov, 2019/09/26