It's also that 2 numbers will be transported in one cycle, and via the m32 I guess that the compiler makes use of the same additional registers that exists on 64bit, but I would have to check this, that a pure 32 bit compiler would not do on the same cpu, (especially via flags Slackbuilds provide and that are not changeable without editing the build;-).
I have been ask to show an example where -m32 code is faster, I explained that simple examples are synthetic, but I delivered. not more or less.

That is a meaningless comparison.

a=32-bit
b=64-bit
n=time

If a takes 12 cycles and b takes 24 cycles that is still the same amount of data being processed as b is piping twice the amount of data so the n has to be more than double for b over a. Sure, 32-bit will have a lower n number, but it is also half the word length or amount of data being processed.

Your file size comparison is also arbitrary for the same reason. 12Mb on a 64-bit bus and file system will load (all else equal) at the same speed as 6Mb on a 32-bit arch.

This is computer basics...

Actually, you delivered nothing as your example is 'synthetic'. English is a second language for you so here is a hint. When you call your example synthetic you automatically disqualify it as proof.

Excuse me, but I want to understand well what you expect from me.

So, you want me to create a virtual machine, where's a full install of Slackware 32bit, but powered by a 64bit kernel from Slackware64?

Then, to share this virtual machine somehow to you, for your own tests?

IF that's what you want, I agree; please tell me what you prefer as style of that virtual machine: a VirtualBox or VMware (Player) box?

After I will known this information, then in this weekend I will made it and I will send you a link from where you can download it, via a private message.

PS. Sorry, but I cannot offer public downloads (specially something big like a virtual machine), because I have no servers at disposition like some others.

Relevant: Running a 32-bit Slackware within an lxc container on a 64-bit Slackware host how-to, from our own ponce -- http://slackware.ponce.cc/blog/2012/...lackware-14-0/

This is a known alternative to multilib, suggested in (and linked to from) the slackbook.

3 members found this post helpful.

Tell me when you have this VM with a system that covers what you promised and that it covers all use cases we are talking about when it comes to multilib, and I will provide you the online space. Until than, take Erics' post from #157, that fits much better to your post.

how those this help to run games? wine? other useage of mutlibi? oh, it doesn't! We hat this already, you did not pay attention but just wanted to state that the limitation of Slackware is full OK because you are not affected and don't understand/know all use cases. What valuable contribution, thanks!

What you want to suggest? That is impossible to run a full Slackware 32bit userspace from a 64bit kernel?

You know well that's perfectly possible, because that is exactly the principle behind of your beloved Multi-Lib, on 32bit side. And in the past I tested that in real machines, not virtual ones, then I know what I say.

BTW, when someone said that he's sure that you will raise later to the full-fledged Multi-Lib, you said him that he's a troll; and dared to insult. So, what you do now?

We care only about your beloved high performance computing based on integers and compiling programs who needs only libraries from GLIBC and GCC[1], like you claimed?



[1] then pure console programs, unable to interact with nothing else, i.e. network or whatever. And 3D is out of scope. It is all about crunching integers as fast as possible.

I said this is my main usecase, read it up, and that I do not care so much about the other use cases, but that there are many reasons why multilib compiler should be default in Slackware. Fits of course not to your trolling, you troll. Now deliver what you are talking about or shut up, because everyone knows now what a big moth and troll you are

My friend, I know you are smart, and you know you are smart.

BUT, please remember that also other people are smart, and some knows even to write C/C++ like you. You are nothing superior me as intellect and performances. And you aren't even the single programmer in the block.

Not that I strive to remember you, BUT, please respect me as myself I respect you. You aren't stupid, me neither.

OK, people, so the incredible and impossible Slackware 32bit operating system with a 64bit kernel, had been incarnated in the form of a VirtualBox virtual machine. Screenshot attached.

It is just a standard full install of Slackware 32-bit excluding KDEI series and usual configuration.

After finishing installation, I replaced the non-smp kernels with the ones from Slackware64, then configured the LILO and reboot.

Sure, there is no possible to build kernel modules, because the lack of a proper x86_64 compiler, as I said in a previous post.

Must be invented some cross-compiling, or maybe used a multi-architecture GCC, with the note that of course GLIBC is no need to be touched. That's why I said that I tested that, it is possible, I had intention to propose that from long time, but I had no time yet to find a minimal invasive solution for building X86_64 kernels and modules from this 32bit operating system.

Long story short, if someone wants to download this virtual machine, just to ask in private, I will export it and in several hours I will send them a link from where can be downloaded. In several hours, because I have something to do meantime.

And again, sorry! But I have no public server at disposition for publicly share it.

BUT, leaving out all [removed] and all that MULTILIB AKBARU! it is trivial to run a full-install 32bit operating system with a 64bit kernel, when we talk about Slackware. IF you already have them and you do not need to build modules, ie. from Slackware64, yet to make a cross-compiler to x86_64 is not so complicated.

Another visible issue is that anything using the UNAME feature believes that's in a 64bit operating system, just like in Slackware64 and Multi-Lib, but that could be fixed using simply /usr/bin/linux32

Something like that started to use Fedora around 10 years ago. It is nothing new.

Attached Thumbnails

 

2 members found this post helpful.

Darth , you claimed that we need no multilib gcc and than you said everything is already available via the isos, what implies that you mean Erics work on multilib is not needed.
Still waiting for your prove, so far you delivered nothing than embarrassing hot air. this does not remove the troll status from you.

What hot air, man?

It is just the full install of Slackware 32bit with the kernels from Slackware64. Proof of concept and what I promised. You want to quote myself?

How you build custom x86_64 kernels or modules for them, from the 32bit operating system, that's another story. And I said that.

However, I for one I will build and use a cross-compiler, if I will want to be independent from Slackware64 or to build modules.

Darth, thanks for confirming that: A) you did not understand the topic at all and B) you where just posting OT stuff to troll around.

Excuse me, but "future of 32 bit on Slackware?"

An alternative (and maybe future) x86_64 kernel for Slackware 32bit is pretty on topic considering there are some advantages for this concept. You known the advantages already, thought.

And that might happen, while Multi-Lib adoption not, even if this thread is big like the Requests for Current just before to be closed.

At least, until Patrick Volkering is on command. Trust me, he have a great perseverance on following his vision...

BUT, I will love to stop calling people trolls. I know that's the new trend around is to yell troll to anyone who disagree with you, but from you I have some expectations. As Culture.