From: Philip Potter on
Timmy wrote:
> On Thu, 03 Jan 2008 23:45:35 -0500
> "Daniel T." <daniel_t(a)earthlink.net> wrote:
>> [snip]
> So if I were to ask why g++ isn't compiling this program with
> funroll-loops you could give me the answer
>
> ==========
> #include <iostream>
> using namespace std;
>
> int main()
>
> {
>
>
> std::cout << "Daniel Is No Help!\n";
> return 0;
>
> }
>
> ===============
>
> Can ya point out the error in that program? :-)

I see two errors:
1) The program insults the person whom you are asking for help. This
rarely helps to get things working.
2) You don't say what the problem is. "isn't compiling" isn't enough
information.

Phil
From: Francis Glassborow on
Timmy wrote:

> There in lies the problem; Those "In The Know" Say you shouldn't step
> outside the norm, the norm being CFLAGS -O2 -pipe. Yet 80% of the
> programs running on this system/FreeBSD have been built with -O3 and
> work perfectly. Btw, those at the GCC list don't want to hear about
> any errors you may encounter if you step OUTSIDE OF THERE NORM. For
> the most part I know what CFLAGS I can get by with on source operating
> systems/programs.
>
> My question was. Will x86 run faster on a smaller code base than it
> will on a larger optimised code base? I know what you're thinking
> "Benchmark it & and see" Do you know how long it takes to build and
> install these operating systems from source? That's why I thought I
> would ask master programmers who write this code their opinion before I
> spend all day building an o/s from source. For all I know the woman was
> yanking my chain.

This rather OT but my understanding is that the real place to look for
optimisations in OSs is code that runs unnecessarily or unnecessarily
often. I believe that there is quite a bit of this in Linux code.


--
Note that robinton.demon.co.uk addresses are no longer valid.
From: Francis Glassborow on
Ulrich Eckhardt wrote:

> Now, what does that mean for the speed? The speed is limited by both the
> pipeline and the memory bandwidth. If one is used completely, the other
> might still be partially idle. You can now try to tweak that behaviour by
> reducing the amount of stress on one of the two. E.g. unrolling loops will
> reduce the number of branches (easier work for the pipeline) but increase
> the amount of instructions (more work for the memory bus). Using
> size-optimised code will reduce the load for the memory bus but increase
> the work for the pipeline.

Furthermore unrolling a loop can result in code that no longer resides
completely in top level cache which can adversely effect performance.
OTOH, assuming that your system is multi-tasking, cache may be being
repeatedly reloaded anyway.

The upshot is still that considering the overall activity of the OS and
which processes are active all the time etc. is far more important than
most micro-optimisations. Worse, the ultimate speed freak OS today can
be the traffic jam of tomorrow.


>
> So, whether something is faster or not actually depends both on the CPU and
> on the actual task.
>

Exactly.
From: Daniel T. on
Timmy <Timmy15(a)Spamnot.com> wrote:
> "Daniel T." <daniel_t(a)earthlink.net> wrote:
>
> > You are not asking the master programmers who wrote that code by
> > posting in this group. If you asked in the FreeBSD & LFS Linux groups
> > and they all said "don't try it" then I suggest you take their
> > advice, unless you are a master programmer who knows the code (which
> > if you were, you wouldn't be asking the question.)
>
> So if I were to ask why g++ isn't compiling this program with
> funroll-loops you could give me the answer

If there is a problem in the c++ code, then this is an appropriate place
to ask. If there is a problem with how you are using g++, it isn't.

I'm simply trying to tell you that this is not the place to ask your
question. Yours isn't a question about how to program using the c or c++
language, it is a question about how to work with particular program.
From: Ben Cottrell on
Timmy wrote:

> Ram is cheap: 99.99% of programs don't take advantage random allocation
> space, well, it would seem windows Vista did. <rolls eyes>

I would disagree with this comment. Maybe memory seems cheap to you,
and maybe it is relatively cheap for a Desktop PC compared to X years
ago, but those 99.99% of programs certainly do not all run on desktop
PC's, or even anything which even removely resembles a desktop PC.
There are many types of embedded systems where even requesting a few
extra KB to be added is non-viable due to the extra per-unit cost of the
end product. You can bet anything that a program running on such a
system will take advantage of every last available byte, because if it
didn't, management would want to know why they've wasted money on extra
unused memory.