LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-04-2013, 03:50 PM   #121
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233

Quote:
Originally Posted by T3slider View Post
Don't forget about those. sysvinit, udev, bzip2, xine-lib, seamonkey, and more are being ignored because they require manual SlackBuild modification. Certainly bzip2 is a candidate for optimization.
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.
Quote:
Again -- Slackware has been one of the most stable and reliable distros since 1993 and it does not recompile everything. If the only requirement for stability rested in compiling for every release, then the vast majority of other distros would surely be ten times as stable.
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.
Quote:
I have never said this, nor do I believe it. But you can continue to put words in my mouth if it makes you feel better.
If not sorry I must have confused you with other replies.
Quote:
I haven't assumed any superiority. I am giving opinions on information that I know about Slackware. You recompiled a bunch of packages, but discovered errors in some and have a WHOLE BUNCH leftover that weren't attempted because mass conversion just isn't possible without rewriting the SlackBuilds (which is why I still suggest waiting for Alien Bob's work and targeting a potential future Slackware release rather than doing this now).
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.
Quote:
This is how Slackware development works. Regardless of whether you recompile or reuse existing binaries, you will have to test to make sure everything still works.
You would have avoided the wrong version quickly if you tried to compile it first then test it rather than test, compile, test.
Quote:
If you are not comfortable with this, then REALLY -- Slackware is not for you. As I stated before, many packages have not been recompiled since at least 2009.
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.
Quote:
This is an API vs ABI discussion. If the ABI remains compatible, it will work. If it becomes incompatible, then it won't. An API change isn't necessary for ABI breakage, and an API change doesn't necessarily break the ABI. Libraries are supposed to bump the major version in case of an ABI change, and while this doesn't always happen (not all programmers are experts at maintaining ABI compatibility), it does work in many cases.
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.
 
Old 05-04-2013, 03:56 PM   #122
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by ruario View Post
What did you prove exactly?
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.
 
Old 05-04-2013, 04:08 PM   #123
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233
@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?
 
Old 05-04-2013, 04:23 PM   #124
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,615

Rep: Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415Reputation: 1415
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).

Last edited by dugan; 05-04-2013 at 04:49 PM.
 
2 members found this post helpful.
Old 05-04-2013, 06:32 PM   #125
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 797

Rep: Reputation: 247Reputation: 247Reputation: 247
Quote:
Originally Posted by konsolebox View Post
@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?
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.
Old 05-04-2013, 10:11 PM   #126
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by dugan View Post
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.
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.
Quote:
(Unless you need technical help along the way, of course)
Like what technical help would still be needed?
 
Old 05-04-2013, 10:24 PM   #127
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,157

Rep: Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013
Quote:
Originally Posted by konsolebox View Post
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
Wait and see
 
Old 05-04-2013, 11:10 PM   #128
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,160

Rep: Reputation: 525Reputation: 525Reputation: 525Reputation: 525Reputation: 525Reputation: 525
Quote:
Originally Posted by konsolebox View Post
For a normal user perhaps I'm not done, but for a maintainer I think I've shown enough.
Eric H.(one of our lead developers) posted in your thread and he offered his point of view.

Quote:
Originally Posted by Alien Bob View Post
You don't really understand anything about Slackware do you?

Also, this is a public forum, with lots of smart people who are willing to answer the weirdest questions - in theor own free time. I think that your tone if offensive to these good people.

To come back to the topic at hand, my answer is:

Eric
Mr. Volkerding(our maintainer) has remained silent in your thread. Silence is an answer in my opinion.
 
1 members found this post helpful.
Old 05-04-2013, 11:44 PM   #129
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233
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.
 
Old 05-05-2013, 04:02 AM   #130
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: ElementaryOS, Ubuntu LTS, Slackware
Posts: 1,537

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
Quote:
Originally Posted by konsolebox View Post
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)
 
Old 05-05-2013, 04:13 AM   #131
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,157

Rep: Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013Reputation: 1013
Quote:
Originally Posted by kikinovak View Post
The dogs optimize, the caravan i486.

(Old Arab saying)
Only because we lost i386 on our way to 3.8
 
Old 05-05-2013, 04:31 AM   #132
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by kikinovak View Post
The dogs optimize, the caravan i486.

(Old Arab saying)
Come again?

And so it shows.

Last edited by konsolebox; 05-05-2013 at 04:33 AM.
 
Old 05-05-2013, 05:06 AM   #133
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,812

Rep: Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817
Quote:
Originally Posted by konsolebox View Post
At least just one significant thing. It is possible, and doable if really wanted.
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?

Quote:
Originally Posted by konsolebox View Post
I proved stuffs all because you guys wanted those, and now you see.
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.

Quote:
Originally Posted by konsolebox View Post
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.
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.

Last edited by ruario; 05-05-2013 at 05:11 AM.
 
Old 05-05-2013, 05:24 AM   #134
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,245
Blog Entries: 15

Original Poster
Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by ruario View Post
No, you claimed it would be easy to maintain multiple optimised binary versions of Slackware.
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.

Quote:
You have now rebuilt a sub-selection of packages and are suggesting that this is proof??
I think I can't suggest that to those who wouldn't really care and not really wanting to have an idea about it.

Quote:
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 that failed will take some work?
You obviously don't follow the flow of the topic now. Why are you even asking for the rest of the packages compiled?

Quote:
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?
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.
Quote:
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.
Not proved a single to those who wouldn't really care and try to understand perhaps.
Quote:
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.
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.
 
Old 05-05-2013, 06:06 AM   #135
cynwulf
Senior Member
 
Registered: Apr 2005
Distribution: OpenBSD, FreeBSD
Posts: 1,265

Rep: Reputation: Disabled
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...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Optimized distros for my particular computer setup? Rick069 Linux - Software 3 09-30-2007 11:39 AM
Custom slackware CD with optimized packs sl4ckw4re Slackware 5 07-13-2006 04:03 PM
Any Debian-based distros that are optimized for 686? lefty.crupps Debian 8 06-16-2005 08:43 AM
Is Slackware booting already optimized? dhave Slackware 1 11-21-2004 12:09 PM
Real-life speed diference between 386,586 and 686 optimized distros Embedded Linux - Distributions 4 06-19-2003 12:21 PM


All times are GMT -5. The time now is 09:07 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration