C++ is Slow?

[nw]

Hi all,

I'm constantly confronted with the following two techniques, which I
believe often produce less readable code, but I am told are faster
therefore better. Can anyone help me out with counter examples and
arguments?

1. The STL is slow.

More specifically vector. The argument goes like this:

"Multidimensional arrays should be allocated as large contiguous
blocks. This is so that when you are accessing the array and reach the
end of a row, the next row will already be in the cache. You also
don't need to spend time navigating pointers when accessing the array.
So a 2 dimensional array of size 100x100 should be created like this:

const int xdim=100;
const int ydim=100;

int *myarray = malloc(xdim*ydim*sizeof(int));

and accessed like this:

myarray[xdim*ypos+xpos] = avalue;

Is this argument reasonable? (Sounds reasonable to me, though the
small tests I've performed don't usually show any significant
difference).

To me this syntax looks horrible, am I wrong? Is vector the wrong
container to use? (My usual solution would be a vector<vector<int).
Would using a valarray help?

2. iostream is slow.

I've encountered this is work recently. I'd not considered it before,
I like the syntax and don't do so much IO generally... I'm just now
starting to process terabytes of data, so it'll become an issue. Is
iostream slow? specifically I encountered the following example
googling around. The stdio version runs in around 1second, the
iostream version takes 8seconds. Is this just down to a poor iostream
implementation? (gcc 4 on OS X). Or are there reasons why iostream is
fundamentally slower for certain operations? Are there things I should
be keeping in mind to speed up io?

// stdio version
#include <cstdio>
using namespace std;
const int NULA = 0;
int main (void) {
for( int i = 0; i < 100000000; ++i )
printf( "a" );
return NULA;
}

//cout version
#include <iostream>
using namespace std;
const int NULA = 0;
int main (void) {
std::ios_base::sync_with_stdio(false);

for( int i = 0; i < 100000000; ++i )
cout << "a" ;
return NULA;
}

[Ioannis Vranos]

nw wrote:

Hi all,

I'm constantly confronted with the following two techniques, which I
believe often produce less readable code, but I am told are faster
therefore better. Can anyone help me out with counter examples and
arguments?

1. The STL is slow.

More specifically vector. The argument goes like this:

"Multidimensional arrays should be allocated as large contiguous
blocks. This is so that when you are accessing the array and reach the
end of a row, the next row will already be in the cache. You also
don't need to spend time navigating pointers when accessing the array.
So a 2 dimensional array of size 100x100 should be created like this:

const int xdim=100;
const int ydim=100;

int *myarray = malloc(xdim*ydim*sizeof(int));

and accessed like this:

myarray[xdim*ypos+xpos] = avalue;

Is this argument reasonable? (Sounds reasonable to me, though the
small tests I've performed don't usually show any significant
difference).

To me this syntax looks horrible, am I wrong? Is vector the wrong
container to use? (My usual solution would be a vector<vector<int).
Would using a valarray help?

In normal cases you should use vector as you mentioned.

2. iostream is slow.

I've encountered this is work recently. I'd not considered it before,
I like the syntax and don't do so much IO generally... I'm just now
starting to process terabytes of data, so it'll become an issue. Is
iostream slow? specifically I encountered the following example
googling around. The stdio version runs in around 1second, the
iostream version takes 8seconds. Is this just down to a poor iostream
implementation? (gcc 4 on OS X). Or are there reasons why iostream is
fundamentally slower for certain operations? Are there things I should
be keeping in mind to speed up io?

// stdio version
#include <cstdio>
using namespace std;
const int NULA = 0;
int main (void) {
for( int i = 0; i < 100000000; ++i )
printf( "a" );
return NULA;
}

//cout version
#include <iostream>
using namespace std;
const int NULA = 0;
int main (void) {
std::ios_base::sync_with_stdio(false);

for( int i = 0; i < 100000000; ++i )
cout << "a" ;
return NULA;
}

I suppose it is an implementation issue. The two codes should undertake
the same time-cost. If you remove
"std::ios_base::sync_with_stdio(false);" the output is slower?
Also check the compiler optimisation switches, they can enhance the
run-time execution.

[Ioannis Vranos]

nw wrote:

>
More specifically vector. The argument goes like this:>
"Multidimensional arrays should be allocated as large contiguous
blocks. This is so that when you are accessing the array and reach the
end of a row, the next row will already be in the cache. You also
don't need to spend time navigating pointers when accessing the array.
So a 2 dimensional array of size 100x100 should be created like this:

const int xdim=100;
const int ydim=100;

int *myarray = malloc(xdim*ydim*sizeof(int));

and accessed like this:

myarray[xdim*ypos+xpos] = avalue;

Is this argument reasonable? (Sounds reasonable to me, though the
small tests I've performed don't usually show any significant
difference).

To me this syntax looks horrible, am I wrong? Is vector the wrong
container to use? (My usual solution would be a vector<vector<int).
Would using a valarray help?

I think your code is incorrect. Your approach corrected:
#include <cstdlib>

int main()
{
using namespace std;

const int XDIM= 100;

const int YDIM= 200;
int (*my_array)[YDIM]= static_cast<int (*)[200]( malloc(XDIM* YDIM
* **my_array) );

if(my_array== 0)
return EXIT_FAILURE;

for(size_t i= 0; i< XDIM; ++i)
for(size_t j= 0; j< YDIM; ++j)
my_array[i][j]= i+j;
// ...

free(my_array);

// ...
}
The equivalent C++ style:
include <cstdlib>

int main()
{
using namespace std;

const int XDIM= 100;

const int YDIM= 200;
int (*my_array)[YDIM]= new int[XDIM][YDIM];

for(size_t i= 0; i< XDIM; ++i)
for(size_t j= 0; j< YDIM; ++j)
my_array[i][j]= i+j;
}

The proper C++ approach:

#include <cstdlib>
#include <vector>

int main()
{
using namespace std;

const int XDIM= 100;

const int YDIM= 200;

vector<vector<int my_array(XDIM, vector<int>(YDIM));

for(vector<vector<int::size_type i= 0; i< my_array.size(); ++i)
for(vector<int>::size_type j= 0; j< my_array[i].size(); ++j)
my_array[i][j]= i+j;
// ...

// No need to clean up your memory or any other resource
// - RAII (Resource Acquisition Is Initialisation)

}

[Daniel T.]

Ioannis Vranos <iv*****@nospam.no.spamfreemail.grwrote:

The proper C++ approach:

vector<vector<int my_array(XDIM, vector<int>(YDIM));

That is not necessarily the proper approach. The above creates YDIM + 1
separate blocks of code which may, or may not be a good idea.

[Alex Vinokur]

On Feb 5, 1:19*am, nw <[e-mail]:
[snip]

>
1. The STL is slow.

Comparative performance measurement

C-qsort vs. STL-sort (including vectors)
http://groups.google.com/group/comp....dc98dcb6f0f9fc
[snip]

2. iostream is slow.

Copying files: C vs. C++
http://groups.google.com/group/log-f...8ee2a154042a0c
http://groups.google.com/group/sourc...c640ecc648422c

[snip]
Copying files: C vs. C++
http://groups.google.com/group/log-f...8ee2a154042a0c
http://groups.google.com/group/sourc...c640ecc648422c

[Ioannis Vranos]

Code correction:
Ioannis Vranos wrote:

nw wrote:

>>
More specifically vector. The argument goes like this:>
"Multidimensional arrays should be allocated as large contiguous
blocks. This is so that when you are accessing the array and reach the
end of a row, the next row will already be in the cache. You also
don't need to spend time navigating pointers when accessing the array.
So a 2 dimensional array of size 100x100 should be created like this:

const int xdim=100;
const int ydim=100;

int *myarray = malloc(xdim*ydim*sizeof(int));

and accessed like this:

myarray[xdim*ypos+xpos] = avalue;

Is this argument reasonable? (Sounds reasonable to me, though the
small tests I've performed don't usually show any significant
difference).

To me this syntax looks horrible, am I wrong? Is vector the wrong
container to use? (My usual solution would be a vector<vector<int).
Would using a valarray help?

I think your code is incorrect. Your approach corrected:
#include <cstdlib>

int main()
{
using namespace std;

const int XDIM= 100;

const int YDIM= 200;

==int (*my_array)[YDIM]= static_cast<int (*)[YDIM]( malloc(XDIM*
YDIM* sizeof(**my_array)) );

if(my_array== 0)
return EXIT_FAILURE;

for(size_t i= 0; i< XDIM; ++i)
for(size_t j= 0; j< YDIM; ++j)
my_array[i][j]= i+j;
// ...

free(my_array);

// ...
}
The equivalent C++ style:
include <cstdlib>

int main()
{
using namespace std;

const int XDIM= 100;

const int YDIM= 200;
int (*my_array)[YDIM]= new int[XDIM][YDIM];

for(size_t i= 0; i< XDIM; ++i)
for(size_t j= 0; j< YDIM; ++j)
my_array[i][j]= i+j;
}

The proper C++ approach:

#include <cstdlib>
#include <vector>

int main()
{
using namespace std;

const int XDIM= 100;

const int YDIM= 200;

vector<vector<int my_array(XDIM, vector<int>(YDIM));

for(vector<vector<int::size_type i= 0; i< my_array.size(); ++i)
for(vector<int>::size_type j= 0; j< my_array[i].size(); ++j)
my_array[i][j]= i+j;
// ...

// No need to clean up your memory or any other resource
// - RAII (Resource Acquisition Is Initialisation)

}

[nw]

That is, what, lets see, 1/100th is a milisecond,

1/1,000 is a nano second, 1/1,000,000 is a .. pico second? 8/100 of a pico
second? For something that is so fast and not used that often, do we care?
You might want to look up premature optimization.

That's just an example, in reality I'm looking at 19.2Gb (compressed
size) of text files, which I'll have to parse on a regular basis.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-02-05 13:48, nw wrote:

>That is, what, lets see, 1/100th is a milisecond,
1/1,000 is a nano second, 1/1,000,000 is a .. pico second? 8/100 of a pico
second? For something that is so fast and not used that often, do we care?
You might want to look up premature optimization.

That's just an example, in reality I'm looking at 19.2Gb (compressed
size) of text files, which I'll have to parse on a regular basis.

Depending on what kind of processing/parsing you are going to do (and
what kind of hardware you are running) it is very likely that disk I/O
or decompression will be the bottleneck.

--
Erik Wikström

[Puppet_Sock]

On Feb 5, 11:34*am, Erik Wikström <[e-mail]:

On 2008-02-05 13:48, nw wrote:

That is, what, lets see, 1/100th is a milisecond,
1/1,000 is a nano second, 1/1,000,000 is a .. pico second? 8/100 of a pico
second? *For something that is so fast and not used that often, do wecare?
You might want to look up premature optimization.

That's just an example, in reality I'm looking at 19.2Gb (compressed
size) of text files, which I'll have to parse on a regular basis.

Depending on what kind of processing/parsing you are going to do (and
what kind of hardware you are running) it is very likely that disk I/O
or decompression will be the bottleneck.

I'm going to (I hope) echo Erik's thoughts here.

Whenever you get to questions like "which is better" or "which
is faster" it is important to have a specification of what
really is better. "I like it that way" isn't a spec unless
the person saying it will give you money to do it his way.

And you need to measure it using several typical cases.
Presuming it is execution speed, you need a stopwatch.
And you need to compare various methods and see which
is faster and if it is significant. And you need to make
some tests to see what part of the app is using the time
and what parts are not making much of a difference.

Many stories are appropriate, but long winded and boring.
Just insert long shaggy-dog story of a "bug" that could
not be found when execution speed was perceived as a
problem, and a long attack on optimizing the code followed.
Only to end when the app was found to spend more than
90 percent of its time doing something other than the
part of the task being optimized. Such as Erik suggests,
where disk I/O might be using most of the time and there
isn't all that much you can do about it.
Socks

[Juha Nieminen]

Erik Wikström wrote:

On 2008-02-05 13:48, nw wrote:

>>That is, what, lets see, 1/100th is a milisecond,
1/1,000 is a nano second, 1/1,000,000 is a .. pico second? 8/100 of a pico
second? For something that is so fast and not used that often, do we care?
You might want to look up premature optimization.

That's just an example, in reality I'm looking at 19.2Gb (compressed
size) of text files, which I'll have to parse on a regular basis.

Depending on what kind of processing/parsing you are going to do (and
what kind of hardware you are running) it is very likely that disk I/O
or decompression will be the bottleneck.

While that might sound plausible in theory, unfortunately my own
real-life experience tells otherwise: When reading&parsing input and
printing formatted output (usually to a file), switching from C++
streams to C streams usually gives a considerable speedup with all the
compilers I have tried with. We are talking about at least twice the
speed, if not even more, which is not a small difference.

If you are reading&parsing hundreds of megabytes of input and
outputting also hundreds of megabytes, the difference could well be very
considerable (eg. 20 seconds instead of 1 minute).

[Jim Langston]

nw wrote:

Hi all,

I'm constantly confronted with the following two techniques, which I
believe often produce less readable code, but I am told are faster
therefore better. Can anyone help me out with counter examples and
arguments?

1. The STL is slow.

More specifically vector. The argument goes like this:

"Multidimensional arrays should be allocated as large contiguous
blocks. This is so that when you are accessing the array and reach the
end of a row, the next row will already be in the cache. You also
don't need to spend time navigating pointers when accessing the array.
So a 2 dimensional array of size 100x100 should be created like this:

const int xdim=100;
const int ydim=100;

int *myarray = malloc(xdim*ydim*sizeof(int));

and accessed like this:

myarray[xdim*ypos+xpos] = avalue;

Is this argument reasonable? (Sounds reasonable to me, though the
small tests I've performed don't usually show any significant
difference).

To me this syntax looks horrible, am I wrong? Is vector the wrong
container to use? (My usual solution would be a vector<vector<int).
Would using a valarray help?

2. iostream is slow.

I've encountered this is work recently. I'd not considered it before,
I like the syntax and don't do so much IO generally... I'm just now
starting to process terabytes of data, so it'll become an issue. Is
iostream slow? specifically I encountered the following example
googling around. The stdio version runs in around 1second, the
iostream version takes 8seconds. Is this just down to a poor iostream
implementation? (gcc 4 on OS X). Or are there reasons why iostream is
fundamentally slower for certain operations? Are there things I should
be keeping in mind to speed up io?

// stdio version
#include <cstdio>
using namespace std;
const int NULA = 0;
int main (void) {
for( int i = 0; i < 100000000; ++i )
printf( "a" );
return NULA;
}

//cout version
#include <iostream>
using namespace std;
const int NULA = 0;
int main (void) {
std::ios_base::sync_with_stdio(false);

for( int i = 0; i < 100000000; ++i )
cout << "a" ;
return NULA;
}

I don't know how you got yours to run in 1 second and 8 second. On my
platform it was taking too long and I reduced the iterations. Here is a
test program I did with results:

#include <ctime>
#include <cstdio>
#include <iostream>

const int interations = 1000000; // 100000000
// stdio version
int mainC (void) {

std::ios_base::sync_with_stdio(false);

for( int i = 0; i < interations; ++i )
printf( "a" );
return 0;
}

//cout version
int mainCPP ()
{
std::ios_base::sync_with_stdio(false);

for( int i = 0; i < interations; ++i )
std::cout << "a" ;
return 0;
}

int main()
{
clock_t start;
clock_t stop;

start = clock();
mainC();
stop = clock();
clock_t ctime = stop - start;

start = clock();
mainCPP();
stop = clock();
clock_t cpptime = stop - start;

std::cout << "C: " << ctime << " C++: " << cpptime << "\n";

std::cout << static_cast<double>( cpptime ) / ctime << "\n";

}

after a bunch of aaaa's...

C: 20331 C++: 23418
1.15184

This is showing the stl to be about 15% slower than the C code.

Microsoft Visual C++ .net 2003
Windows XP Service Pack 2

Unfortunately with my compiler my optimizations are disabled so I don't know
how it would be optimized. But it is not 8x difference.

I would be curious of the output of different compilers. Note that clock()
on microsoft platforms shows total time, not just processing time.

--
Jim Langston
ta*******@rocketmail.com

[Mirek Fidler]

I don't know how you got yours to run in 1 second and 8 second. On my

platform it was taking too long and I reduced the iterations. Here is a
after a bunch of aaaa's...

C: 20331 C++: 23418
1.15184

This is showing the stl to be about 15% slower than the C code.

Actually, this only proves that this particular library has both C and
C++ implementations inefficient...

Mirek

[nw]

Not sure what you're talking about here, but std::vector does allocate

contigious memory. Guaranteed by the (C++03) standard. And so does
std::string, in practice, but that won't be guaranteed until C++0x.

I'm talking about contiguous allocation of multidimensional vectors.

[Victor Bazarov]

nw wrote:

>Not sure what you're talking about here, but std::vector does
allocate contigious memory. Guaranteed by the (C++03) standard.
And so does std::string, in practice, but that won't be guaranteed
until C++0x.

I'm talking about contiguous allocation of multidimensional vectors.

There is no such thing. There can be a vector of vectors, but it
is not a "multidimensional vector", unfortunately. The main reason
it isn't that is the ability of all [second-tier] vectors to have
different sizes.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[nw]

>I'm talking about contiguous allocation of multidimensional vectors.

There is no such thing. There can be a vector of vectors, but it
is not a "multidimensional vector", unfortunately. The main reason
it isn't that is the ability of all [second-tier] vectors to have
different sizes.

ok, I'm talking about implementing a vectorlike multidimensional
datastructure that uses contiguous memory (see initial message for
details of the problem I'm addressing).

[Juha Nieminen]

Jim Langston wrote:

Unfortunately with my compiler my optimizations are disabled so I don't know
how it would be optimized.

You *can't* make any speed comparisons between things when compiling
without optimizations. In debug mode the speed of the code will be
completely random, depending on what debug checks the compiler chooses
to insert there.

Moreover, printing to a console makes the comparison pointless as
well, because printing to a console has an enormous overhead which
nullifies any speed difference there may be between different I/O
libraries. You have to print to a file to get a better comparison.
After all, the question was about reading (and presumably parsing)
enormous amounts of data, and outputting enormous amounts of data. These
things are never done with a console terminal as the output, but a file.
Writing to a file is quite a fast operation (probably hundreds of times
faster than printing to a console), and thus the speed difference
between the different I/O routines will have more effect.

[Ioannis Vranos]

nw wrote:

>>I'm talking about contiguous allocation of multidimensional vectors.

>There is no such thing. There can be a vector of vectors, but it
is not a "multidimensional vector", unfortunately. The main reason
it isn't that is the ability of all [second-tier] vectors to have
different sizes.

ok, I'm talking about implementing a vectorlike multidimensional
datastructure that uses contiguous memory (see initial message for
details of the problem I'm addressing).

Where computational efficiency is a primary concern, you should use
valarray and its facilities (slice_array etc).

[Ioannis Vranos]

nw wrote:

>
Firstly is it possible to create a generalizable n-dimensional matrix
using this method?

Where computational efficiency is a primary concern you should use
valarray, and use its facilities for "simulating" n-dimensional matrices.

[James Kanze]

On Feb 6, 1:49 pm, Mirek Fidler <[e-mail]:

I don't know how you got yours to run in 1 second and 8
second. On my platform it was taking too long and I reduced
the iterations. Here is a after a bunch of aaaa's...

C: 20331 C++: 23418
1.15184

This is showing the stl to be about 15% slower than the C code.

Actually, this only proves that this particular library has
both C and C++ implementations inefficient...

Or more likely, he has a very slow disk or IO bus. The more
time you spend in I/O, the less the differences in CPU make when
expressed as a percentage.

Not really related to the original question (we use Posix level
I/O for the critical parts in our application), but we've
noticed this a lot when migrating from Sparc/Solaris to
Linux/PC. Our Sparc park is old and slow---the new PC's are
often more than ten times as fast. But the Sparc I/O bus was
apparently a lot faster: our application actually runs at about
the same speed on both systems---with close to 100% use of the
CPU on the Sparcs, but less than 15% on the PC's.

My experience also suggests that SBM makes signficantly less
efficient use of the network than NFS (or maybe it is just Samba
which is a lot slower than the NFS servers), which means that
accessing a remote file under Windows will be really, really
slow. And that of course, any difference between stdio.h and
iostream will be negligeable, because even a poor and slow
implementation won't use measurable CPU compared to data
transfer times.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Feb 6, 5:02 pm, "Daniel T." <[e-mail]:

nw <[e-mail]:

[...]

For my own VectorContiguous, I guess operator[] would have to
return a dummy object which could be automatically type converted
to the storage type of the VectorContiguous object? Has this
already been done?

It sounds like if pushed I should be able to create a drop in
replacement for vector that contiguously allocates memory. Whither
this is valuable or not seems to be an open question, and probably
architecture dependent.

Having op[] return a dummy object is a poor idea, it makes it harder to
drop in different implementations. Only do something like that if you
absolutely have to. See the FAQ for more about this subject.

http://www.parashift.com/c++-faq-lit...ing.html#faq-1...

The FAQ is wrong about this. The choice between [i][j] and
(i,j) should depend on personal preference and local
conventions; both offer exactly the same possibilities for
optimization and supporting different implementations.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[nw]

Having op[] return a dummy object is a poor idea, it makes it harder to
drop in different implementations. Only do something like that if you
absolutely have to. See the FAQ for more about this subject.
http://www.parashift.com/c++-faq-lit...ing.html#faq-1...

The FAQ is wrong about this. The choice between [i][j] and
(i,j) should depend on personal preference and local
conventions; both offer exactly the same possibilities for
optimization and supporting different implementations.

My reading was that the FAQ indicates that you can use [i][j] but
tries to steer
you away from it because it will be harder to implement. I'm veering
towards a
Matrix object with a operator() but I find it unfortunate that the STL
doesn't
already provide such an object, doing so would provide a standardized
interface
which would let people create compatible Matrix objects optimized for
different
platforms, spare matrices etc.

Are there are any plans for this to be added to a future standard?

[Ioannis Vranos]

nw wrote:

>

>"The C++ Programming Language" 3rd Edition or Special Edition by Bjarne
Stroustrup (the creator of C++), Chapter 22 "Numerics" (on page 657).

<readsok.. I see. So the message here is encapsulate a valarray in a
Matrix object and use the slice operations to access it. The advantage
to using valarray over vector here is that that it provides slice
operations, I don't need to implement my own? Or are there other
efficiency gains to using valarray?

I can't see a huge advantage to encapsulating a valarray to a vector
here.

I haven't used valarray in practice myself, however valarray can be
aggressively optimised so if you have serious run-time concerns you
should use valarray with slice or gslice or whatever other valarray
auxiliary type fits better.

If you have not serious run-time concerns but the usual ones, you may
use the usual vector<vector<whatever combinations and have your job done.

[nw]

I haven't used valarray in practice myself, however valarray can be

aggressively optimised so if you have serious run-time concerns you
should use valarray with slice or gslice or whatever other valarray
auxiliary type fits better.

What is it about valarray that allows it to be aggressively optimised?
Is it because it has a fixed size? So that a compiler could choose to
store it in a small but fast region of memory and be sure that it
would be necessary to grow the array?

I'm trying to understand why I need this data structure, as others
have noted it's usually not well optimised and doesn't seem to have
been developed very well in the standard.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-02-07 12:26, nw wrote:

Having op[] return a dummy object is a poor idea, it makes it harder to
drop in different implementations. Only do something like that if you
absolutely have to. See the FAQ for more about this subject.
http://www.parashift.com/c++-faq-lit...ing.html#faq-1...

The FAQ is wrong about this. The choice between [i][j] and
(i,j) should depend on personal preference and local
conventions; both offer exactly the same possibilities for
optimization and supporting different implementations.

My reading was that the FAQ indicates that you can use [i][j] but
tries to steer
you away from it because it will be harder to implement. I'm veering
towards a
Matrix object with a operator() but I find it unfortunate that the STL
doesn't
already provide such an object, doing so would provide a standardized
interface
which would let people create compatible Matrix objects optimized for
different
platforms, spare matrices etc.

Are there are any plans for this to be added to a future standard?

No, (or rather probably not, I am not a member of the committee so I do
not know). It has always been the purpose of the standard library to
supply generic containers and algorithms. For specialised purposes third
part libraries are generally recommended. If you want a library you can
use to perform vector and matrix algebra there are a number of them
available, http://www.oonumerics.org/oon/ have a good list.

--
Erik Wikström

[Ioannis Vranos]

Erik Wikström wrote:

>
I am quite sure that many in the C++ committee would like to remove it,
but you are not allowed to do that in an ISO standard (at least not very
easily).

If this is the case they could deprecate it. It wasn't in C++03 and I am
not sure this will happen in "C++0x" too.

I agree that there are special-purpose, very efficient, C++ math
libraries out there, but I think we should stick with ISO C++ as much as
we can in our code.

If I had efficiency concerns and valarray didn't do the job, I would
check those 3rd party libraries of course.

[Maxx]

On My FreeBSD platform iostream takes about 3sec more than stdio to
compile a program that is approximately about 23MB big.And that lag in
speed is probably because of the large number of libraries that
iostream has within it.

[Ian Collins]

Maxx wrote:

On My FreeBSD platform iostream takes about 3sec more than stdio to
compile a program that is approximately about 23MB big.And that lag in
speed is probably because of the large number of libraries that
iostream has within it.

Who makes these compilers (iostream and stdio)?

--
Ian Collins.

[James Kanze]

On Feb 7, 12:26 pm, nw <[e-mail]:

Having op[] return a dummy object is a poor idea, it makes
it harder to drop in different implementations. Only do
something like that if you absolutely have to. See the FAQ
for more about this subject.
>http://www.parashift.com/c++-faq-lit...ing.html#faq-1....

The FAQ is wrong about this. The choice between [i][j] and
(i,j) should depend on personal preference and local
conventions; both offer exactly the same possibilities for
optimization and supporting different implementations.

My reading was that the FAQ indicates that you can use [i][j]
but tries to steer you away from it because it will be harder
to implement.

Not significantly. My reading was that it also raised
performance issues, which aren't present either.

I'm veering towards a Matrix object with a operator() but I
find it unfortunate that the STL doesn't already provide such
an object, doing so would provide a standardized interface
which would let people create compatible Matrix objects
optimized for different platforms, spare matrices etc.

Are there are any plans for this to be added to a future standard?

It's probably true that there is a need for true
multi-dimensional arrays. To date, however, I don't think that
there has been a proposal.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Feb 8, 9:07 am, Maxx <[e-mail]:

On My FreeBSD platform iostream takes about 3sec more than stdio to
compile a program that is approximately about 23MB big.And that lag in
speed is probably because of the large number of libraries that
iostream has within it.

More likely the difference is due to the fact that iostream is a
template.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[nw]

On Feb 8, 10:59 am, James Kanze <[e-mail]:

On Feb 7, 12:26 pm, nw <[e-mail]:

Having op[] return a dummy object is a poor idea, it makes
it harder to drop in different implementations. Only do
something like that if you absolutely have to. See the FAQ
for more about this subject.
http://www.parashift.com/c++-faq-lit...ing.html#faq-1...
The FAQ is wrong about this. The choice between [i][j] and
(i,j) should depend on personal preference and local
conventions; both offer exactly the same possibilities for
optimization and supporting different implementations.

My reading was that the FAQ indicates that you can use [i][j]
but tries to steer you away from it because it will be harder
to implement.

Not significantly. My reading was that it also raised
performance issues, which aren't present either.

From the FAQ: "If you have a decent compiler and if you judiciously
use inlining, the compiler should optimize away the temporary objects.
In other words, the operator[]-approach above will hopefully not be
slower than what it would have been if you had directly called
Matrix::operator()(unsigned row, unsigned col) in the first place. Of
course you could have made your life simpler and avoided most of the
above work by directly calling Matrix::operator()(unsigned row,
unsigned col) in the first place. So you might as well directly call
Matrix::operator()(unsigned row, unsigned col) in the first place."

I guess he's saying that your compiler /should/ be able to optimize
your performance issues away, but perhaps that wont always be the
case.

It's probably true that there is a need for true
multi-dimensional arrays. To date, however, I don't think that
there has been a proposal.

Seeing as there is a lot of numerical code going in to TR1, perhaps it
wouldn't be a bad idea if this was suggested for TR2? Or does anyone
have an opinion as to why this would be a bad idea?

[Hans Mull]

Ian Collins schrieb:

Maxx wrote:

>On My FreeBSD platform iostream takes about 3sec more than stdio to
compile a program that is approximately about 23MB big.And that lag in
speed is probably because of the large number of libraries that
iostream has within it.

Who makes these compilers (iostream and stdio)?

Compilers?

[Hans Mull]

Maxx schrieb:

On My FreeBSD platform iostream takes about 3sec more than stdio to
compile a program that is approximately about 23MB big.And that lag in
speed is probably because of the large number of libraries that
iostream has within it.

Some C++ functions are using dynamic memory allocation. This is not as
fast as static memory allocation.

Kind regards, Hans

[Ian Collins]

Hans Mull wrote:

Ian Collins schrieb:

>Maxx wrote:

>>On My FreeBSD platform iostream takes about 3sec more than stdio to
compile a program that is approximately about 23MB big.And that lag in
speed is probably because of the large number of libraries that
iostream has within it.

Who makes these compilers (iostream and stdio)?

Compilers?

To quote "iostream takes about 3sec more than stdio to compile a program"

Compilers compile.

--
Ian Collins.

[Juha Nieminen]

Hans Mull wrote:

Maxx schrieb:
Some C++ functions are using dynamic memory allocation. This is not as
fast as static memory allocation.

Do you actually have some reference to support this?