|
From: Philip Potter on 4 Jan 2008 04:42 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 4 Jan 2008 05:29 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 4 Jan 2008 05:51 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 4 Jan 2008 09:06 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 4 Jan 2008 12:48 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.
First
|
Prev
|
Pages: 1 2 Prev: edit c-string passed as a parameter Next: Colored bitmaps in Visual C++ |