Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > experiment with std::fill

Reply
Thread Tools

experiment with std::fill

 
 
ma740988
Guest
Posts: n/a
 
      01-24-2006

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?

 
Reply With Quote
 
 
 
 
Michiel.Salters@tomtom.com
Guest
Posts: n/a
 
      01-24-2006

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?

 
Reply With Quote
 
 
 
 
mlimber
Guest
Posts: n/a
 
      01-24-2006
(E-Mail Removed) 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

 
Reply With Quote
 
Earl Purple
Guest
Posts: n/a
 
      01-24-2006

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.

 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      01-24-2006
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

 
Reply With Quote
 
Andrew Koenig
Guest
Posts: n/a
 
      01-24-2006
"mlimber" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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.


 
Reply With Quote
 
ma740988
Guest
Posts: n/a
 
      01-24-2006
> > 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!!

 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      01-24-2006
Andrew Koenig wrote:
> "mlimber" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) 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

 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      01-24-2006
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

 
Reply With Quote
 
Earl Purple
Guest
Posts: n/a
 
      01-24-2006

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).

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The Thumb Drive RAID Experiment Silverstrand Front Page News 0 12-30-2005 04:41 AM
The Underclocking Experiment Silverstrand Front Page News 0 12-26-2005 04:41 PM
Inconclusive result of a low-value experiment. Common cache Mozilla & Firefox. Splibbilla Firefox 0 05-30-2005 06:58 AM
Re: Wildly OT:My spampot experiment Robert Moir MCSE 1 05-25-2005 08:46 PM
Re: Wildly OT:My spampot experiment JaR MCSE 1 05-25-2005 07:29 PM



Advertisments