how to increase speed in c++

Quote:

---

Originally posted by AnthonyMai
<snip>
I encourage people to look into the source code of STL and judge by themselves whether they want to use piece of code like that, or they are allowed to write code in that kind of style, after they have seen the STL source code for themselves. Lack of knowledge of STL internals is the most frequent cause of mis-use of STL by programmers.

---

Yes, it certainly would be a great gain for every C++ programmer to fully understand the way STL is implemented and works. Looking into the implementation of STL can teach you many things, but is a complicated task. I took a few hours to roam thru the source code of STLPort and the main achievement of that was realizing the fact that I'd need to spend much more time in order to get a grip on the implementation.

If reading and understanding the STL source code would be a demand prior beginning to use STL, many programmers, especially the beginners, would never come to actually use STL, being frightened away by the complexity of its implementation.

Also, we should think about the concept of separating the interface of a class (library) from its implementation. I'm not referring to the code organization here, but to the concept itself. I think you can use STL at a decent level by understanding only its interface and documentation (widely speaking: books, examples, articles). I think that the lack of understanding the interface and the concepts of STL is "the most frequent cause of mis-use of STL by programmers".

I have been writing C/C++ for over 30 years and I don't like STL at all because of its complexity -- I just don't understand it! I have used vector and string on rare occasions, but other than that I stay clear of all STL. I know STL is an attempt to make type-safe classes -- but why should I put myself through all that pain when non-STL classes and structures will do the job just as well -- and with a lot less effort on my part? I don't write code or libraries for other people to use, so the type-safe concept is usless to me.

In contrast to that, I've been using STL in earnest for a couple of years now, and on those occasions when I can't use it (leagcy code that would break), I find myself yearning for its simplicity.

Quote:

---

Originally posted by Graham
In contrast to that, I've been using STL in earnest for a couple of years now, and on those occasions when I can't use it (leagcy code that would break), I find myself yearning for its simplicity.

---

Just the algorithms alone are worth it. And as far as it being too difficult, all it takes is to read example programs. If you can use vector or string, it's not much more in using a list or a deque.

If you want complexity, try "Modern C++ Design" by Andrei Alexandrescu.

Regards,

Paul McKenzie

Quote:

---

Originally posted by Paul McKenzie
If you want complexity, try "Modern C++ Design" by Andrei Alexandrescu.

Regards,

Paul McKenzie

---

Now that did blow my mind! (Good fun, though.)

If all one wants is to produce some code that works correctly at all, STL would be a good and simple solution, and one doesn't need to look at the terrifying internal of STL. All you need is STL documentation and STL books. I guess that's what Paul et al has been promoting all the time. It is easier to produce correct code using STL as long as you comply witht he standard. I have no dispute of that.

In real life, code correct is far from good enough. A programmer who is satified with merely writting code that produce correct result is an unqualified programmer in today's IT job market. And, surprise, programmers ARE allowed to produce incorrect code now and then, as long as you know how to detect and fix bugs.

A piece of sorting code that produce the corret result maybe totally useless, if it takes days or weeks to sort something that could have been sorted in seconds.

To produce code that is more than merely correct, it is inevitable that one needs to know the internal of STL. Because, unfortunately the most performance rellevant piece of code are those inner loops and implementation detals. STL bites you really bad in performance if you do not know how it works underneath.

skulkarni,

Implementations of LISP and FORTRAN77 use call-by-reference in order to pass input parameters to subroutines. A direct translation into C++ must be more carefully undertaken since your routines have large object-type input parameters.

This topic was discussed by Paul McKenzie. You must familiarize yourself with the calling-convention of C/C++, which used call-by-value unless otherwise specified by using an object reference or memory pointer.

Do not reject the STL on the basis of speed. In addition, if you are serious about writing speed-optimized programs, then try to familiarize yourself with the STL-implementation at hand. Reading the source-headers can be quite cumbersome. Sometimes an empirical analysis (code-profiling) can be of great insight if you find yourself repeatedly using various parts of the STL.

Regards, Chris.

:)

skulkarni is passing an object by value. Before STL came along, competent C++ programmers know that passing objects by value will cause temporary objects to be created. Joe Blow's brand-x class can have penalties if passed by value. This has absolutely nothing to do with the speed of STL, but the implementation of proper C++ coding when it comes to passing parameters.

Regards,

Paul McKenzie

Quote:

---

Before STL came along, competent C++ programmers know that passing objects by value will cause temporary objects to be created

---

That is absolutely right. However the fact is for some reason the author of STL decided to pass objects by value (especially it is UNKNOWN objects, since we are talking about templates) around every where within the STL, causing temporary objects to be created every where.

The point is the user of STL really don't have a choice when passing parameter to STL functions. Take std::sort() for example, the third parameter is a function object passed in by value.

You can't change that. You can't pass it in by reference when the template function tells you to pass object in by value. The only thing you can change is try to make your object as simple as possible. And when you fail to do that, Just like Paul's original "index sorting using std::sort()" sample code. The performance becomes so poor that a few seconds of sorting now takes days or weeks.

Quote:

---

Originally posted by AnthonyMai


That is absolutely right. However the fact is for some reason the author of STL decided to pass objects by value (especially it is UNKNOWN objects, since we are talking about templates) around every where within the STL, causing temporary objects to be created every where...

---

Umm...What does this have to do with the OP problem?

Regards,

Paul McKenzie

The original post showed a clear mystery about run-time characteristics. Several thread-elements later the sample codes containing the translated algorithms were provided. It is clear from the posted codes that the subroutines force the compiler to pass large objects by value. Here one is talking about objects in memory which are bigger than the size of a few CPU-registers.

Paul has described what the compiler must do in order to achieve this: The compiler will create new objects (the vectors) for the subroutine call, dilligently copy the original passed vector into the newly created vector and feed the new one into the subroutine.

skulkarni:
The run-time characteristics of the translated algorithm are probably governed by the creation and copying of temporary objects passed to and possibly returned from subroutines.

There is no STL-issue here.

Redesign the C++ algorithms and make proper use of C++ references.

Sincerely,
Chris

:)

Optimize ur C linker,
and use inline ASM ;) ( _asm{} / asm{} )
:D

What compiler and optimization level are you using ?

For example, with the version of g++ that I am using, the
default optimization level is "-O0". In some cases
compiling at "-O2" increased the speed by a factor of 10.