Skip to content
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

Consider std::array in place of boost::array #2

Closed
mspraggs opened this issue Apr 29, 2015 · 4 comments
Closed

Consider std::array in place of boost::array #2

mspraggs opened this issue Apr 29, 2015 · 4 comments
Assignees

Comments

@mspraggs
Copy link
Contributor

You mention boost arrays in the TODO list, so I thought I'd mention this on the off-chance you hadn't already seen it. C++11 provides an array class template that's pretty much the same as the boost array type.

@paboyle
Copy link
Owner

paboyle commented Apr 30, 2015

Isn't the array template fixed size one dimensional [compile time templated]?

Might work for Nd type indices, but not generally usable; secondly the boost array has really nice
multi-dimensional features and subslicing extents. So it would merge multi1d,2d,3d to Nd neatly
and give subslicing. Just annoyed it hasn't made it into a standard and don't like dependency on boost.

Another thought is that in general I'm getting quite annoyed that vector resize loops
over dimension calling default constructor, giving slow resize. Will benchmark this again,
but for a while I tried (incorrectly) to call reserve and prevent the loop.

If I remember right, it is an implementation issue: the loop is implemented by
i) calling the default constructor once on a temporary if not is_pod.
ii) looping over the whole array using the copy constructor for each element
passing it the temporary.
iii) in the case where the default constructor does nothing, is_pod still says not plain old
data, the empty constructor does nothing to the temporary, but then it loops over the whole
volume copying the temporary that contains junk.

This is avoidable with an "is_pod" enable_if in valarray (and possibly vector haven't checked); but
std::complex is forcing it to still use the slow resize were I to use valarray because it triggers and "is_pod" failure.

So, at some point I may be forced to roll my own "simple" array container that suppresses
initialisation of arrays to junk in resize and initial allocate when is_pod==false.

Question is then whether I make it a multi-dim like boost arrays, or fix to vector like 1d.

@paboyle
Copy link
Owner

paboyle commented Apr 30, 2015

This is the sort of offending loop, that creates a default object and issues a loop
of length the allocation EVEN if the default contstructor is trival and thus filling with random junk.
The implementation should be guarded with enable_if<has_trivial_constructor<value_type> > to
avoid the loop when the constructor is empty.

void
resize(size_type __new_size, value_type __x = value_type())
{
if (__new_size < size())
_M_erase_at_end(this->_M_impl._M_start + __new_size);
else
insert(end(), __new_size - size(), __x);
}

@paboyle
Copy link
Owner

paboyle commented Apr 30, 2015

sorry for brain dumping Matt -- origin of misunderstanding -- my comments in the
TODO were intended to mean Boost's MultiArray:

http://www.boost.org/doc/libs/1_58_0/libs/multi_array/doc/

which is a very interesting interface.

@mspraggs
Copy link
Contributor Author

Ah sure, I see what you mean. Yeah std::array won't help for multi-dimensional arrays.

@paboyle paboyle self-assigned this Apr 30, 2015
azusayamaguchi pushed a commit that referenced this issue Nov 19, 2015
goracle added a commit to goracle/Grid that referenced this issue May 28, 2019
0) We remove lib directory
1) cartesian comm now inherits from shared memory
2) mpit may be wrong, and is unsupported in this grid version
3) similar to paboyle#2, mpi3 is also unsupported
4) the purpose of this commit is to catch up with a year+ of commits
from the main develop branch, but still compile with GRID_COMMS_MPI (not
MPI3).  We want multiple ppn due to contraction tunings (which we have
so far been unable to replicate for ppn = 1).  Additionally, the mpi3
shared mem options for multiple ppn has only map anon, which will not
allow for memory safety when using a shared mem comms buffer (from my
recollection).  We hope this commit might be useful to other projects
which are forced to use multiple ppn (esp. for comms on the KNL.  We
should recall that the KNL comms may eventually be solved using
multi-endpoint, so there may be a limited window for the usefulness of this snapshot.)

More testing is needed.  Caveat Emptor.
paboyle pushed a commit that referenced this issue May 6, 2020
…-norm2

Fused innerProduct + norm2 on first argument operation
fjosw pushed a commit to fjosw/Grid that referenced this issue Feb 16, 2022
paboyle pushed a commit that referenced this issue May 10, 2022
edbennett pushed a commit to edbennett/Grid_epcc that referenced this issue Aug 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants