C++ : how to speed things up ?

[doc_bean]

Okay, so i've got a c++ program that does what I need, problem is, it's a little slow. Can anyone give me any pointers as to which operations cost a lot of time and which can be done rather fast ? I have to use a lot of loops (since i'm doing matrix algebra/operations and c++ doesn't allow me to extract a column from a matrix or anything like that without making a nice little loop, or declaring all the elements myself, afaik). I removed all my vector/matrix resizing, but apparently that isn't making much of a difference (well, might be a few seconds...)

So does anyone have any suggestions ?

[caravel]

Okay, so i've got a c++ program that does what I need, problem is, it's a little slow. Can anyone give me any pointers as to which operations cost a lot of time and which can be done rather fast ? I have to use a lot of loops (since i'm doing matrix algebra/operations and c++ doesn't allow me to extract a column from a matrix or anything like that without making a nice little loop, or declaring all the elements myself, afaik). I removed all my vector/matrix resizing, but apparently that isn't making much of a difference (well, might be a few seconds...)

So does anyone have any suggestions ?
Well I'm out of my depth here, as it's about 10 years since I've done any programming, but I do remember that using pointer arithmetic in C/C++ makes for faster code execution than array indexing.

[MikeV]

It's almost impossible to give an accurate answer without any specifics. :wall:


using pointer arithmetic in C/C++ makes for faster code execution than array indexing.

Actually, in C/C++, array indexing and pointer arithmetic end up being about the same speed (sometimes, the compiler will convert one to the other).

The best suggestion for tuning any code, in any language, is to profile the program and find out where the hot spot really is -- then focus your tuning efforts on that code. Lather, rinse, repeat. :laugh4:

[doc_bean]

I'd give more details, but then I'd wind up in unofficial NDA territory, which wouldn't be good.

I know one function gets called up about 20 000 times and another nearly 100 000 times, I should probably focus on those :laugh4:

Anyone know how you can you profile your code using cmake ?

[Blodrast]

Never used cmake, but a quick glance suggests it's a cross-platform make utility, rather than a profiler.
Are you running on a linux or a windows box ? On *nix systems, you can use, for example, gprof. On both *nix and windows, you can use, for instance, Intel's profilers (they have a compiler suite both for windoze and for linux).

I'm sure all systems would offer other tools, but I don't even know what platform you're using.

As for the question at hand: as it's already been said, your question is waaaay too generic.
At the very least, you have to show some code, or at least explain in detail not what the code is doing, necessarily, but how it's doing it.
Otherwise, it's well nigh impossible to get any help.
If people had an answer to the question "How can I speed up any generic code that I have no information on ?", we'd be far more advanced ~;)

However, there are a few generic things:

1. Turn on optimizations in your compiler - as aggressive as possible. For gcc and intel compilers, this is -O3/-O4/5 (depending on versions, etc). (that's an "oh", not a "zero").

2. I am assuming your arrays are multidimensional. How are they declared ? If you can declare them statically, that'd be great - it will allow the compiler to compute offsets for the array elements much more efficiently. While declaring them statically might waste a bit of memory (if you make them just larger than you need), it might gain you some time improvement.

3. You said you have functions that are called a significant number of times. Are those functions large (code-wise) ? Make sure they are inlined. Inlining makes a big difference.
Aggressive compiler optimizations should take care of that, but depending on how they are written, the compiler may or may not inline them.
You can verify if they're inlined by looking at the assembly code.

If you can, change them such that they can be inlined. One thing that may prevent inlining, for example, is functions that are called from within those functions - especially if those called functions are in a different source file.

-----------

Again, without more details...

Another thing - if, for whatever reason, you can't/don't want to use a profiler, you can just measure the execution time spent in the various methods yourself.
Just take a time measurement before the function is called, and another one after - and add them all up. That'll tell you how much time is spent, overall, in each function, which is what you need.