That's it? This is your argument?

Feel free to test yourself. I guess installing 3 packages and editing a LILO entry is trivial for a Linux Guru like you.

2 members found this post helpful.

Looking back at your posts here, you've contributed nothing to the topic being discussed. Please consider going away.

chris

3 members found this post helpful.

Sheesh this thread has gotten ugly so please understand that I've not read all the posts in the thread ...

But let me fan the flames a 'bit'

Q: How does one compile and link a 32-bit C-Program on a PURE Slackware64 System ( i.e. a System without 32-bit Header Files and Libraries ) ?

A: One cannot do that as far as I know ...

Here I am working on my PURE Slackware64 14.2+current box ( no Multilib and very few optional packages from SBo or Alien Bob or ... )

Example. This is a small C-Program that executes `uname -a` via the stdlib system() call. I saved the file as /tmp/test-arch.c ( please excuse my old-and-set-in-my-ways formatting )
Then on your pure 64-bit system ...
Note that on my PURE Slackware64 14.2+current system that the linked libraries are all in /lib64/ for this simple program.

Now try to build a 32-bit version of the program:
It will not compile because there are no 32-bit include files on my PURE Slackware64 System.

And even if it did compile, it would not link because there are no 32-bit libraries on a pure Slackware64 box without Alien Bob's Multilib System.

On the other hand ... on my Slackware64 14.2 + Multilib System:
Also for the record, I don't play any games but I have been installing Alien Bob's Multilib on my own systems since he made it available.

This is because I need to compile 32-bit programs for our Customers at work ( Intel 32-bit is the Lowest Common Denominator among all our Customer Systems ).

And I don't have to wait for Alien Bob to update the compat-32 packages ... he kindly provided convertpkg-compat32 and massconvert32.sh so one can convert all the packages you need with each Slackware Update one at a time or all at once as you need.

Finally, I don't have an opinion about including 32-bit include files and libraries on future Slackware64 Systems ... at most I would say make it 'extra' ...

HTH.

-- kjh

1 members found this post helpful.

If you ask me, I will respond this way:

using a cross-compilation toolchain, just like myself I used uncounted times to build CyanogenMod for the ARM architecture of my smartphone. https://en.wikipedia.org/wiki/CyanogenMod

Hmmm ... yes, I understand cross-compilation ... But ... I thought this was about the Intel 32-bit Architecture ...

1. A Slackware64 System with a cross-compilation toochain doesn't sound like a pure Slackware64 System ... ( ? maybe just semantics at work here ? )

2. the only cross-compiler that I know of for compiling, linking and running 32-bit programs on a pure Slackware64 System is Alien Bob's Multilib system ... ( I am sure there are other ways to do it but Multilib is certainly the most convenient way to do it )

HTH.

-- kjh

I fail to understand WHY someone will insists to build 32bit programs on a pure 64bit operating system.

People, there's a saying: "use the right tool for the right job."

I believe that the best way to build 32bit programs is obviously a 32bit operating system. Either ran on bare-metal, or in a LXC container, or a virtual machine. And there's always for you the Slackware 32bit.

And for running particular 32bit programs (specially those which heavily use integers) with max performance, there's always for you the variant of using 64bit kernels on Slackware 32bit.

But another saying is "for someone who has a hammer, everything looks like a nail"

2 members found this post helpful.

Speaking of using 64bit kernels on the Slackware 32bit, you have an explanation why apparently entire OS behave better and not only the OP's test program?

I was so much impressed by performance differences, that I consider to leave that box on using them as is. TBH, I do not need to build custom kernel modules for it.

This has been explained in depth, if you are not willing to read the thread then do not post. This is another example of why you are only capable of worthless trolling.

2 members found this post helpful.

Well, first of all, the SMP kernels form Slackware 32bit uses PAE, which essentially is the usage of a table with addresses of chunks of memory. This table permits to kernels to use up to 64GB memory instead of 4GB, but introduce some additional processing.

Compared with the 32bit kernels and their PAE, the 64bit kernels use so called "linear addressing", then they does not need to translate and re-translate memory locations, via a whatever table of chunks. Then they are a bit faster.

And another advantage is that they can use memory with size beyond 64GB. Not so important in the past, but today can happen your server to have 256GB memory and to have the need to use a 32bit operating system, because some proprietary application suite.

BUT, that PAE v.s Linear does not explain the differences observed with the test program suggested by @a4z. Rather, it explains why our BDFL observes slightly better performances of 64bit OS on his benchmarks.

What happens with this test program?

For simplification, let's imagine that an "integer" could be defined by a number from 0000 to 9999 (4 decimal digits) and that a 32bit CPU register or a memory location can contain exactly that number with 4 digits.

How you put 4 "integers" in memory, in this case? Sequentially.

1111
2222
3333
4444

Now, let's imagine that the 64bit has a double width, from 0000000 to 99999999, both as CPU registers, memory locations and "integers".

How you put exactly these 4 "integers" in memory, in this case? Of course, sequentially.

00001111
00002222
00003333
00004444

You will observe that apparently the CPU do the same job but the length of data differ. And that apparently a part of memory bits is not used.

Then, the brilliant minds behind compilers had an idea for static data: packing it to use the unused part when the records are smaller than registers width.

It is about something like:

11112222
33334444

Obviously, writing and reading TWO memory locations is considerable faster than reading and writing FOUR.

How in a 32bit operating system, the "integers" has 32bit length, when the kernel (and CPU) is 64bit, it is possible to use this records packing, resulting in a faster execution.

Which programs benefits from this records packing? Any programs which does not intend to manipulate this data, just to load it and read it.

For example, to compute a logarithmic sum of those integers. OR to load in memory tons of images, like Firefox do for its web-pages. OR even the compositing game done by a window manager, which is all about pixmaps put all the times back and forth.

Long story short, some applications can heavily benefit from this combination of a 64bit kernel and a 32bit operating system.

2 members found this post helpful.

don't take these guy serious, he doesn't understand the difference between a cross compiler and a multilib compiler, but he manages to have the brain acrobatic to be against inclusion of multilib compiler in 64bit Slackware but he thinks that 'optional 64bit kernel for Slackware 32bit is a interesting suggestion for improvements.' #206

Darth Vader is agains multilib, talks about alternatives that are all no alternatives, just to destroy any useful discussion

and jakep says my example, from which I said it is obvious that is is faster, is not an example for anything because it is obvious that such code is faster on 64 bit if compiled with32 bit, just to produce poison and make noise in this thread and be able to troll arround, togheter with Darth and ZahoLin

and I got friction points for the same post 2 times in a row, still don;t know why 2 times, but the trolls that mess up this and other threads with undoable or wrong techical info or pure nonsens and/or provocations are allowed to continue spread their mess in this place.

meanwhile, the person who maintains the multilib compiler that has so many user here has the following on his blog
https://alien.slackbook.org/blog/indisposed/

which is an other prove why multilib compiler should be available by default and not via a 3rd party repo, but of course just for those who understand what it is and wherefore it is used, and the persons who made the most noise in this thread, namely Darth Vader, jakep and ZhaoLin1457 are not in this group, they are trolls that want to destroy every topic and discussion here they don't understand.

sad to see to what this place became, no wonder that on Linus conferences and other places Linux devs and other people get a slightly grin on their face when the topic comes to Slackware

actually, this topic is final discussed, I think an admin should close this thread

See my previous post about a tentative of explanation on layman terms about what happens, and why some 32bit programs tend to behave faster under a 64bit kernel.

The people who spread misinformation are the ones who claims about magics behind "-m32" flag. There's not such thing. The magic is elsewhere.

2 members found this post helpful.

a4z --

I believe you've got me mixed up with someone else ( #206 ).

But would you not say that Alien Bob's Multilib System provides a cross-compiler ?

I do because I use it that way to cross-compile Intel 32-bit programs on my Intel 64-bit system.

And as far as automatically installing Multilib ... even RedHat makes Multilib optional via the compatibility libraries ...

YMMV ...

-- kjh

1 members found this post helpful.

Reported with a request that this thread be locked.

1 members found this post helpful.

Yeah, man! RedHat gives you Multilib optionally.

BUT, also it gives you the RPM package manager, and automatically dependencies tracking. It also, gives you LinuxPAM and Kerberos. And I kept best one for the last: SystemD

Did you really believe that Patrick Volkerding should to exactly what RedHat do?

What is wrong on discussing about the advantages of using 64bit kernels on Slackware 32bit?

2 members found this post helpful.