experiment with std::fill

Discussion in 'C++' started by ma740988, Jan 24, 2006.

  1. ma740988

    ma740988 Guest

    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?
     
    ma740988, Jan 24, 2006
    #1
    1. Advertising

  2. ma740988

    Guest

    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?
     
    , Jan 24, 2006
    #2
    1. Advertising

  3. ma740988

    mlimber Guest

    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
     
    mlimber, Jan 24, 2006
    #3
  4. ma740988

    Earl Purple Guest

    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.
     
    Earl Purple, Jan 24, 2006
    #4
  5. ma740988

    mlimber Guest

    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
     
    mlimber, Jan 24, 2006
    #5
  6. "mlimber" <> wrote in message
    news:...

    >> 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.
     
    Andrew Koenig, Jan 24, 2006
    #6
  7. ma740988

    ma740988 Guest

    > > 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!!
     
    ma740988, Jan 24, 2006
    #7
  8. ma740988

    mlimber Guest

    Andrew Koenig wrote:
    > "mlimber" <> wrote in message
    > news:...
    >
    > >> 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, Jan 24, 2006
    #8
  9. ma740988

    mlimber Guest

    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
     
    mlimber, Jan 24, 2006
    #9
  10. ma740988

    Earl Purple Guest

    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).
     
    Earl Purple, Jan 24, 2006
    #10
  11. ma740988

    ma740988 Guest


    > 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.
     
    ma740988, Jan 24, 2006
    #11
  12. ma740988

    Pete Becker Guest

    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)
     
    Pete Becker, Jan 24, 2006
    #12
  13. ma740988

    ma740988 Guest


    > 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?
     
    ma740988, Jan 25, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page