experiment with std::fill

[ma740988]

I've allocated 4K memory and I'd like to use std::fill to fill each 1K
with a different value. Note: I could easily use a vector/deque but
I'm interested in a C style array.

int main()
{
int const max = 0x1000;
int *ptr_mem = new int [ max ];
int initial(1);
for ( int idx(0); idx < 4; ++idx )
{
std::fill ( ptr_mem, ptr_mem + 0x400, initial );
ptr_mem += 0x400; // move to the next 1K
initial += 1; // change the value
}

// call a display function to send output to a text - for assessment

delete [] ptr_mem;
ptr_mem = 0; // just in case.
}

I'm coming up short. I'm sure part of the problem is my limited
understanding of std::fill (back to the text in a minute on this). In
the meantime, how would I achieve this?

[Michiel.Salters]

ma740988 wrote:

I've allocated 4K memory and I'd like to use std::fill to fill each 1K
with a different value. Note: I could easily use a vector/deque but
I'm interested in a C style array.

int main()
{
int const max = 0x1000;
int *ptr_mem = new int [ max ];
int initial(1);
for ( int idx(0); idx < 4; ++idx )
{
std::fill ( ptr_mem, ptr_mem + 0x400, initial );
ptr_mem += 0x400; // move to the next 1K
initial += 1; // change the value
}

// call a display function to send output to a text - for assessment

delete [] ptr_mem;
ptr_mem = 0; // just in case.
}

Looks OK. What's the problem?

[mlimber]

[e-mail] wrote:

ma740988 wrote:

I've allocated 4K memory and I'd like to use std::fill to fill each 1K
with a different value. Note: I could easily use a vector/deque but
I'm interested in a C style array.

int main()
{
int const max = 0x1000;
int *ptr_mem = new int [ max ];
int initial(1);
for ( int idx(0); idx < 4; ++idx )
{
std::fill ( ptr_mem, ptr_mem + 0x400, initial );
ptr_mem += 0x400; // move to the next 1K
initial += 1; // change the value
}

// call a display function to send output to a text - for assessment

delete [] ptr_mem;
ptr_mem = 0; // just in case.
}

Looks OK. What's the problem?

Except that ptr_mem was changed from its original location. Unless it
is changed back before the delete[], there will be problems! Dare I ask
why the OP can't use a vector (or perhaps boost::array or a statically
allocated array)?

Cheers! --M

[Earl Purple]

mlimber wrote:

Dare I ask
why the OP can't use a vector (or perhaps boost::array or a statically
allocated array)?

I don't know why he can't use vector. boost::array isn't actually
standard and I don't know if it's ever going to be. Is it more portable
than vector across libraries? That's the big downside of vector.

He will be exceeding his 4K of memory unless sizeof(int) is 1 on his
system.

[mlimber]

Earl Purple wrote:
[snip]

boost::array isn't actually
standard and I don't know if it's ever going to be. Is it more portable
than vector across libraries? That's the big downside of vector.
Well, boost::array is at least part of TR1, and it provides an iterator
interface that would reduce pointer errors like the one you caught
below.
He will be exceeding his 4K of memory unless sizeof(int) is 1 on his
system.

Good catch.

Cheers! --M

[Andrew Koenig]

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

He will be exceeding his 4K of memory unless sizeof(int) is 1 on his
system.

Good catch.

How so? The OP didn't say 4K of what. The array has 4K elements and all
those elements get filled.

[ma740988]

> > Looks OK. What's the problem?

Except that ptr_mem was changed from its original location. Unless it
is changed back before the delete[], there will be problems! Yikes!! Forgot to change it back!! So much for these source code
analysis tools. What a joke!!
Dare I ask
why the OP can't use a vector (or perhaps boost::array or a statically
allocated array)?

Limitation of the vendor hardware. If I want to move data and move it
fast, I take advantage of the vendor hardware. ie. their DMA engine.
Having said that it's a call to a vendor API, which is a C API.
I've experimented with containers usage and while transfers from source
to destination appeared OK with the vendor API. The contents at the
destination was all 'garbage'.
One thing, I'm tempted to do is compare the performance of
memcopy/std::copy versus the vendor API. Something tells me the vendor
API is memcopy under the hood. Even so the vendor API has a dma
engine (hardware spewing 128 byte bursts) under the hood so it should
blast memcopy/std::copy out the window.
We'll see!!

[mlimber]

Andrew Koenig wrote:

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

He will be exceeding his 4K of memory unless sizeof(int) is 1 on his
system.

Good catch.

How so? The OP didn't say 4K of what. The array has 4K elements and all
those elements get filled.

Uhh, good catch. I didn't do the math; I just assumed Earl Purple had
done it correctly. Mea culpa.

Cheers! --M

[mlimber]

ma740988 wrote:

Dare I ask
why the OP can't use a vector (or perhaps boost::array or a statically
allocated array)?
Limitation of the vendor hardware. If I want to move data and move it
fast, I take advantage of the vendor hardware. ie. their DMA engine.
Having said that it's a call to a vendor API, which is a C API.
I've experimented with containers usage and while transfers from source
to destination appeared OK with the vendor API. The contents at the
destination was all 'garbage'.

std::vector's memory is guaranteed to be contiguous, so something like
this should work:

vector<int> data( 4096 );
GetDataFromDMA( &data[0], data.size() );

If it doesn't, it's not likely std::vector's fault. That code should
behave the same as if you allocated the memory yourself:

const unsigned int size = 4096;
int *const data = new int[ size ];
GetDataFromDMA( &data[0], size );

except that the usual advantages (and usually minor disadvantages) of
std::vector apply.
One thing, I'm tempted to do is compare the performance of
memcopy/std::copy versus the vendor API. Something tells me the vendor
API is memcopy under the hood. Even so the vendor API has a dma
engine (hardware spewing 128 byte bursts) under the hood so it should
blast memcopy/std::copy out the window.

<OT>
The performance (and perhaps even method) likely depends on where
you're DMAing from and to.
</OT>

Cheers! --M

[Earl Purple]

ma740988 wrote:

Limitation of the vendor hardware. If I want to move data and move it
fast, I take advantage of the vendor hardware. ie. their DMA engine.
Having said that it's a call to a vendor API, which is a C API.
I've experimented with containers usage and while transfers from source
to destination appeared OK with the vendor API. The contents at the
destination was all 'garbage'.
One thing, I'm tempted to do is compare the performance of
memcopy/std::copy versus the vendor API. Something tells me the vendor
API is memcopy under the hood. Even so the vendor API has a dma
engine (hardware spewing 128 byte bursts) under the hood so it should
blast memcopy/std::copy out the window.
We'll see!!

If you want to be able to take advantage of things like memcpy then you
might use

std::basic_string<int, myIntTraits >

where you write myIntTraits in the style of char_traits to optimise
copies.

The problem is that if your API wants an int* buffer then you cannot
get one from &intstr[0] like you can with &vec[0]. You can get a
continguous const int* buffer by calling c_str() or data().

(And when you said 4K of memory I assumed you meant 4K bytes. The code
was correct though in that you allocated 4K ints, just you deleted the
wrong pointer as was pointed out).

[ma740988]

vector<int> data( 4096 );
GetDataFromDMA( &data[0], data.size() );

If it doesn't, it's not likely std::vector's fault. That code should
behave the same as if you allocated the memory yourself:

Uhmmn, I'd have to check again but if memory serves here's a test
'case' I ran that failed
int *ptr_source = new int[ 4096 ];
std::fill ( ptr_source, ptr_source + 4096, 0xA5 );
int *ptr_dest = new int [ 4096 ];

<non standard >
gtDmaTransfer( /*some DMA engine*/, ptr_source, ptr_dest, 0x4096);
</non standard >

Works!!
Now

vector<int> int_vec1(4096);
// same story - std::fill
vector<int> int_vec2(4096);
<non standard >
gtDmaTransfer( /*some DMA engine*/, &int_vec1[0], &int_vec2[0],
0x4096);
</non standard >

Didn't.

A little surprising to me but I thought the fact that the vector comes
with copy constructor etc, might have hosed things up. Ironically, (in
my mind - I thought) if I'm transferring raw bits, the API shouldn't
care about the fact that it's a 'container'.. Oh well, I just need to
play with it some more I guess.

[Pete Becker]

ma740988 wrote:

Uhmmn, I'd have to check again but if memory serves here's a test
'case' I ran that failed
int *ptr_source = new int[ 4096 ];
std::fill ( ptr_source, ptr_source + 4096, 0xA5 );
int *ptr_dest = new int [ 4096 ];

<non standard >
gtDmaTransfer( /*some DMA engine*/, ptr_source, ptr_dest, 0x4096);
</non standard >

Works!!

Well, maybe, but it's impossible to say, since this is a code fragment,
not a test case. It looks suspicious, though. The code allocates space
for 4096 (0x1000) integers, then copies some unexplained number of bytes
that's apparently related to 16,534 (0x4096).

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[ma740988]

If you want to be able to take advantage of things like memcpy then you
might use

std::basic_string<int, myIntTraits >

where you write myIntTraits in the style of char_traits to optimise
copies.

"myIntraits in the style of char_traits to optimise copies". I think
I'm following you here but could you elaborate on this a little?