By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,652 Members | 1,182 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,652 IT Pros & Developers. It's quick & easy.

bus error on vector resize

P: n/a
Hi,

I'm having a problem resizing a (very big) nested vector. It's not the
most streamlined piece of code ever but I need this array to avoid
having to recalculate the same quantity millions of times!

The (relevant) snippets of code are below : since it's relevant though
L=28,T=96 (so TasteProps weighs in at a hefty
8*96*28*28*28*96=1,618,477,056 doubles [which I think requires 12G of
memory - I'm running on an 8GB machine : the problem??])

Can anyone suggest a more elegant solution? If inline calculation is
ruled out I'll have to resort to a lookup file rather than lookup in
memory - something I'd rather not have to deal with as I could quickly
fill up our departments home drive space!).

namespace PropLTable
{
vector< vector< vector< vector< double > > > > ScalarDisc(L),
VectorDisc(L), AxialDisc(L),
k2_lup(L);
vector<vector<vector<vector<vector<vector<double> > > > > >
TasteProps(8);
}

void resizenamespace()
{
using namespace PropLTable;

for (int i=0;i<L;i++)
{
ScalarDisc[i].resize(L);
VectorDisc[i].resize(L);
AxialDisc[i].resize(L);
k2_lup[i].resize(L);
for (int j = 0;j<L;i++)
{
ScalarDisc[i][j].resize(L);
VectorDisc[i][j].resize(L);
AxialDisc[i][j].resize(L);
k2_lup[i][j].resize(L);
for (int k = 0;k<L;k++)
{
ScalarDisc[i][j][k].resize(T);
VectorDisc[i][j][k].resize(T);
AxialDisc[i][j][k].resize(T);
k2_lup[i][j][k].resize(T);
}
}
}

for (int i = 0;i<8;i++)
{
TasteProps[i].resize(T);
for (int j = 0;j<T;j++)
{
TasteProps[i][j].resize(L);
for (int k = 0;k<L;k++)
{
TasteProps[i][j][k].resize(L);
for (int l = 0;l<L;l++)
{
TasteProps[i][j][k][l].resize(L);
for (int m = 0;m<L;m++)
{
TasteProps[i][j][k][l][m].resize(T);
}
}
}
}
}

}

May 7 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
<mr**********************@googlemail.com> wrote in message
news:11********************@i39g2000cwa.googlegrou ps.com...
: I'm having a problem resizing a (very big) nested vector. It's not the
: most streamlined piece of code ever but I need this array to avoid
: having to recalculate the same quantity millions of times!
:
: The (relevant) snippets of code are below : since it's relevant though
: L=28,T=96 (so TasteProps weighs in at a hefty
: 8*96*28*28*28*96=1,618,477,056 doubles [which I think requires 12G of
: memory - I'm running on an 8GB machine : the problem??])
Well yes, this might well be !

: Can anyone suggest a more elegant solution?

Do you really need to keep a cache of 1.6 billion results ??
What is this application where pre-computing all this data
at startup helps performance?
[ if it is not precomputed at startup, then it is stored in
a file, and you'd better read that file in chunks than
stored in all in a hierarchy of vectors ]

There usually are smarter caching schemes, especially if some
computations are performed repeatedly.
Like some kind of mapping of input->output pairs for the most
recent inputs received.

Then if you really were to need such a big cache, it will be
more efficient to allocate a single contiguous vector of data,
and do the index calculations yourself within that big table.

hth -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
May 7 '06 #2

P: n/a
Hi,

It's for a theoretical physics calculation - the TasteProps array
stores some propagators which are stored for different momenta on the
lattice (this leads to the T*L*L*L*T factor). In the work I do there
are mass splittings into 16 different 'tastes' which can be categorised
into 8 different groups, hence the 8.

I could remove a factor of 8 by calculating the sums earlier, and
reusing the TLLLT array over and over again. In fact, come to think of
it I can completely remove each of the 8 tastes into separate programs
which output them into files, then the overall total can just be read
back into the core - having them separately allows me to analyse their
relative contributions anyway.

Thanks for your help anyway - I'll print that bit out for future
reference as I'm sure I'll run into very similar problems very soon!
Thanks,
Chris

May 7 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.