-
passing an array as a pointer to a function
Hello!!
It's the first time I post at your forum..
I can clearly understand how to pass a dynamic array to a function and modified within the function..
My aim is to get back the array initialized as I am trying on the next sample of code..
Any help would mean a lot to me!
Code:
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <iostream>
#include <fstream>
using namespace std;
#define N 3 //number of bodies
void initialise( double *M[], double *X[], double *y[])
{
*M[1]=0.001; *M[2]= 0.002; *M[3]= 1.; //Masses (the last body must be the gratest)
*X[0]=0.; //Time
*X[1]=0.9741; *X[2]=0.; *X[3]=0.1; //x,y,z for body 1 MOON
*X[4]=2.2933; *X[5]=0.; *X[6]=1.; //x,y,z for body 2 EARTH
*X[7]=0.0055607; *X[8]=0.; *X[9]=0.0021;//x,y,z for body 3 SUN
*X[10]=0.2; *X[11]=1.0327; *X[12]=0.0005; //Vx,Vy,Vz for body 1
*X[13]=0.1; *X[14]=0.6320; *X[15]=0.0005; //Vx,Vy,Vz for body 2
*X[16]=0.01; *X[17]=0.0022967; *X[18]=0.0000015;//Vx,Vy,Vz for body 3
for ( int i=0; i<=3*(N-1); ++i ) *y[i] = *X[i];
for ( int i=3*(N-1)+1; i<=6*(N-1); ++i ) *y[i] = *X[i+3];
}
int main()
{
double *M=new double[N+1]; //the masses of the bodies
double *X=new double[6*N+1]; //time,positions,velocities of N bodies
double *y=new double[6*(N-1)+1]; //time,positions,velocities of N-1 bodies
initialise( &M, &X, &y);
for (int i=0; i<=6*N; ++i) cout<<X[i]<<endl;
return 0;
}
-
Re: passing an array as a pointer to a function
Quote:
I can clearly understand how to pass a dynamic array to a function and modified within the function..
Perhaps not. You just need to pass a pointer to the memory of the array
Code:
void initialise( double *M, double *X, double *y)
{
M[1]=0.001; M[2]= 0.002; M[3]= 1.; //Masses (the last body must be the gratest)
X[0]=0.; //Time
X[1]=0.9741; X[2]=0.; X[3]=0.1; //x,y,z for body 1 MOON
X[4]=2.2933; X[5]=0.; X[6]=1.; //x,y,z for body 2 EARTH
X[7]=0.0055607; X[8]=0.; X[9]=0.0021;//x,y,z for body 3 SUN
X[10]=0.2; X[11]=1.0327; X[12]=0.0005; //Vx,Vy,Vz for body 1
X[13]=0.1; X[14]=0.6320; X[15]=0.0005; //Vx,Vy,Vz for body 2
X[16]=0.01; X[17]=0.0022967; X[18]=0.0000015;//Vx,Vy,Vz for body 3
for ( int i=0; i<=3*(N-1); ++i )
y[i] = X[i];
for ( int i=3*(N-1)+1; i<=6*(N-1); ++i )
y[i] = X[i+3];
}
int main()
{
double *M = new double[N+1]; //the masses of the bodies
double *X = new double[6*N+1]; //time,positions,velocities of N bodies
double *y = new double[6*(N-1)+1]; //time,positions,velocities of N-1 bodies
initialise( M, X, y);
for (int i=0; i<=6*N; ++i)
cout<<X[i]<<endl;
Why not use the STL vector class?
-
Re: passing an array as a pointer to a function
Quote:
I can clearly understand how to pass a dynamic array to a function and modified within the function..
Of course! I can't... I saw my mistake afterwards, and i didn't know how to modify the post...
It was so simple..!!
Quote:
Why not use the STL vector class?
Because vectors need more time to execute (at least this what I know)...
I am doing a project, that has to run for many iterations, so I have to take under consideration the execution time..
Thank you very much 2kaud!
Thank you for your help and you instant reply!
-
Re: passing an array as a pointer to a function
Quote:
i didn't know how to modify the post...
I believe you need to have made several (5?) posts before you obtain the ability to edit your posts.
initialise() could also be defined as
Code:
void initialise( double M[], double X[], double y[])
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
nebula987
... Because vectors need more time to execute (at least this what I know)...
And what is the source (or the reason) of that "knowledge"? Did you measure the difference in executing using vectors and plain pointers?
Or you read it in some of the articles? Which one?
And what was the difference?
-
Re: passing an array as a pointer to a function
I haven't read that in an article, I suppose that needs more time, because STL vector is a class, and I include an extra library...
Of course for programs that has to run a short time, this difference is insignificant, but for programs that has to run for hours or days, I have to take that in mind..
-
Re: passing an array as a pointer to a function
I would be grateful to you if you could solve me a problem in the same part of code..
What if I wanted to pass an array to a function and again inside a function call it to an other function.. (like Inception :-P)
Code:
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <iostream>
#include <fstream>
using namespace std;
#define N 3 //number of bodies
void init_y_arr( double *y, double *X )
{
for ( int i=0; i<=3*(N-1); ++i ) y[i] = X[i];
for ( int i=3*(N-1)+1; i<=6*(N-1); ++i ) y[i] = X[i+3];
}
void initialise( double *M, double *X, double *y)
{
M[1]=0.001; M[2]= 0.002; M[3]= 1.; //Masses (the last body must be the gratest)
X[0]=0.; //Time
X[1]=0.9741; X[2]=0.; X[3]=0.1; //x,y,z for body 1 MOON
X[4]=2.2933; X[5]=0.; X[6]=1.; //x,y,z for body 2 EARTH
X[7]=0.0055607; X[8]=0.; X[9]=0.0021;//x,y,z for body 3 SUN
X[10]=0.2; X[11]=1.0327; X[12]=0.0005; //Vx,Vy,Vz for body 1
X[13]=0.1; X[14]=0.6320; X[15]=0.0005; //Vx,Vy,Vz for body 2
X[16]=0.01; X[17]=0.0022967; X[18]=0.0000015;//Vx,Vy,Vz for body 3
init_y_arr(y, X);//How sould i write it?
}
int main()
{
double *M = new double[N+1]; //the masses of the bodies
double *X = new double[6*N+1]; //time,positions,velocities of N bodies
double *y = new double[6*(N-1)+1]; //time,positions,velocities of N-1 bodies
initialise( M, X, y);
for (int i=0; i<=6*(N-1); ++i)
cout<<y[i]<<endl;
return 0;
}
-
Re: passing an array as a pointer to a function
Code:
init_y_arr(y, X);//How sould i write it?
What's wrong with this?
-
Re: passing an array as a pointer to a function
Quote:
because STL vector is a class, and I include an extra library...
Of course for programs that has to run a short time, this difference is insignificant, but for programs that has to run for hours or days, I have to take that in mind..
Take what in mind? Why do you think that as STL vector is a class it includes an extra library? and why do you think that using a class like a vector has a performance impact over managing the memory allocation and access direct in the program?
-
Re: passing an array as a pointer to a function
I'd like to suggest that you get out of the habit of putting multiple statements on one line. That code is pretty messy to read. As you develop larger apps, you need to make sure they're easy to read and debug. Multiple statements on a single line goes against that goal.
Also, avoid single character or meaningless variable names. You know what they mean now, but you won't a year from now and neither will the next guy that has to look at your code.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
nebula987
I haven't read that in an article, I suppose that needs more time, because STL vector is a class, and I include an extra library...
Of course for programs that has to run a short time, this difference is insignificant, but for programs that has to run for hours or days, I have to take that in mind..
I have to tell you that you are wrong. :(
And I am 100% sure that your own array and memory management is much less effective than the STL vector class has.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
nebula987
I haven't read that in an article, I suppose that needs more time, because STL vector is a class, and I include an extra library...
Of course for programs that has to run a short time, this difference is insignificant, but for programs that has to run for hours or days, I have to take that in mind..
Both std::array and std::vector are defined to have a contiguous memory layout (as of the C++ 11 standard). This means they are guaranteed to be as efficient as old-style C arrays (you're currently using) when it comes to accesses.
Note that if you allocate heap memory using new[] you also need to deallocate it using delete[]. Otherwise you risk a memory leak.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
2kaud
Code:
init_y_arr(y, X);//How sould i write it?
What's wrong with this?
sorry! It works fine..! I have messed it up to this thread.. :-D
Quote:
Originally Posted by
GCDEF
I'd like to suggest that you get out of the habit of putting multiple statements on one line. That code is pretty messy to read. As you develop larger apps, you need to make sure they're easy to read and debug. Multiple statements on a single line goes against that goal.
Also, avoid single character or meaningless variable names. You know what they mean now, but you won't a year from now and neither will the next guy that has to look at your code.
I am going to agrree with you, I will have it in my mind...
Quote:
I have to tell you that you are wrong.
And I am 100% sure that your own array and memory management is much less effective than the STL vector class has.
Quote:
Both std::array and std::vector are defined to have a contiguous memory layout (as of the C++ 11 standard). This means they are guaranteed to be as efficient as old-style C arrays (you're currently using) when it comes to accesses.
Note that if you allocate heap memory using new[] you also need to deallocate it using delete[]. Otherwise you risk a memory leak.
For the 2 posts above, I must say that I don't know so much deep details about how effective is using arrays or vectors, although thank you for your suggestions..!
The reason why I reject the vector method is because I am doing a project for a master and I have to do a code that is going to be used to an already existing code, and I have to do it that that way...
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by nebula987
The reason why I reject the vector method is because I am doing a project for a master and I have to do a code that is going to be used to an already existing code, and I have to do it that that way...
That is not a good reason to reject the usage of std::vector or std::array. You can always write your own using these standard library facilities, and then expose them as pointers to the first element of an array when you need to interface with code that cannot handle them, but that can handle such pointers.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
zizz
Both std::array and std::vector are defined to have a contiguous memory layout (as of the C++ 11 standard). This means they are guaranteed to be as efficient as old-style C arrays (you're currently using) when it comes to accesses.
This is slightly off.
it'll be as efficient as old-style ALLOCATED C style array.
by it's very nature, a C style array does not need allocation or deallocation, nor does it need (indirect) access through a pointer.
in that respect c-style array -> std::array<>
heap allocated c-style array -> std::vector<>
there are cases where local vs heap allocated might be an important decision factor.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
OReubens
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.
-
Re: passing an array as a pointer to a function
you're missing the point.
a non allocated c-style array as in 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.
-
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.)
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
OReubens
you're missing the point.
a non allocated c-style array as in
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.)
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
laserlight
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.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
zizz
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.
Quote:
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.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
superbonzo
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. :)
-
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?
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
laserlight
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.
-
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
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
2kaud
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
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 ...
-
Re: passing an array as a pointer to a function
So that result is the same for both foo() and bar() :)
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
superbonzo
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.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
OReubens
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.
-
Re: passing an array as a pointer to a function
Quote:
Originally Posted by
zizz
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 :rolleyes: ... 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 ? :rolleyes:
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 ...
