Umm, this is not the tricky bit. Wake me up when you successfully build them all.

4 members found this post helpful.

...and tested them all, for multiple archs, like he asked for.
I'm not even thinking about maintenability/upgrading (for now).

Zzzzz...

4 members found this post helpful.

Honestly, I don't understand why you are avoiding Alien Bob's work which does have a chance to make it into Slackware one day. He has this file (/etc/slackbuild/machine.conf):
Which is centrally located and can be changed -- this way you would be able to add your own SLKCFLAGS in one location which is (or will be, in the future) obeyed by most of the SlackBuilds. In the individual SlackBuilds (this is not widespread in his local scripts yet but I have to assume it will be in the future):
If this ever gets adopted by Slackware to more easily handle multiple ports (and of course this isn't guaranteed, but at least Pat has seen it, according to this post), then you can just adjust /etc/slackbuild/machine.conf (or use a local machine.conf) and you don't have to do this potentially error-inducing automatic script editing. Of course it means you would have to wait until Alien Bob has modified more SlackBuilds to support this new format before starting your project, but at least it adds an element of future-proofing to your effort. It still wouldn't guarantee that all packages would actually build at any given time, but it would mean that you could focus on that instead of having to worry about both modifying SlackBuilds repeatedly for each architecture and making sure everything actually builds.

As a side note, to see if there are any SlackBuilds that need manual attention after the above modifications are more widespread, your script would be reduced to:
This is more maintainable, more future-proof, and less error-prone...

1 members found this post helpful.

Seems to me it is much more useful to spend time getting a Slackware release that can run on multiple chip generations rather than spending time grinding out a suitcase-full of so-called optimized packages.

Here's the thing about optimizations: For almost all of us, our systems spend almost all of their time sitting there not doing much of anything. I don't want to make the effort to optimize that. There'd be no payoff. If I started spending a lot of my time in some seriously processor-intensive task, and if I found, subjectively, that it was a wee bit slow, I might decide to rebuild that specific package. But, it would take a lot to get me to do that. I certainly wouldn't do it just to produce better benchmark numbers. If I can't notice the result of an optimization apart from a benchmark test, it's pointless.

3 members found this post helpful.

And if you do "notice" the result but never do a benchmark test, you're fooling yourself into seeing what you want to see.

1 members found this post helpful.

That's why I never bother with tweaks to do things like speed up boot time. Once I get things set up, I don't need to reboot, so I don't. The fastest reboot is the one that doesn't happen.

Every so often, I work my way through a large batch of photo files. Processing an image file can be pretty processor intensive. If I could reduce the time it takes to deal with, say, 300 files, by 50 percent, that might be worth rebuilding something. Even there, though, most of the time involved is down to me staring at the screen trying to decide what I like and don't like. In the end, I'd just use "optimized" software to give me more time to play with the images.

It's up to upstream developers to optimize performance-sensitive code paths - because they know them. Using the shotgun approach by throwing CFLAGS at anything only make some things faster and some things slower (-funroll-loops) - it doesn't make sense.

If your setup is too slow for your use-case, then optimizing isn't likely to change that. If your hardware is too slow for playing 1080p video, then GCC -funroll-loops isn't gonna help you. But if you replace the Atom CPU with a Core i3, then Slackware's stock MPlayer or Alien's VLC packages are just fine. That's the truth behind this whole cargo cult.

I hope you'd be patient as that would take time. It's not something we have to rush. Also, I already mentioned earlier that if a package won't compile with new added march parameter then that package could just remain unoptimized.

Now about your previous post.

Then that would just mean that binary and the
source has inconsistency as a pair, and either one of them does not belong to
that release. That could also mean that the binary was built before an upgrade
in either of its dependencies and could risk having broken links to the
libraries. What I mean is that if the source does not build with current
packages but was successfully built with previous ones then it could also
possibly mean that the binary that it built is no longer compatible with those
packages. So this would be a general problem of the release itself.

Of course there would be exceptions that the package would still work even
after the dependencies were upgraded/downgraded, but still it would be better
that it was verified, and one of it is through building the source with what
is currently there. We could check the consistency of dynamic linking with
libraries as well of course, but sometimes it's also about other depended
stuffs not just libraries.

If it does make it to the next release then things could be adopted. What I'm really just after is a proof that an extension of optimized packages could be made use. I'm just looking now on the stable snapshot of 14.0. I also have my own different ideas about it, and so decided not to look at any other script or solution.

On generic optimizations probably, but you can't do that with hardware-specific implementations unless you do ASM. And even just with that, you can't do it without sacrificing readability most of the time.
I don't see how necessary it is to test with all archs to my prove my point? Probably those who haven't had much experience with compiling packages that target different architectures would say that.
I wonder if you really had the idea that it's only about the release and not really about the package upgrades? Yet again, it could happen if the Slackware team decides to have optimized packages on the upgrades as well.

Also like I said if it's decided the converted scripts need to be converted only once and be used as a general form afterwards.

The thing is you really are not likely to see all that much in the way of gains there. I really recommend people find some smallish C code they understand, call GCC with -S and different mixes of optimization flags. Compare the outputs.

Its not easy to count how many cycles something is going to be on modern Intel hardware; mostly you can't due to pipeline stalls, branch prediction, and out of order execution but you can still get some idea of what is better or worse based on the instruction latencies. Spend an afternoon on this exercise once and you will find for the most part you going to get trades that amount to 6 of one for a half dozen of the other. Then you can understand the silliness here they pay off just does not come anywhere near the cost in terms of all the additional testing that would be necessary to support every micro optimization on every CPU step out there.

Look if you are running a photo blog and you have a box dedicated to doing nothing but processing upload files with imagemagic 24x7 yes fine; monkey with flags on that; but for general packages that are not support hot code paths its not worth it.

Really you'd probably get the most bang for your buck doing an CPU specific build of the kernel and glibc and stopping there; in almost every other situation (and even this isn't really worth doing).

1 members found this post helpful.

Or it could be something that certainly appears to be beyond your ability to understand. You really do need to read this thread since it covers this very issue.

1 members found this post helpful.

I went to the thread but can't see how the topic is really related to this as it's more on compiling everything from scratch, and didn't see anything that could disprove my point. I just made a quick read, but can you refer to me an idea there that actually disproves it?

Just to tell you I've tried LFS, known the concepts of toolchains, system build stages, binary conflicts, way too long already since 3.6-4.0 gcc upgrade.

I have doubts on that, yet again you can you feel the actual output like how I see the number of FPS my game could have, which is especially crucial with emulating softwares. Note that this is not only about the software itself but on the libraries it depend upon as well, especially graphics libraries.

And can't you not measure the amount of time that a batch of files could be processed in average, and if not the amount of time needed to transcode an audio/video, and even those that rely on input especially HD which needs immediate processing.

Why would someone need to build critical and heavy libraries like glibc on their own when they could be distributed as a package? And things about media files is not really even about glibc.

No.

Time and time again we have seen GCC becoming more compliant with the C/C++ standards and as it does old code stops compiling.

This does not mean the binaries are no longer compatible.

These are *ROUGH* numbers since I am just looking at /var/log/packages/ on my installed system instead of verifying everything on a mirror. There are 92 packages that haven't been recompiled since at least 2009. Another 54 haven't been recompiled since at least 2010. Another 179 haven't been recompiled since 2011 (those 179 packages were compiled during 13.37's development cycle but were not recompiled during 14.0's). Newer versions of glibc intentionally maintain binary compatibility with binaries built using older versions of glibc, and minor library (dependency) version bumps are supposed to maintain ABI compatibility, so unless there is a major version bump to a dependency it shouldn't need to be recompiled (and sometimes even with a major bump it may still work).

Again -- as I stated before -- packages are only recompiled for one of three reasons:
1) A security vulnerability has been identified, and the package is patched
2) The package is upgraded to a newer version
3) The package is broken because of an update to another package

Unless it is already known that a certain package will break (if you upgrade certain components of KDE, then other packages will need to be recompiled, for example -- and obviously Pat has a lot of experience guessing what packages will need to be recompiled when major components are upgraded), then the package will probably not be recompiled until someone notices it is broken during -current's development cycle (whether this is a member of the Slackware team or a -current user -- search the forums and you will see plenty of -current users reporting broken packages after other upgrades). Although packages do often break because of other package upgrades, in *MANY* cases they will work just fine. And by the time the package does break -- and this could be years after the package was originally built -- the sources used originally may not compile because of other system upgrades. Again, because Slackware is never recompiled for each release, it isn't the most suitable distro for this project. But, if you really want to spend your time futzing around, go ahead...but it really does seem that you're not getting what people are saying.