One of the main reasons why I provided a proof that things could be automated is just for the sake of proving that if one decides to convert them many at once, they could be easily done. But yet again as I've been saying repeatedly SlackBuilds need to be converted only once.
I didn't say anything like it's all about compiling. Yet again I was after the concept that if something doesn't compile 1 out of 10 it could be a sign of binary incompatibility or ABI as you said, and probably API as well sometimes.
If not sorry I must have confused you with other replies.
I guess it wasn't really obvious that the main thing I wanted was to prove that an optimized version of a release is possible, and the decision and control would still be from the Slackware Team. Of course I don't really have to try converting everything, and modify everything. I just have to show that a large and highly significant portion of it could be optimized.
You would have avoided the wrong version quickly if you tried to compile it first then test it rather than test, compile, test.
If that is -really- the case then I would really think about it. Unless it's only a limitation of Slackware and not really the principle.
Yet again it could be avoided with one preventive measure if packages are compiled. They could be patched if they don't work with current gcc. As for the risk about newer features being enabled and needs to be tested, I think I see more risks with an older version that shows possible signs of incompatibility at compile time.

At least just one significant thing. It is possible, and doable if really wanted. And I actually just did the second motion. Funtoo already proved it.

@Erik_FL I'm sorry, and thanks for the post, you have my respects, but can you tell us what you think about how the newer instructions like ssse3, sse4+, etc. could give difference for possible new levels of optimizations? Or are they not really that helpful?

I had a critical reply to Konsolebox here, consisting largely of points that were made by others, but I thought better of it...

Konsolebox, just complete your project as best you can, and then give us your report on the results afterwards. We don't really need to hear anything about it in the meantime. (Unless you need technical help along the way, of course).

2 members found this post helpful.

Those instructions are designed to optimize repetitive calculations on large amounts of data. They have a fairly limited application to media streaming and conversion and some advanced mathematical problems. The C/C++ compiler can use those instructions in only specific kinds of repetitive calculations. Detecting those situations in the compiler is difficult.

The SSE instructions are not very useful for optimizing general-purpose C/C++ code. The SSE instructions would mainly be useful to provide a 128-bit floating point or integer data type. The problem is that the SSE instructions do not implement all of the standard calculations in the C++ language or libraries. They are not designed to be a replacement for the normal 64-bit FPU or the normal integer and move instructions. There is a penalty for moving data between the special registers and the normal CPU registers. The C/C++ compiler cannot just substitute SSE instructions for other instructions that do the same thing once or twice. It would reduce performance.

How the libraries and applications choose to use SSE instructions depends on how they are designed. Some may depend on compiler optimizations. Some may use header files. Others may check the CPU identification and capabilities at run time. Some programs may just support the "old" SSE capabilities when the instructions were first added to the X86 architecture and not the variations added later.

So, recompiling applications like media players and video converters is much more likely to provide a performance increase, than recompiling the shell, for example. I expect a lot of software just tests for the presence or absence of the minimum SSE capabilities rather than trying to provide different code for all the variations.

There is a negative aspect to using the SSE instructions in a kernel, kernel modules or drivers. They carry an additional set of registers and execution state information that has to be saved and restored. I wouldn't expect the kernel compilation to enable the use of the SSE instructions in the kernel. One can make a very good case for using some of the other instructions designed to improve performance with multiple cores or multiple CPUs. That is why I think that re-compiling the kernel provides the most benefit to take advantage of CPU variations.

2 members found this post helpful.

I'm sorry but what do you think is still needed to be done there (assuming you've seen my post)? For a normal user perhaps I'm not done, but for a maintainer I think I've shown enough. The concept is proven and one could already visibly see the outcome. The only thing that's remaining is just something that would almost complete the project, but likewise it would still need a decision from the team like making a complete change to the SlackBuilds.
Like what technical help would still be needed?

Wait and see

Eric H.(one of our lead developers) posted in your thread and he offered his point of view.

Mr. Volkerding(our maintainer) has remained silent in your thread. Silence is an answer in my opinion.

1 members found this post helpful.

Well something has to be done when it has to be done. I've seen many things quite enough thanks to this thread. I did say that it's up to them but that doesn't really mean I'm expecting it. I proved stuffs all because you guys wanted those, and now you see. And exploring Slackware further was quite fun as well. Someday I would still do that anyway. The case for Slackware being further improved through efficient use of instructions and hardware capabilities I think is as good already as finding its conclusion. Slackware would remain conservative for the rest of its life I guess. And I'm already quite fulfilled to know that.

The dogs optimize, the caravan i486.

(Old Arab saying)

Only because we lost i386 on our way to 3.8

Come again?

And so it shows.

Possible and doable yes but this is not what you claimed. You claimed it would be easy to maintain multiple optimised binary versions of Slackware. It may be possible for me to climb Everest, that is not the same as it being easy.

You have now rebuilt a sub-selection of packages and are suggesting that this is proof?? Where are the rest of the packages and how do you propose to keep maintenance simple, when it is obvious that someone would need to manually update all the other SlackBuilds (those that did not build automatically)?

I am still waiting for you to prove that it is easy to fully rebuild Slackware and maintain the SlackBuilds such that they can always be rebuilt at the drop of a hat.

I am also waiting for proof that it is worth it (show me the benchmarks) and that there are sizable numbers of other people who actually want all of this. Without these two things, what is the point, other than as a learning exersize?

You have not proved a single thing. Being able to queue up a few SlackBuilds was obvious prior to you attempting it. I seriously doubt that anyone questioned that some packages could be built in a queue. Why would they, after all sbopkg has this functionality built in and is used by people here daily.

Umm ... what?? Where are the benchmarks or other proof that rebuilding was worth the effort?

You have gone some way to proving that we were right and this was all pointless, given that it has taken you this long to get almost nowhere in terms of doing anything difficult. Well done on that count.

Yes it will at least the amount of work compared to gathering packages to build a new release is far uncomparable. And this could all be seen with one script. At least try to look at the script I made and how you could monitor all the logs within there. And of course that's not final but even just with it I was able to just let hundreds of packages compile and not even trying to repeat most of them when something fails.

I don't see how difficult it is to add more features like automatically copying the packages that were successfully compiled to their proper directories, do some checksums, etc. If one package failed to compile all because it can't, simply choose the original generic package for the package. Then build the ISO. Those things are far trivial already.

I think I can't suggest that to those who wouldn't really care and not really wanting to have an idea about it.

You obviously don't follow the flow of the topic now. Why are you even asking for the rest of the packages compiled?

Go wait as I see it no longer worth giving. I gave enough points already, and if you are in doubt that a distro can't do that, go check Funtoo.
Not proved a single to those who wouldn't really care and try to understand perhaps.
No I don't agree that you guys were right about all those about Slackware being able to have optimized versions, but I guess you were right that Slackware can't go further to it as is. Well let's just say that I wasn't convinced until now.

And yes from what I discovered I think I can't accept how Slackware just allows an old package to be included when it could have possible compatibility issues, and relying more on discovering bugs through long-term use rather than checking through compile-time if it's compatible with the new dependency packages. Yes the team monitors which could still be compatible with new updates, but I still see that is risky and so not Slackware-like as how I thought Slackware is. Yes I admit. I was mistaken about Slackware's approach to stability.

You started this thread on the 17th of last month

dugan's replies weren't "official" enough for you.

Then Eric responded to you on the same day: https://www.linuxquestions.org/quest...ml#post4933380

You ignored his post and continued as before. You've also ignored or rejected the good points made by many other well respected users.

We're now onto page 9 of this pointless thread, over two weeks later, which could easily be renamed as "why can't slack be more like gentoo or funtoo?".

Pat has not responded.

I'll leave you to fill in the blanks...