Not generally - otherwise I couldn't use the same
checkinstall-generated tgz on all my machines. Or
at least it appears silly to have the slowest box do
all the hard work.

Normally I will leave defaults turned on, a few packages
(like mplayer) will try to detect the cpu anyway, and
for the "time-critical" ones I do use the proper flags (note
on the side: encoding a DVD to DivX5 with a non-optimized
version of transcode took about 40 seconds longer than
with an optimized one - which doesn't do a lot for me
considering that the process took well over 4 hours) ;D

Or, to re-iterate what has been said several times:
CPU/Architecture optimization doesn't gain you THAT
much benefit.


Cheers,
Tink

c'mon tinkster, no need to put people down cause they have a different opinion..

anyway, just for the record, i use athlon-xp specific flags cause i have only one machine running linux and will not be using checkinstall generated packages on any other machine..

Well ... I find that approach (arguing to raise the limit
just because you happen to have a specific CPU)
rather selfish and egotistic ... and a bit of sarcasm doesn't
hurt :)


Cheers,
Tink

opening this one after a long time...but ive just tried two i686 distro's namely mepis and arch, and theyre both much faster that slack..im sticking with arch..mepis was slightly unstable for me..but pacman rules!

Personally, I think i486 is fine. Going higher than that, IMO, is a mistake, as it would be offensive to the Slackware`s philosophy and some of its loyal users, and as [believe it or not] there`s a lot of older systems running around, which offer a high potential of expansion to Linux, and therefore, Slackware.

By the way, about the rich-part-of-the-world comment, and I don`t mean to be rude or start any kind of debate, well, it`s really ... inaccurate.

Anything higher than 586 would be a great mistake. It has been a long time since I've used a 486 (or seen one) but I'm sure they are in use by someone. Pentiums have been around for a long time and surely dominate in the *old* category of computer.

686 would be a huge mistake but 486 works for everyone.

well...then looking at it in that way...switching from i386 to i486 would have offended a whole bunch of loyal slackware users with older machines..im curious..was there a problem with that switch?(slack 9.1 was i386, i think)

Well, for example, I have an old laptop I use for a media computer. It has a pentium processor.

What I am saying is that a switch to 686 would make slack impossible to use on this type of machine, which is old and not one of my work computers, but not garbage.

Just because you aren't using a computer for you daily workstation doesn't mean that you have no use for it anymore.

from an IRC log file: http://ximpul.ath.cx/log.txt

I don't know about you, but i trust this guy.
You propably forgot the mcpu flag....

Recent gcc's require it - *it* doesn't work with 386s, IIRC. So the 386-486 jump was basically out of Pat's hands. As far as 486's I was playing around with one until it died a few months ago. It really doesn't make much sense to exclude 486s just to 'optimize' for 586s. Cost vs. payoff is minimal.

Anyway - while I compile specifically for my machine in most cases, I agree that Slack is a complete general-purpose distro and should work as widely as possible.

And I have Arch on here too and it didn't occur to me it's any faster than Slack. (Not saying it is or isn't but it's definitely nothing that hits you with a 2x4.) Arch also has somewhat quicker startup scripts (which I *did* notice - but they also don't do as much or as carefully as Slack, I don't think) and uses a different kernel patch set, neither of which have anything to do with -march/-mtune and both of which probably make more apparent difference.

im not really talking about the boot scripts...but the desktop and gtk/firefox feels so much
more responsive....i only wish slack was like this..

well...i think your Slackware setup is not optimal.
mayby there are a lot of services running in background that you don't need.

but if you want to make sure, you are free to compile xorg, your wm/de, firefox, gtk etc
on your own machine and see if it makes any difference.

if it does, report back.

egag

Believe me, the setup was optimal. lots of googling, lots of posts at LQ.org to speed it up everyway possible..but windows just seemed faster..all unnecessary startup stuff & processes were disabled.


to do that in slack anyway would be dependency hell IMHO..(i had a fun installing gdesklets)


anyway im going to give slack 10.1 a shot one of these days and see if i like it....i686 or not, theres always a certain charm about slack

I have heard that too, Windows open windows faster, but frankly, could you benchmark a system just by testing its speed at boot and for opening windows ?

Also, if you want to run a V8 system, try some Kernel patches like Kon Kolivas...
For my part, I prefer have a slow stable system than a speedy buggy one (and I like the unpatched 2.6.9 kernel).

The only difference I see when enable CFLAGS during compile is a resulting binary with a slightly less drive space than unoptimised one. So I think as it has less size, it would load quicker in memory (in theory). But the difference is minimal.

about benchmarks....synthetic benchmarks dont really matter right?..theyre not real world results (like a lot of articles saying raid-0 is crap in the real world, but brilliant in benchmarks)..what matters in the end is the experience or atleast the feeling of speed & responsiveness for the user..and windows is better when it comes to that..(but windows is annoying too cause it does sneaky stuff to speed up boot time like loading services after logging in...i hate those flickers & mouse jerks during a windows boot up)

ive tried CK, CKO , mm & ac patches...but none of them made any noticeable difference...i greatly suspect DLG/swaret/slapt-get/random-dependency hell(during gdesklets) of ruining my system...i guess i should take pat's advice about things like swaret/slapt-get...but its quite annoying when you download a program...extract...run configure..then find out that you need some other program..google again..install that..then come back to the original program which you wanted to install..only to find out that it fails slightly later during configure..amd google again...

and a good number of websites dont really list dependencies..thats what makes it all so frustrating..