Compiling for pentium4?

binarybob0001 · 04-09-2006, 05:38 AM

I'm trying to figure out how to compile for the pentium4. I think I just have to type:
export CFLAGS="-march=pentium4 -O3"
I'm turning on full optimization too. How do I make sure I'm really compiling for the pentium4? Is there a test, or do I just need to compile the app and run it?

d0odman · 04-09-2006, 10:07 PM

The configure scripts, if the software package comes with them, take care of all that. There's usually no need to export a CFLAGS variable, unless the documentation of the software tells you to.

binarybob0001 · 04-09-2006, 11:57 PM

OK... how would I check what architecture the files were compiled for? The reason I ask, is because I am making packages and wish to name them properly. Not to mention, optimized code for a processor runs faster than non-optimized code. I want to be able to compile for different architectures if necessary and check what architecture I actually got.

Alien_Hominid · 04-10-2006, 12:05 AM

In Slackware packages architecture is mentioned in the packages names like i386, i686 and so on. Same tradition is often used in other package management systems like rpm.

foo_bar_foo · 04-10-2006, 12:16 AM

Quote:

Originally Posted by d0odman

The configure scripts, if the software package comes with them, take care of all that. There's usually no need to export a CFLAGS variable, unless the documentation of the software tells you to.

no this is not true the configure scripts use your CFLAGS and CXXFLAGS
or fall back on lame ass defaults.

i have done extensive benchmarking with my P4 and i use this
in my ~/.bash_profile

Code:

export CFLAGS='-march=pentium4 -O3 -funroll-loops -ftracer -momit-leaf-frame-pointer -fprefetch-loop-arrays'
export CXXFLAGS=$CFLAGS

for the rare instances when this causes runtime problems you just go back and
unset CFLAGS
unset CXXFLAGS

Electro · 04-10-2006, 12:48 AM

I recommend leaving -momit-leaf-frame-pointer out unless you like scratching your head all day figuring out what is the problem. By leaving out -momit-leaf-frame-pointer you get descriptive debug messages that you can use to fix your setup. Also -O3 can break some programs. I suggest using- O2 as the highest optimize value because it minimize unusual problems.

A Pentium 4 is an 80786 or i786, so a 80686 will not be able to run the program.

binarybob0001 · 04-10-2006, 01:11 AM

Thanks guys, this is getting much better. Well, I don't know how to debug yet, so I don't see how an error message would help me. I have done a lot of C++ in Windows but the projects I have seen for linux are so big, so complex that I have a time finding the starting point. I would love to learn to program in X or KDE. I know the difference between the two, but I don't know if there is a difference when you program in X versus programming in KDE. I can't find any documents for the strict C API of either really. I found some for X but KDE nothing.

Well, do you guys know of a way to test if the program was really compiled in 786 or not?

d0odman · 04-10-2006, 01:54 AM

Quote:

Originally Posted by foo_bar_foo

no this is not true the configure scripts use your CFLAGS and CXXFLAGS
or fall back on lame ass defaults.

What I was trying to point out, was that it's optional to set both of these variables. A lot of the time, mere mortal users don't need to fool with these for a run of the mill compilation (lame ass defaults, as you say), unless they're doing something according to some howto they've seen somewhere or something.

Electro · 04-10-2006, 08:03 PM

Quote:

Originally Posted by binarybob0001

Thanks guys, this is getting much better. Well, I don't know how to debug yet, so I don't see how an error message would help me. I have done a lot of C++ in Windows but the projects I have seen for linux are so big, so complex that I have a time finding the starting point. I would love to learn to program in X or KDE. I know the difference between the two, but I don't know if there is a difference when you program in X versus programming in KDE. I can't find any documents for the strict C API of either really. I found some for X but KDE nothing.

Well, do you guys know of a way to test if the program was really compiled in 786 or not?

Read my previous post. An 80686 or lower will not run an 80786 program.

Configuring and compiling KDE programs takes different steps than compiling GTK or wxWidget programs. KDE programs use qmake (I think). I do not recommend making any KDE programs because it is way too bloated. Write either GTK or wxWidget programs.

You can try use Eclipse to help you oragnize a big program.

binarybob0001 · 04-11-2006, 12:18 AM

Oh, I read your previous post, but I was hoping to test it without the need for an 80686 process. I don't have one test it on.

Thanks a lot, you have given me some excellent tips.

foo_bar_foo · 04-11-2006, 01:13 AM

Quote:

Originally Posted by Electro

Read my previous post. An 80686 or lower will not run an 80786 program.
I recommend leaving -momit-leaf-frame-pointer out unless you like scratching your head all day figuring out what is the problem.
Also -O3 can break some programs.

twilight zone again in LQ land (this has been the norm lately -- quite a shame really)
thus onward to the rebuttal in the reality matters wars.

why would we want to run code compiled for other than exactly the cpus we have ?
a processor feature is a terrible thing to waste.
next P4 is a class 80686 -- Itanium 64 bit is the first intell 80786 class processor
next from gcc docs

Quote:

-momit-leaf-frame-pointer
Don't keep the frame pointer in a register for leaf functions. This avoids the instructions to save, set up and restore frame pointers and makes an extra register available in leaf functions.
-fomit-frame-pointer
removes the frame pointer for all functions which might make debugging harder.

why people make assertions here about this kind of stuff when they don't know what they are talking about i will never understand.
yea my optimization flags broke at most 3 packages on my entire system which took all of 10 minutes to correct.
check out this extreem case of math overhead improvement
with -O2
Arithmetic Test (type = arithoh) 13439624.3 lps (10 secs, 6 samples)
with the flags i put earlier
Arithmetic Test (type = arithoh) 182031243.1 lps (10 secs, 6 samples)
thats over 1000% faster !
isn't that worth 10 minutes effort ?
can you make enough money in 10 minutes to buy a cpu thats 1000% faster than the one you have now ?
anyway i also really like Qt/KDE as a programming environment.
KDE might seem bloated however if you use an instruction set from 1983.
people often talk of wasting unused RAM. how about wasting unused cpu features.

here are the KDE docs

http://developer.kde.org/documentation/library/

daihard · 04-11-2006, 02:52 AM

Quote:

Originally Posted by Electro

Configuring and compiling KDE programs takes different steps than compiling GTK or wxWidget programs. KDE programs use qmake (I think). I do not recommend making any KDE programs because it is way too bloated. Write either GTK or wxWidget programs.

"qmake" is one of the tools that come with Qt, the toolkit KDE is based upon. Running "qmake" will generate all the necessary project files and makefiles for your source files depending upon the platform. Qt is a multi-platform SDK, which means you can maintain a single source tree and create GUI applications for multiple platforms; i.e. Windows, Linux, UNIX and Mac OS X.

I don't know much about GTK, but I have written code for both Qt and wxWidget (and I still work with Qt). If you ask me, Qt is much cleaner and easier to work with. It is my opinion that Qt is very well designed. You can write either "barebone" Qt apps or KDE apps using Qt. KDE apps use KDE-specific components and therefore require the base KDE components to be installed; Qt apps only require the Qt library and is therefore much more lightweight.

Electro · 04-11-2006, 03:09 AM

Quote:

Originally Posted by foo_bar_foo

twilight zone again in LQ land (this has been the norm lately -- quite a shame really)
thus onward to the rebuttal in the reality matters wars.

why would we want to run code compiled for other than exactly the cpus we have ?
a processor feature is a terrible thing to waste.
next P4 is a class 80686 -- Itanium 64 bit is the first intell 80786 class processor
next from gcc docs

why people make assertions here about this kind of stuff when they don't know what they are talking about i will never understand.
yea my optimization flags broke at most 3 packages on my entire system which took all of 10 minutes to correct.
check out this extreem case of math overhead improvement
with -O2
Arithmetic Test (type = arithoh) 13439624.3 lps (10 secs, 6 samples)
with the flags i put earlier
Arithmetic Test (type = arithoh) 182031243.1 lps (10 secs, 6 samples)
thats over 1000% faster !
isn't that worth 10 minutes effort ?
can you make enough money in 10 minutes to buy a cpu thats 1000% faster than the one you have now ?
anyway i also really like Qt/KDE as a programming environment.
KDE might seem bloated however if you use an instruction set from 1983.
people often talk of wasting unused RAM. how about wasting unused cpu features.

here are the KDE docs

http://developer.kde.org/documentation/library/

You are wrong that Pentium 4 are 80686. They are 80786. Go to http://en.wikipedia.org/wiki/80786

A smart programmer will revise his or her program to make it 10,000 times faster and still be able to use -O2. You can use -O3 but you will not be able to post reliable bug reports. I am going to use -O2 because I want to post bug reports and have a reliable setup.

What I mean KDE is bloated is because it loads too much junk that is not needed. It is like loading MS Office's DLL files even though I'm not going to use Word, Exel, Powerpoint, Access today. The DLL files are taking up CPU resources. wxWidgets and GTK are much better for GUI applications because they are several times quicker than KDE programs because they use less processor resources.

I do not know what you are talking about KDE uses features from the processor. That is load of bull.

daihard · 04-11-2006, 03:34 AM

Quote:

Originally Posted by Electro

What I mean KDE is bloated is because it loads too much junk that is not needed. It is like loading MS Office's DLL files even though I'm not going to use Word, Exel, Powerpoint, Access today. The DLL files are taking up CPU resources. wxWidgets and GTK are much better for GUI applications because they are several times quicker than KDE programs because they use less processor resources.

Like I said above, wxWidgets is much harder to learn and use than Qt. To me, it is very important to provide a programming environment that is easy to learn and use - that will in turn reduce the number of bugs introduced. The only library (or "DLL") required by Qt is libqt-mt.so (or qt-mtxxx.dll for Windows, where xxx is the version number). If you do feel that KDE apps are bloated, try Qt without using the KDE-specific features.

Alien_Hominid · 04-11-2006, 04:19 AM

Quote:

Originally Posted by foo_bar_foo

Itanium 64 bit is the first intell 80786 class processor

As I know Itanium is IA=64 and does not belong to x86 architecture.

EDIT: But it's strange that even I have Pentium 4 Prescott uname still shows i686 (pentium 4 support is compiled into the kernel).