public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/14809] New: performance depends on allocation methods
@ 2004-04-01 12:06 boeck at fhi-berlin dot mpg dot de
2004-04-01 13:25 ` [Bug c++/14809] " pinskia at gcc dot gnu dot org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: boeck at fhi-berlin dot mpg dot de @ 2004-04-01 12:06 UTC (permalink / raw)
To: gcc-bugs
Compiler: gcc 3.3.3
System: Redhat, SuSE 8.1, 8.2, 9.0, Pentium3, 1.2GHz, 2GB Ram
compiler options: default options, was compiled with "configure, make, make install"
command line: g++ -O2 file.cpp
compiler output: no warning, no error
output of "g++ -v":
Reading specs from /usr/local/gcc-3.3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: /soft/gcc/gcc-3.3.3/gcc-3.3.3/configure --prefix=/usr/local/gcc-3.3.3
--enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.3.3
The performance of a program seems to depend on the way how vectors are allocated:
Here are 4 small example codes:
(a) slow[35sec]: using C++ "new/delete"
(b) fast[22sec]: using C-like malloc
(c) slow[35sec]: using C-like malloc via function call
(d) fast[22sec]: using C-like malloc via INLINE fuction call
g++ -O2 [a,b,c,d].cpp
timex a.out
i don't understand, why the performance depends on the way how i allocate pointers.
Please help.
thanks
Sixten
----- a.cpp ---
#include <stdio.h>
int main ()
{
long it;
int i, n = 1000;
double *x = new double [n];
double *y = new double [n];
double a = 0.2, b = -a;
for (i=0; i < n; ++i) x[i] = y[i] = i;
for (it=0; it < 5000000L; ++it) {
for (i=0; i < n; ++i) {
y[i] += a * x[i];
y[i] += b * x[i];
}
}
printf ("%g\n", y[0]);
delete [] y;
delete [] x;
}
---- b.cpp ---
int main ()
{
long it;
int i, n = 1000;
double *x = (double *)malloc ((size_t)(n * sizeof(double)));
double *y = (double *)malloc ((size_t)(n * sizeof(double)));
double a = 0.2, b = -a;
for (i=0; i < n; ++i) x[i] = y[i] = i;
for (it=0; it < 5000000L; ++it) {
for (i=0; i < n; ++i) {
y[i] += a * x[i];
y[i] += b * x[i];
}
}
printf ("%g\n", y[0]);
free (y);
free (x);
}
--- c.cpp ---
double *myMalloc (int nElem)
{
return (double *)(malloc ((size_t)(nElem * sizeof(double))));
}
int main ()
{
long it;
int i, n = 1000;
double *x = myMalloc(n);
double *y = myMalloc (n);
double a = 0.2, b = -a;
for (i=0; i < n; ++i) x[i] = y[i] = i;
for (it=0; it < 5000000L; ++it) {
for (i=0; i < n; ++i) {
y[i] += a * x[i];
y[i] += b * x[i];
}
}
printf ("%g\n", y[0]);
free (y);
free (x);
}
--- d.cpp ---
inline double *myMalloc (int nElem)
{
return (double *)(malloc ((size_t)(nElem * sizeof(double))));
}
int main ()
{
long it;
int i, n = 1000;
double *x = myMalloc(n);
double *y = myMalloc (n);
double a = 0.2, b = -a;
for (i=0; i < n; ++i) x[i] = y[i] = i;
for (it=0; it < 5000000L; ++it) {
for (i=0; i < n; ++i) {
y[i] += a * x[i];
y[i] += b * x[i];
}
}
printf ("%g\n", y[0]);
free (y);
free (x);
}
--
Summary: performance depends on allocation methods
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boeck at fhi-berlin dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
@ 2004-04-01 13:25 ` pinskia at gcc dot gnu dot org
2004-04-01 13:27 ` falk at debian dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-04-01 13:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-04-01 13:25 -------
I cannot reproduce it on my machine with the mainline.
tin:~/src/gnu/gcctest>g++ -O2 pr14809.a.cc
tin:~/src/gnu/gcctest>time ./a.out
0
21.460u 0.020s 0:42.13 50.9% 0+0k 0+0io 180pf+0w
tin:~/src/gnu/gcctest>g++ -O2 pr14809.b.cc
time ./a.out
0
21.750u 0.110s 0:33.76 64.7% 0+0k 0+0io 177pf+0w
tin:~/src/gnu/gcctest>g++ -O2 pr14809.c.cc
tin:~/src/gnu/gcctest>!tim
time ./a.out
0
20.970u 0.750s 0:28.55 76.0% 0+0k 0+0io 177pf+0w
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
2004-04-01 13:25 ` [Bug c++/14809] " pinskia at gcc dot gnu dot org
@ 2004-04-01 13:27 ` falk at debian dot org
2004-04-01 15:13 ` boeck at sfhingx dot de
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: falk at debian dot org @ 2004-04-01 13:27 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From falk at debian dot org 2004-04-01 13:27 -------
It probably depends on alignment of the pointers relative to cache lines. You
should look at alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
2004-04-01 13:25 ` [Bug c++/14809] " pinskia at gcc dot gnu dot org
2004-04-01 13:27 ` falk at debian dot org
@ 2004-04-01 15:13 ` boeck at sfhingx dot de
2004-04-01 15:34 ` falk at debian dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: boeck at sfhingx dot de @ 2004-04-01 15:13 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From boeck at sfhingx dot de 2004-04-01 15:13 -------
Subject: Re: performance depends on allocation methods
hi,
> ------- Additional Comments From falk at debian dot org 2004-04-01 13:27
> -------
> It probably depends on alignment of the pointers relative to cache lines.
> You
> should look at alignment.
thank you very much for your response. i tried all compiler flags related
somehow to alignment. vectors allocated with "new" are still significantly
slower than those allocated with "malloc".
btw. i tried the test programs on some more linux machines. the effect seems
to be larger on SMP machines. but i don't know what this means...
any ideas???
:)
sixten
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
` (2 preceding siblings ...)
2004-04-01 15:13 ` boeck at sfhingx dot de
@ 2004-04-01 15:34 ` falk at debian dot org
2004-04-01 16:00 ` bangerth at dealii dot org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: falk at debian dot org @ 2004-04-01 15:34 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From falk at debian dot org 2004-04-01 15:34 -------
Compiler flags don't have any effect on this. I was suggesting to
examine alignment and try to adjust it manually. Also check
coalignment with respect to cache line index, maybe you have a one-way
associative cache and get collisions.
In any case, it seems unlikely that gcc can do much about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
` (3 preceding siblings ...)
2004-04-01 15:34 ` falk at debian dot org
@ 2004-04-01 16:00 ` bangerth at dealii dot org
2004-05-03 17:26 ` aleks at physik dot tu-berlin dot de
2004-05-03 18:23 ` bangerth at dealii dot org
6 siblings, 0 replies; 8+ messages in thread
From: bangerth at dealii dot org @ 2004-04-01 16:00 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-04-01 15:59 -------
I can't reproduce this either, but it took me a while until I understood
Falk's comment. The point is: you call malloc/new only once, so the run
time of these functions must necessarily be negligible and can't account
for the 13 second slowdown you observe. So it must be the output of these
functions (for example the alignment of the data region returned), which
however is not under gcc control.
Since none of us can reproduce this, I guess we should close this PR.
For the record, here are the results for running the four testcases:
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -O2 a.cc -o a
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -O2 b.cc -o b
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -O2 c.cc -o c
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -O2 d.cc -o d
g/x> time ./a ; time ./b ; time ./c ; time ./d
0
real 0m19.101s
user 0m18.792s
sys 0m0.016s
0
real 0m19.340s
user 0m19.092s
sys 0m0.019s
0
real 0m19.135s
user 0m18.869s
sys 0m0.014s
0
[1]+ Done emacs -fn 9x15 b.cc
real 0m20.012s
user 0m19.669s
sys 0m0.164s
W.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
` (4 preceding siblings ...)
2004-04-01 16:00 ` bangerth at dealii dot org
@ 2004-05-03 17:26 ` aleks at physik dot tu-berlin dot de
2004-05-03 18:23 ` bangerth at dealii dot org
6 siblings, 0 replies; 8+ messages in thread
From: aleks at physik dot tu-berlin dot de @ 2004-05-03 17:26 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From aleks at physik dot tu-berlin dot de 2004-05-03 17:26 -------
REOPEN the bug 14809: i can verify the problem partly.
performance with global static arrays of double's is up to 10% higher as with
pointers to dynamic (new or malloc) arrays of same size and type!!
PSA .. pointer to static arrays
time(average over 5runs): (big matrix multiplications, g++)
static=21.8sec; PSA=23.4sec ;dyn.new=23.4sec; dyn.malloc=23.0sec
(last week i had up to 3 sec diff.!?)
result: pointers slow down my prog!?
used memory: ca. 05 megabyte
computer: kernel 2.4.23-1.SMP i686
Dual Processor Pentium III, 1.2 GHz, 512K L2-Cache, 2530 bogomips
Red Hat Linux(2years old, but some updates (gcc,kernel,libs)
GCC: -3.3.3 --enable-shared --enable-languages=c,c++,f77
Thread model: posix, gcc version 3.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/14809] performance depends on allocation methods
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
` (5 preceding siblings ...)
2004-05-03 17:26 ` aleks at physik dot tu-berlin dot de
@ 2004-05-03 18:23 ` bangerth at dealii dot org
6 siblings, 0 replies; 8+ messages in thread
From: bangerth at dealii dot org @ 2004-05-03 18:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-05-03 18:23 -------
That's an unrelated thing. Sometimes you can get away with a smaller number
of dereferencing operations if memory is allocated statically.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14809
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-05-03 18:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-01 12:06 [Bug c++/14809] New: performance depends on allocation methods boeck at fhi-berlin dot mpg dot de
2004-04-01 13:25 ` [Bug c++/14809] " pinskia at gcc dot gnu dot org
2004-04-01 13:27 ` falk at debian dot org
2004-04-01 15:13 ` boeck at sfhingx dot de
2004-04-01 15:34 ` falk at debian dot org
2004-04-01 16:00 ` bangerth at dealii dot org
2004-05-03 17:26 ` aleks at physik dot tu-berlin dot de
2004-05-03 18:23 ` bangerth at dealii dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).