CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 30 of 30
  1. #16
    Join Date
    Aug 2013
    Posts
    55

    Re: passing an array as a pointer to a function

    Quote Originally Posted by OReubens View Post
    This is slightly off.

    it'll be as efficient as old-style ALLOCATED C style array.
    No.

    There's no difference in what "memory" these data structures (C-style array, std::array and std::vector) can be allocated in, be it static, automatic, free store or something else.

    And they can all be accessed in the same way for example via a pointer to the first element with the same efficiency.
    Last edited by zizz; April 29th, 2014 at 12:00 AM.

  2. #17
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: passing an array as a pointer to a function

    you're missing the point.
    a non allocated c-style array as in
    Code:
    int a[50];
    whatever it's storage does NOT need indirection via a pointer.

    wheras with vector<> whatever it's storage, will ALWAYS have an indirection via a pointer.

    that alone can be enough to make an impact on performance.

  3. #18
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,765

    Re: passing an array as a pointer to a function

    Quote Originally Posted by OReubens
    c-style array (...) whatever it's storage does NOT need indirection via a pointer.
    Once you start passing it around as a pointer to its first element you end up with that indirection anyway. (Oh, and a thought came to mind: conceptually, it still is a pointer dereference according to the semantics, even before you start passing it around.)
    Last edited by laserlight; April 29th, 2014 at 10:08 AM.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  4. #19
    Join Date
    Aug 2013
    Posts
    55

    Re: passing an array as a pointer to a function

    Quote Originally Posted by OReubens View Post
    you're missing the point.
    a non allocated c-style array as in
    Code:
    int a[50];
    whatever it's storage does NOT need indirection via a pointer.

    wheras with vector<> whatever it's storage, will ALWAYS have an indirection via a pointer.

    that alone can be enough to make an impact on performance.
    You're making a common mistake namely to confuse C++ constructs with possible implementations of these constructs.

    Such second-guessing (also called premature optimization) leads to inferior code. It's better to program at the highest abstraction level supported by the language for clear and readable code and worry about efficiency when a bottleneck has been established. And then it usually turns out that an ill adviced data-structure or algorithm is to blame rather than a certain language construct.

    I've written a small test program that makes random accesses to a C-style array, an std::vector and an std::array. I run this with Visual Studio Express 2013 with full optimization in release mode.

    The result is that there's no difference in performance of the arrays. I know one cannot draw general conclusions from tests like this but at least Microsoft's C++ implementation didn't stumble on the pointer indirection you claimed is ALWAYS present and detrimental to efficiency. Here it wasn't.

    Code:
    #include <algorithm>
    #include <chrono>
    #include <vector>
    #include <array>
    
    typedef std::chrono::time_point<std::chrono::high_resolution_clock> Kronos; // time type
    inline Kronos now() { // current time
    	return std::chrono::high_resolution_clock::now();
    }
    inline double elapsed(Kronos now, Kronos then) { // elapsed time in seconds
    	return static_cast<double>(std::chrono::duration_cast<std::chrono::microseconds>(now-then).count())*0.000001;
    }
    
    void arrays_test() {
    
    	const int R=100000; // number of repeats
    	const int N=10000; // array length
    	
    	int c[N]; // C-style array
    	std::vector<int> v(N); // std::vector
    	std::array<int, N> a; // std::array
    
    	Kronos t0, t1; // timers
    	int r; // result
    
    		// initialize arrays
    	for (int i=0; i<N; ++i) v[i] = i; // assign integer sequence 0 .. N-1 to std::vector
    	std::random_shuffle (v.begin(), v.end()); // shuffle to random order
    	for (int i=0; i<N; ++i) c[i] = v[i]; // copy to C-style array
    	for (int i=0; i<N; ++i) a[i] = v[i]; // copy to std::array
    
    	    // measure C-style array
    	t0 = now();
    	r=0;
    	for (int j=0; j<R; ++j) {
    		for (int i=0; i<N; ++i) {
    			r += c[c[c[i]]]; // 3 accesses
    		}
    	}
    	t1 = now();
    	std::cout << r << "/"<< elapsed(t1,t0) << " (C-style array)" << std::endl;
    
    	    // measure std::vector
    	t0 = now();
    	r=0;
    	for (int j=0; j<R; ++j) {
    		for (int i=0; i<N; ++i) {
    			r += v[v[v[i]]];  // 3 accesses
    		}
    	}
    	t1 = now();
    	std::cout << r << "/"<< elapsed(t1,t0) << " (std::vector)" << std::endl;
    
    	    // measure std::array
    	t0 = now();
    	r=0;
    	for (int j=0; j<R; ++j) {
    		for (int i=0; i<N; ++i) {
    			r += a[a[a[i]]]; // 3 accesses
    		}
    	}
    	t1 = now();
    	std::cout << r << "/"<< elapsed(t1,t0) << " (std::array)" << std::endl;
    
    } // arrays_test
    The output from the code as posted is:

    158067456/1.32008 (C-style array)
    158067456/1.31207 (std::vector)
    158067456/1.31408 (std::array)

    (The first integer is just to make sure the loops calculate a result and thus cannot be aggressively reduced by the optimizer, and also to assure the loops really are functionally identical.)
    Last edited by zizz; May 1st, 2014 at 05:21 AM.

  5. #20
    Join Date
    Oct 2008
    Posts
    1,456

    Re: passing an array as a pointer to a function

    Quote Originally Posted by laserlight View Post
    Oh, and a thought came to mind: conceptually, it still is a pointer dereference according to the semantics, even before you start passing it around.
    the issue is not whether a dereference conceptually occurs or not, the point is if such a dereference implies a memory access to the pointer value or not.

    Quote Originally Posted by zizz
    The result is that there's no difference in performance of the arrays. I know one cannot draw general conclusions from tests like this but at least Microsoft's C++ implementation didn't stumble on the pointer indirection you claimed is ALWAYS present and detrimental to efficiency. Here it wasn't.
    the fact that is theorically "present" does not exclude the possibility that it will be optimized anyway (*). In order to show the effect of that indirection you should force the compiler to perform a new "access" for each iteration, something like this:

    Code:
    #include <vector>
    #include <array>
    #include <iostream>
    #include <ctime>
    
    struct A{ int c[10]; A(){ std::cout << "we need a type with a nontrivial ctor for fair testing ...\n"; } };
    
    int foo( int i ) { static A c; return c.c[i]++; }
    int bar( int i ) { static std::vector<int> c(10); return c[i]++; }
    
    int main( int argc, char* argv[] )
    {
    	auto fptr = argc % 2 ? foo : bar; // just to avoid inlining
    	int result = 0;
    
    	fptr(0); // force static initialization
    
    	auto time = std::clock();
    
    	for( int c = 0; c < 100000000; ++c ) result += fptr( c % 10 );
    
    	auto duration = std::clock() - time;
    
    	std::cout << ( fptr == foo ? "foo" : "bar" ) << ": " << result << " in " << duration;
    }
    on my system ( ~10 runs each, both interleaved or not ), this gives a stable avarage slowdown of 46% for the vector version ( the slowdown increases to 60% if we replace A with a plain array due to the static initialization code as the asm shows, hence the non trivial constructor ).

    EDIT: (*) to clarify, in your code, the indirection OReubens alluded to does occur ( so it is correct to say that it always occurs when an allocated array is involved ), it just occurs only once instead of for each and every iteration, hence making it to disappear in your measurement.
    Last edited by superbonzo; May 1st, 2014 at 09:53 AM.

  6. #21
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: passing an array as a pointer to a function

    Quote Originally Posted by zizz View Post
    You're making a common mistake namely to confuse C++ constructs with possible implementations of these constructs.
    Actually, i'm more into the reasoning that if performance is at all relevant to you, you SHOULD have a semi decent understanding of how it is actually implemented or you'll make wrong decisions up front that could ruin a lot of effort downstream.

    I give lectures on optimization so I do actually have 'some' experience in this matter. ;-)

    If performance is irrelevant, use whatever language construct gets the programming done fastest. This is in fact a big part of optimisation as well because whatever development time you can save in the parts you know up front won't have any impact on performance is the time you'll have left to spend on optimizing where it does matter.

    Such second-guessing (also called premature optimization) leads to inferior code.
    the choice between an array and a vector (or the plain C variants thereof) are rarely going to be making any kind of impact in performance except for really really exceptional cases. The reasons to choose one of the other typically has more to do with how it's being used, and the impact there can matter a LOT.

    vector by it's nature is allocated, and where it's allocated from doesn't even matter. The allocation and deallocation process will come at a cost.
    array is not allocated and it's storage location is determined by how you declared it.

    if you have a function that is called a lot, then the mere creation of a vector every time through the loop might end up costing you a lot in allocation/deallocation time. Where an array would cost you nothing (maybe).
    But then we might be talking about a container of an object with a high cost for construction, in that case, a large array to account for the worst case storage amount could be more costly than a vector that might on average only need to construct a few.


    I'm not saying premature optimisation is a good thing, because it obviously isn't.
    But the other thing you're proposing "It's better to program at the highest abstraction level supported by the language for clear and readable code and worry about efficiency when a bottleneck has been established." is equally bad.
    You might not have enough time to "get back to it" and change the code to the better construct. Or the high level abstraction might have set you on a road that makes alternate solutions "impossible" within the project requirements.

    As programmers we make a lot of "informed guesses" about what we do, and this is where a good programmer will do better than an unexperienced one. If you have need container, and you know you'll be searching a lot in it, then yes, a map might be better than a vector, that doesn't mean a map is Always going to be better, even if you'll be searching a lot. So we "guess" about the typical usage case and hope that the trick we pulled out of our hat will be adequate.

    The better you know how the internals of your libraries work, the better you'll be at making these guesses. So it's not so much about premature optimisation, but about making informed guesses that are "good enough" the first time around so you don't have to optimize.

  7. #22
    Join Date
    Aug 2013
    Posts
    55

    Re: passing an array as a pointer to a function

    Quote Originally Posted by superbonzo View Post
    this gives a stable avarage slowdown of 46% for the vector version
    I ran your test program and with my compiler there's no difference. Well there is a small difference of about 2% but that's to be expected and sometimes the C-array is the winner and sometimes the vector. It certainly isn't anyway near 46%

    So it seems the little green alien from outer space you claim is sitting in std::vector preventing it from being efficient can easily be scared away with a decent optimizing compiler.
    Last edited by zizz; May 2nd, 2014 at 12:22 AM.

  8. #23
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,765

    Re: passing an array as a pointer to a function

    Maybe some kind of checked iterator feature that also affects array index style accesses was not turned off?
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  9. #24
    Join Date
    Oct 2008
    Posts
    1,456

    Re: passing an array as a pointer to a function

    Quote Originally Posted by laserlight View Post
    Maybe some kind of checked iterator feature that also affects array index style accesses was not turned off?
    nope, here is a vector-less version showing the same phenomenon:

    Code:
    #include <iostream>
    #include <ctime>
    
    int  sptr[10] = {};
    int* cptr = new int[10];
    
    int foo( int i ) { static int* c = sptr; return c[i]++; }
    int bar( int i ) { static int* c = cptr; return c[i]++; }
    
    int main( int argc, char* argv[] )
    {
    	auto fptr = argc % 2 ? foo : bar; // just to avoid inlining
    	int result = 0;
    
    	fptr(0); // force static initialization
    
    	auto time = std::clock();
    
    	for( int c = 0; c < 100000000; ++c ) result += fptr( c % 10 );
    
    	auto duration = std::clock() - time;
    
    	std::cout << ( fptr == foo ? "foo" : "bar" ) << ": " << result << " in " << duration;
    }
    foo gives ~500ms whereas bar gives ~1000ms. Here is the asm given by the vs2010 I'm testing this on:

    Code:
    //foo
    009F1002  in          al,dx
    009F1003  mov         ecx,dword ptr [i]  
    009F1006  mov         eax,dword ptr sptr (9F3374h)[ecx*4]  
    009F100D  lea         edx,[eax+1]  
    009F1010  mov         dword ptr sptr (9F3374h)[ecx*4],edx  
    009F1017  pop         ebp  
    009F1018  ret
    
    //bar
    009F1020  push        ebp
    009F1021  mov         ebp,esp  
    009F1023  mov         eax,1  
    009F1028  test        byte ptr [$S1 (9F33A4h)],al  
    009F102E  jne         bar+32h (9F1052h)  
    009F1030  mov         ecx,dword ptr [cptr (9F339Ch)]  
    009F1036  mov         edx,dword ptr [i]  
    009F1039  or          dword ptr [$S1 (9F33A4h)],eax  
    009F103F  mov         eax,dword ptr [ecx+edx*4]  
    009F1042  push        esi  
    009F1043  lea         esi,[eax+1]  
    009F1046  mov         dword ptr [ecx+edx*4],esi  
    009F1049  mov         dword ptr [c (9F33A0h)],ecx  
    009F104F  pop         esi  
    009F1050  pop         ebp  
    009F1051  ret  
    009F1052  mov         ecx,dword ptr [c (9F33A0h)]  
    009F1058  mov         edx,dword ptr [i]  
    009F105B  mov         eax,dword ptr [ecx+edx*4]  
    009F105E  push        esi  
    009F105F  lea         esi,[eax+1]  
    009F1062  mov         dword ptr [ecx+edx*4],esi  
    009F1065  pop         esi  
    009F1066  pop         ebp
    009F1067  ret
    where you can see the indrection in the bar case. Yes, there are many other things going on there, so the slowdown cannot be reduced to that indirection alone; but still, it's reasonable to claim that any asm difference here is a consequence of the ability of avoiding the indirection in the foo() case and hence it's sufficient to confute zizz's claim. Could you post your asm output for a comparison ?

    Quote Originally Posted by zizz
    So it seems the little green alien from outer space you claim is sitting in std::vector preventing it from being efficient can easily be scared away with a decent optimizing compiler.
    this is irrelevant and it has nothing to do with std::vector; your claim was that the memory where an array is allocated does not make any difference in performance, whereas this ( no green aliens, just basic knowledge on how an array access is implemented ) shows you're wrong. The fact that most of the times this difference is optimized away does not change the result.
    Last edited by superbonzo; May 2nd, 2014 at 02:46 AM.

  10. #25
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: passing an array as a pointer to a function

    Code:
    int* cptr = new int[10];
    I guess should be
    Code:
    int* cptr = new int[10]();
    Under VS20012, for foo I get timings in the range 330 - 380 and for bar I get timings in the range 350 - 400.

    Assembler code
    Code:
    ; 12   : int foo(int i) { static int* c = sptr; return c[i]++; }
    
    	push	ebp
    	mov	ebp, esp
    	mov	edx, DWORD PTR _i$[ebp]
    	mov	eax, DWORD PTR ?sptr@@3PAHA[edx*4]
    	lea	ecx, DWORD PTR [eax+1]
    	mov	DWORD PTR ?sptr@@3PAHA[edx*4], ecx
    	pop	ebp
    	ret	0
    Code:
    ; 13   : int bar(int i) { static int* c = cptr; return c[i]++; }
    
    	push	ebp
    	mov	ebp, esp
    	mov	eax, DWORD PTR ?$S1@?1??bar@@YAHH@Z@4IA
    	push	esi
    	test	al, 1
    	jne	SHORT $LN4@bar
    	mov	esi, DWORD PTR ?cptr@@3PAHA		; cptr
    	or	eax, 1
    	mov	DWORD PTR ?$S1@?1??bar@@YAHH@Z@4IA, eax
    	mov	eax, DWORD PTR _i$[ebp]
    	mov	DWORD PTR ?c@?1??bar@@YAHH@Z@4PAHA, esi
    	mov	edx, DWORD PTR [esi+eax*4]
    	lea	ecx, DWORD PTR [edx+1]
    	mov	DWORD PTR [esi+eax*4], ecx
    	mov	eax, edx
    	pop	esi
    	pop	ebp
    	ret	0
    $LN4@bar:
    	mov	esi, DWORD PTR ?c@?1??bar@@YAHH@Z@4PAHA
    	mov	eax, DWORD PTR _i$[ebp]
    	mov	edx, DWORD PTR [esi+eax*4]
    	lea	ecx, DWORD PTR [edx+1]
    	mov	DWORD PTR [esi+eax*4], ecx
    	mov	eax, edx
    	pop	esi
    	pop	ebp
    	ret	0
    Last edited by 2kaud; May 2nd, 2014 at 03:56 AM.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  11. #26
    Join Date
    Oct 2008
    Posts
    1,456

    Re: passing an array as a pointer to a function

    Quote Originally Posted by 2kaud View Post
    I guess should be [...]
    uhm, why ? conceptually, whether the array is zeroed or not does not make a difference in this case ... of course, this may end up making the compiler to opt out for this or that optimization, but

    Quote Originally Posted by 2kaud View Post
    Under VS20012, for foo I get timings in the range 330 - 380 and for bar I get timings in the range 350 - 400.
    the point is not how huge the slowdown is ( which depends on many factors and optimizations as the asm above shows ), the slowdown level of my example is clearly a special unfortunate case. The point is if the slow down exists at all and if it is specifically related to the nature of the array or not.

    for example, here is a version of the previous code where the optimization happens to be minimal (again vs2010). The slow down in this case is of the order of the few percents, but it shows well the point:

    Code:
    #include <iostream>
    #include <ctime>
    
    struct A{A(){std::cout<<"non trivial ctor";}};
    
    int  sptr[10] = {};
    int* cptr = new int[10];
    
    int foo( int i ) { static A a; static int* c = sptr + 1; return c[i]; }
    int bar( int i ) { static A a; static int* c = cptr + 1; return c[i]; }
    
    int main( int argc, char* argv[] )
    {
    	auto fptr = argc % 2 ? foo : bar; // just to avoid inlining
    	int result = 0;
    
    	fptr(argc); // force static initialization
    
    	auto time = std::clock();
    
    	for( int c = 0; c < 10000000; ++c ) for( int j = 0; j < 10; ++j ) result += fptr(j);
    
    	auto duration = std::clock() - time;
    
    	std::cout << ( fptr == foo ? "foo" : "bar" ) << ": " << result << " in " << duration;
    }
    the asm:

    Code:
         9: int foo( int i ) { static A a; static int* c = sptr + 1; return c[i]; }
    00BC1000  push        ebp  
    00BC1001  mov         ebp,esp  
    00BC1003  mov         eax,dword ptr fs:[00000000h]  
    00BC1009  push        0FFFFFFFFh
    00BC100B  push        offset __ehhandler$?foo@@YAHH@Z (0BC1D2Eh)  
    00BC1010  push        eax  
    00BC1011  mov         eax,1
    00BC1016  mov         dword ptr fs:[0],esp  
    00BC101D  test        byte ptr [$S1 (0BC33A8h)],al  
    00BC1023  jne         foo+5Dh (0BC105Dh)  
    00BC1025  or          dword ptr [$S1 (0BC33A8h)],eax
    00BC102B  mov         dword ptr [ebp-4],0  
    00BC1032  mov         eax,dword ptr [__imp_std::cout (0BC2058h)]  
    00BC1037  push        offset string "ctor" (0BC2124h)  
    00BC103C  push        eax  
    00BC103D  call        std::operator<<<std::char_traits<char> > (0BC1270h)  
    00BC1042  mov         ecx,dword ptr [i]  
    00BC1045  mov         eax,dword ptr sptr+4 (0BC3378h)[ecx*4]  
    00BC104C  add         esp,8  
    00BC104F  mov         ecx,dword ptr [ebp-0Ch]
    00BC1052  mov         dword ptr fs:[0],ecx  
    00BC1059  mov         esp,ebp  
    00BC105B  pop         ebp  
    00BC105C  ret  
    00BC105D  mov         edx,dword ptr [i]
    00BC1060  mov         ecx,dword ptr [ebp-0Ch]  
    00BC1063  mov         eax,dword ptr sptr+4 (0BC3378h)[edx*4]
    00BC106A  mov         dword ptr fs:[0],ecx
    00BC1071  mov         esp,ebp  
    00BC1073  pop         ebp  
    00BC1074  ret
    
    10: int bar( int i ) { static A a; static int* c = cptr + 1; return c[i]; }
    00BC1080  push        ebp  
    00BC1081  mov         ebp,esp  
    00BC1083  mov         eax,dword ptr fs:[00000000h]  
    00BC1089  push        0FFFFFFFFh  
    00BC108B  push        offset __ehhandler$?bar@@YAHH@Z (0BC1D0Eh)
    00BC1090  push        eax  
    00BC1091  mov         eax,1  
    00BC1096  mov         dword ptr fs:[0],esp
    00BC109D  test        byte ptr [$S2 (0BC33A4h)],al  
    00BC10A3  jne         bar+45h (0BC10C5h)  
    00BC10A5  or          dword ptr [$S2 (0BC33A4h)],eax  
    00BC10AB  mov         dword ptr [ebp-4],0  
    00BC10B2  mov         eax,dword ptr [__imp_std::cout (0BC2058h)]  
    00BC10B7  push        offset string "ctor" (0BC2124h)  
    00BC10BC  push        eax  
    00BC10BD  call        std::operator<<<std::char_traits<char> > (0BC1270h)  
    00BC10C2  add         esp,8  
    00BC10C5  mov         eax,2  
    00BC10CA  test        byte ptr [$S2 (0BC33A4h)],al  
    00BC10D0  jne         bar+79h (0BC10F9h)  
    00BC10D2  or          dword ptr [$S2 (0BC33A4h)],eax
    00BC10D8  mov         eax,dword ptr [cptr (0BC339Ch)]  
    00BC10DD  mov         ecx,dword ptr [i]  
    00BC10E0  add         eax,4  
    00BC10E3  mov         dword ptr [c (0BC33A0h)],eax  
    00BC10E8  mov         eax,dword ptr [eax+ecx*4]  
    00BC10EB  mov         ecx,dword ptr [ebp-0Ch]  
    00BC10EE  mov         dword ptr fs:[0],ecx  
    00BC10F5  mov         esp,ebp  
    00BC10F7  pop         ebp  
    00BC10F8  ret  
    00BC10F9  mov         eax,dword ptr [c (0BC33A0h)]
    00BC10FE  mov         edx,dword ptr [i]
    00BC1101  mov         ecx,dword ptr [ebp-0Ch]  
    00BC1104  mov         eax,dword ptr [eax+edx*4]  
    00BC1107  mov         dword ptr fs:[0],ecx  
    00BC110E  mov         esp,ebp  
    00BC1110  pop         ebp  
    00BC1111  ret
    this time the generated asms of the functions are nearly identical, with the following notable differences coming exactly from the different compile time knowledge the compiler has of the pointer values. Firstly, here is the "added" indirection we're speaking about:

    foo:
    00BC105D mov edx,dword ptr [i]
    00BC1063 mov eax,dword ptr sptr+4 (0BC3378h)[edx*4] <<< load from "sptr+1"

    bar:
    00BC10F9 mov eax,dword ptr [c (0BC33A0h)] <<< store the pointer value ...
    00BC10FE mov edx,dword ptr [i]
    00BC1104 mov eax,dword ptr [eax+edx*4] <<< and load

    plus, the knowledge of sptr allows the compiler to simplify the static initialization code in the foo case ( take a look at the test/jne instructions )(*).

    (*) EDIT: actually, as far as I can tell, the asm difference in the static initialization should not make any difference at all, so the runtime difference measured from the above asm should give the exact slow down due to the indirection alone in this case. maybe, someone more asm savvy than me could confirm that ...
    Last edited by superbonzo; May 2nd, 2014 at 04:29 AM. Reason: typos

  12. #27
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: passing an array as a pointer to a function

    uhm, why ?
    So that result is the same for both foo() and bar()
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  13. #28
    Join Date
    Aug 2013
    Posts
    55

    Re: passing an array as a pointer to a function

    Quote Originally Posted by superbonzo View Post
    your claim was that the memory where an array is allocated does not make any difference in performance,
    That's right.

    When you compare a C-array and an std:vector it doesn't matter where they're (both) allocated be it in static, automatic or free memory.

    You are confusing C++ with the implementation of C++. That's my point. It's a common mistake and you seem unable to get the distinction.

    Anyway, the question becomes: Regardless of in which memory the C-array and std::vector are (both) allocated, is there a performace difference when it comes to accesses?

    You claim there is but you haven't been able to show any. There is no trace of the little green alien you claim is bogging down the performace of the std::vector. At last not in the presence of a decent optimising compiler.
    Last edited by zizz; May 2nd, 2014 at 04:37 PM.

  14. #29
    Join Date
    Aug 2013
    Posts
    55

    Re: passing an array as a pointer to a function

    Quote Originally Posted by OReubens View Post
    I'm not saying premature optimisation is a good thing, because it obviously isn't.
    But the other thing you're proposing "It's better to program at the highest abstraction level supported by the language for clear and readable code and worry about efficiency when a bottleneck has been established." is equally bad.
    You might not have enough time to "get back to it" and change the code to the better construct. Or the high level abstraction might have set you on a road that makes alternate solutions "impossible" within the project requirements.
    I'm no stranger to optimization. This is a good link by the way,

    http://www.agner.org/optimize/optimizing_cpp.pdf

    I agree that optimization is a fine thing and that C++ is especially well suited for writing efficient code.

    But in my view your approach is old-fashioned. You're essentially saying that

    1. C is better than C++,
    2. prefer performance over correctness, and
    3. the programmer is smarter than an optimizing compiler.

    and I simply don't agree with that.

    It's like you're stuck in the 1970s.

    But today, there are higher abstractions like OO and functional programming. Focus is on writing correct code rater than clever code. And we trust compilers and interpreters to be highly efficient.
    Last edited by zizz; May 2nd, 2014 at 04:43 PM.

  15. #30
    Join Date
    Oct 2008
    Posts
    1,456

    Re: passing an array as a pointer to a function

    Quote Originally Posted by zizz View Post
    That's right. When you compare a C-array and an std:vector it doesn't matter where they're (both) allocated be it in static, automatic or free memory[...]
    oooh, now they are both allocated from the same memory ... so, the fact that you're comparing an automatic array and a free store array ( via std::vector ) in post #19 was just an oversight, ain't it ?

    all this would be funny, if it weren't confusing to anybody coming here reading the thread. Zizz, ( ruzzle, nuzzle, uj, whatever ) nobody cares of your self-esteem but you, so, please, stop polluting the forum with your egotistic non-sense oblitering others effort in conveying possibly helpful information to others ...

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured