C/C++ speed optimization bible/resources/pointers needed!

#31 07-27-2007, 07:38 AM

<jimp@specsol.spam.sux.com> wrote in message
news

79on4-6ta.ln1@mail.specsol.com...
> In sci.physics Luna Moon <lunamoonmoon@gmail.com> wrote:
>
>> <jimp@specsol.spam.sux.com> wrote in message
>> news:2fhnn4-oq7.ln1@mail.specsol.com...
>> > In sci.physics lunamoonmoon@gmail.com wrote:
>> >> C/C++ speed optimization bible/resources/pointers needed!
>> >
>> >> Hi all,
>> >
>> >> I am in the middle of programming to solve an engineering problem
>> >> where the speed is huge concern. The project involving lots of
>> >> numerical integration and then there are several loops/levels of
>> >> optimization on top of the function evaluation engine. As you probably
>> >> know, the key to a successful optimization is a fast underlying
>> >> objective function evaluator. The faster it is, the more promising the
>> >> optimization result(perhaps global optimal). However our project
>> >> requires many numerical integrations which prohibits us from making it
>> >> super fast. At the heart of the numerical integration is a smart
>> >> integrator and a super-fast integrand function evaluator. Even worse,
>> >> our function evaluation is in complex-domain. So the kay point is how
>> >> to arrange our C/C++ code to make it highly efficient in every aspect.
>> >> Could anybody give some advice/pointers on how to improve the speed of
>> >> C/C++ program? How to arrange code? How to make it highly efficient
>> >> and super fast? What options do I have if I don't have luxury to use
>> >> multi-threaded, multi-core or distributed computing? But I do have a
>> >> P4 at least. Please recommend some good bibles and resources! Thank
>> >> you!
>> >
>> > If the problem is ameniable to being multi-threaded, you are dismissing
>> > what would probably be the easiest to implement and biggest speed
>> > improvement.
>> >
>> > Multi-processor Linux boxes aren't all that expensive, expecially
>> > when you start looking at labor cost to hand optimize.
>> >
>> > --
>> > Jim Pennino
>> >
>> > Remove .spam.sux to reply.
>
>> Thanks! But I cannot ask our head to give me a linux box. I am confined
>> within what I have now. I have to do whatever I can and use whatever I
>> have
>> from my part only. Let's focus on what I can do, coding good C++ code.
>> Thanks!
>
> If you have the box, all you need to do is install Linux on it.
>
> Linux is a free download.
>
> You aren't actually going to use Windows are you?
>

As I said, I am confined to what I have. Let's focus on coding good C++...

#32 07-27-2007, 07:41 AM

"Hendrik van der Heijden" <hvdh@gmx.de> wrote in message
news:46a99140$0$31634$9b4e6d93@newsspool3.arcor-online.net...
> galathaea schrieb:
>
>> you have to run benchmarks and profile code execution paths
>> but just choosing the right compiler has increased code
> > speed 40% in tight loops for me in the past
>
> I've seen a 500% boost just from adding a compiler option (-mfpmath).
> With this option, gcc uses SSE1/2 units for floating point calculations
> (SISD, not vector code) instead of traditional x87 code.
>
>
> Hendrik vdH

Great! This is exactly what I want... Thanks so much I will try it out!
Which complier?

We have done everything at the algorithm level, now we just want to make
sure our data structure, caches, and code organization don't do stupid
things to slow down and we try various tricks to squeeze up speed further.

Any more pointers? Hopefully there are some books/articles/resource
somewhere on this planet talking about highly efficient C++ code and
complier, etc.

#33 07-27-2007, 07:42 AM

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:L-ednfeo_NWOFTTbnZ2dnUVZ_rGrnZ2d@comcast.com...
> jimp@specsol.spam.sux.com wrote:
>
> (snip)
>
>> Sigh, Linux is free; all you have to do is download and install it.
>
>> Linux will be a LOT faster than Windows when doing number crunching.
>
> There is no reason Linux should be faster, in general, for number
> crunching. The numeric instructions take the same number of cycles
> independent of the OS. For speedy number crunching one should minimize
> the amount of paging, which could be OS dependent, as could I/O.
>
> If one is doing a lot of paging or I/O, then I would say that one
> is not doing number crunching. (That is, the task is I/O limited
> and not CPU limited.)
>

I also need a large memory, because to improve speed, I have already
transform many calculations into table-loopup and storage... Any more
thoughts?

#34 07-27-2007, 07:43 AM

"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
news:87vec62tst.fsf@nonospaz.fatphil.org...
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> jimp@specsol.spam.sux.com wrote:
>>
>> (snip)
>>
>> > Sigh, Linux is free; all you have to do is download and install it.
>>
>> > Linux will be a LOT faster than Windows when doing number crunching.
>>
>> There is no reason Linux should be faster, in general, for number
>> crunching.
>
> When I compiled, using the same level of gcc, my number crunching code
> (OversEis, for finding prime numbers) for Opteron, using nothing
> but the i386 registers and the FPU, no MMX/SSE/whatever, the code
> running on linux was 30% faster than the code running on windows.
> (250s per test vs. 330s per test) Also, in windows, running 1 such
> program was slower than running 2 in parallel (330s for 2 tests,
> vs. 480s for 1 test - linux was 250s for 2 tests, 250s for 1 test).
>
> Something ain't right in the state of 64-bit windows.
>
> Phil

Why didn't you use MMX/SSE/whatever?

#35 07-27-2007, 07:47 AM

srp@microtec.net wrote:

> Short of going to straight assembly language, nothing is faster.

Many C compilers easily beat most asm code in my experience
what happens is asm programmers tend to use subsets of the
instruction set and rarely do complete a re-implimentation of the
application with each change the way compilers do with each
compile.

Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

#36 07-27-2007, 08:15 AM

On 26 juil, 23:46, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> s...@microtec.net wrote:
> > On 26 juil, 17:19, lunamoonm...@gmail.com wrote:
> ...
> > Your best bet with C/C++ is to get a fast computer. Optimization
> > is only nominal with these compilers.
>
> "nominal"? It's critical.
>
> I have no idea what you're alluding to but if you're trying to say that
> the optimizer is not one of the critical parts of a C++ compiler when it
> comes to performance, you're very mistaken.

Of course, optimized C++ is way better than non optimized C.

But in order of code optimization, from worst to best, you have C++,
straight C, and Forth as best by far. C is simply no match for any
flavor of Forth for low level code optimization.

Simple fact of life.

André Michaud

#37 07-27-2007, 08:18 AM

On 27 juil, 07:47, Walter Banks <wal...@bytecraft.com> wrote:
> s...@microtec.net wrote:
> > Short of going to straight assembly language, nothing is faster.
>
> Many C compilers easily beat most asm code in my experience
> what happens is asm programmers tend to use subsets of the
> instruction set and rarely do complete a re-implimentation of the
> application with each change the way compilers do with each
> compile.
>
> Walter Banks
> --
> Byte Craft Limited
> Tel. (519) 888-6911
> http://www.bytecraft.com
> wal...@bytecraft.com

True. That's the problem with macros, which is unfortunate since
the possibility of doing efficient code is there all the same.

André Michaud

#38 07-27-2007, 08:20 AM

On 26 juil, 23:57, "Luna Moon" <lunamoonm...@gmail.com> wrote:
> <s...@microtec.net> wrote in message
>
> news:1185490398.938753.40390@g4g2000hsf.googlegrou ps.com...
> On 26 juil, 17:19, lunamoonm...@gmail.com wrote:
>
>
>
> > C/C++ speed optimization bible/resources/pointers needed!
>
> > Hi all,
>
> > I am in the middle of programming to solve an engineering problem
> > where the speed is huge concern. The project involving lots of
> > numerical integration and then there are several loops/levels of
> > optimization on top of the function evaluation engine. As you probably
> > know, the key to a successful optimization is a fast underlying
> > objective function evaluator. The faster it is, the more promising the
> > optimization result(perhaps global optimal). However our project
> > requires many numerical integrations which prohibits us from making it
> > super fast. At the heart of the numerical integration is a smart
> > integrator and a super-fast integrand function evaluator. Even worse,
> > our function evaluation is in complex-domain. So the kay point is how
> > to arrange our C/C++ code to make it highly efficient in every aspect.
> > Could anybody give some advice/pointers on how to improve the speed of
> > C/C++ program? How to arrange code? How to make it highly efficient
> > and super fast? What options do I have if I don't have luxury to use
> > multi-threaded, multi-core or distributed computing? But I do have a
> > P4 at least. Please recommend some good bibles and resources! Thank
> > you!
>
> Your best bet with C/C++ is to get a fast computer. Optimization
> is only nominal with these compilers.
>
> If you have the option, the fastest language all around, due to
> structurally built in low level code optimization would be get
> a Forth language interpreter/compiler.
>
> Short of going to straight assembly language, nothing is faster.
>
> André Michaud
>
> ---------------
>
> thanks! It's good to know Forth is the fastest.
>
> But I cannot ask our head to let me switch to Forth. I am confined within
> what I have now. I have to do whatever I can and use whatever I have frommy
> part only.

Unfortunate. Then suggestions made by others will no doubt
be of more help.

André Michaud

#39 07-27-2007, 09:21 AM

Walter Banks <walter@bytecraft.com> writes:

> srp@microtec.net wrote:
>
>> Short of going to straight assembly language, nothing is faster.
>
> Many C compilers easily beat most asm code in my experience
> what happens is asm programmers tend to use subsets of the
> instruction set and rarely do complete a re-implimentation of the
> application with each change the way compilers do with each
> compile.

I normally see a factor of two speedup in hand-coded assembly
over C and it's not uncommon to get a factor of 5.
--
% Randy Yates % "How's life on earth?
%% Fuquay-Varina, NC % ... What is it worth?"
%%% 919-577-9882 % 'Mission (A World Record)',
%%%% <yates@ieee.org> % *A New World Record*, ELO
http://home.earthlink.net/~yatescr

#40 07-27-2007, 09:35 AM

Hi,
have a look to

http://www.agner.org/optimize

Cu
Josef

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode