[SOLVED] future of 32 bit on Slackware?

a4z · 07-06-2018, 09:14 AM

Quote:

Originally Posted by orbea

@a4z I was going to test your latest example, but I found it just ate all my ram and then started to make my system very slow when it filled the swap too.

That said the a32 version ate less ram and was able to complete before the swap was hit too hard. Would you mind satisfying my curiosity and running them with strace -fc? It'd be interesting to see if there is a difference in the number of system calls used.

I help you to help your self, OK?

comment out like this

Code:

    
//    d3 = d3 + measure<>::execution([](){doSomeThing<100000>(4);});

or replace this

Code:

    d1 = d1 + measure<>::execution([](){doSomeThing<1000>(2);});
    d2 = d2 + measure<>::execution([](){doSomeThing<10000>(3);});
    d3 = d3 + measure<>::execution([](){doSomeThing<100000>(4);});

to that

Code:

    d1 = d1 + measure<>::execution([](){doSomeThing<10>(2);});
    d2 = d2 + measure<>::execution([](){doSomeThing<100>(3);});
    d3 = d3 + measure<>::execution([](){doSomeThing<1000>(4);});

than

Code:

    d1 = d1 + measure<>::execution([](){doSomeThing<100>(2);});
    d2 = d2 + measure<>::execution([](){doSomeThing<1000>(3);});
    d3 = d3 + measure<>::execution([](){doSomeThing<10000>(4);});

to see where your system gives up

the number in <> is an array size

the code creates a 'matrix' 100000 x the template arg (the number in <....>)

the 100000 comse from this line

Code:

data.resize(10000,row);

these are the numbers to turn

sorry for not having the time to make this more comfortable configurable, some people here have eaten too much of my time for doing this

a4z · 07-06-2018, 09:23 AM

Quote:

Originally Posted by orbea

Maybe I'm confused, but I thought this discussion was about building and running 32-bit programs on Slackware64 and not cross-compiling 32-bit programs on Slackware64 intended for use on 32-bit systems?

55020's example is just noise and has nothing to do with what we discuss here. he can not build the hello world I posted, he is just making noise for something that has nothing to do with the topic of he requirement of a multilib compiler for several use cases.

The 3 persons that found his post helpful should stop reading here, they obviously do not understand the topic and believe in the wrong persons, persons that tell them what they would like to hear, even if this has nothing to do with reality. This is why such post are so bad. They create wrong information and are actual damaging to Slackware and the Slackware community here.

Darth Vader · 07-06-2018, 09:27 AM

There's another way to get what you want:

To run a Slackware 32-bit operating system on top of a 64bit kernel from Slackware64. Fedora done something similar for long time.

To be honest, I wondered about proposing this (alternative) 64bit kernel for Slackware 32bit, since long time.

But I had no time to study how is possible to build this 64bit kernel from the 32bit operating system without an additional x86_64 cross-compiler.

a4z · 07-06-2018, 09:32 AM

Quote:

Originally Posted by Darth Vader

There's another way to get what you want:

To run a Slackware 32-bit operating system on top of a 64bit kernel from Slackware64. Fedora done something similar for long time.

thanks for the next meaningless and irrelevant OT noise, Darth Vader, did you troll enough in the KDE5 thread, now this one again?
can not admins give you a week break, or so. (please do not reply, there is already enough OT noise here, thanks)

Darth Vader · 07-06-2018, 09:35 AM

Why my post is trolling?

The end result is running the 32bit software on top of a 64bit kernel, just like in a glorified and really full-fledged Multi-Lib.

BTW, while for my shame I have no benchmarks, from my empirical observations, 32bit software on top of a 64bit kernel feels snappier[1]. I talk about things like a full desktop environment.

I may be wrong, but this is what I believe.

[1] Damn, I'd just realized that I sent a huge ball right to the Multi-Lib fans side, but I keep my statement and beliefs.

a4z · 07-06-2018, 09:57 AM

Quote:

Originally Posted by Darth Vader

Why my post is trolling?

The end result is running the 32bit software on top of a 64bit kernel, just like in a glorified and really full-fledged Multi-Lib.

BTW, while for my shame I have no benchmarks, from my empirical observations, 32bit software on top of a 64bit kernel feels snappier. I talk about things like a full desktop environment.

I may be wrong, but this is what I believe.

You ignore what I have written, just to repeat the no need for multilib and I shall think this is not trolling?
Darth, how shall I compile my code to 32 bit, not cross compile, when there is no compiler for this? what is one of the use cases we are talking about an that you are kindly ignore, and I shall think you are not trolling?

Darth Vader · 07-06-2018, 10:06 AM

Quote:

Originally Posted by a4z

Darth, how shall I compile my code to 32 bit, not cross compile, when there is no compiler for this? what is one of the use cases we are talking about an that you are kindly ignore, and I shall think you are not trolling?

You are kidding, right? Obviously, the compiler and linker from the Slackware 32-bit generates natively 32bit code. The issue is instead on how you generate x86_64 code, like I stated.

Please read my post again; I talk about running the whole 32bit hog - a full Slackware 32bit install, but with a 64bit kernel.

Same do a Multi-Lib feature, where the 32bit code is executed literally (starting from GLIBC) on a 32bit environment, but on top of the 64bit kernel.

a4z · 07-06-2018, 10:23 AM

Quote:

Originally Posted by Darth Vader

You are kidding, right? Obviously, the compiler and linker from the Slackware 32-bit generates natively 32bit code. The issue is on how you generate x86_64 code, like I stated.

Please read my post again; I talk about running the whole 32bit hog - a full Slackware 32bit install, with a 64bit kernel.

Same do a Multi-Lib feature, where the 32bit code is executed literally (starting from GLIBC) on a 32bit environment, but on top of the 64bit kernel.

who is kidding whom? you need to convert all packages via Eric scripts because everything not in /lib /usr/lib will override what Slackware64 ships, this is a super bad idea what you suggest in you desperation to hold your multilib opposition. Just give up you justament standpoint against multilib, you have nothing productive to add to this topic. If you do not stop and bring an other unusable or not comparable point, like running a container or VM, I will consider you as troll and you will be next to jakedp on the ignore list, what would be sad because very somtimes you have a valid point, but too many people have already created damage to this topic with nonsens alternative, like the one you just suggest, so if you do not stop ...

Darth Vader · 07-06-2018, 10:26 AM

You do not need to do something like this - because I talk about the Slackware 32bit and a clean installation of it.

I talk about this one: https://mirrors.slackware.com/slackw...ware-14.2-iso/

Let's put that in layman's terms: you are able to compile your 32bit applications on a standard and full installation of Slackware 32bit? Yes or No?

IF YES, then replace the kernel with the one from Slackware64 with no other changes, reboot and be happy.

ponce · 07-06-2018, 10:32 AM

Quote:

Originally Posted by a4z

an other unusable or not comparable point, like running a container

sorry, why this is not comparable?
containers are just compartmentalized processes running under the same kernel, you even see them running along the others with ps on the host, and you also will have available a native 32bit compiler in the container...
I sincerily don't understand.

jeremy · 07-06-2018, 10:35 AM

A reminder that flame wars and personal attacks are not acceptable here. From the rules: Challenge others' points of view and opinions, but do so respectfully and thoughtfully ... without insult and personal attack. Differing opinions is one of the things that make this site great.

There seem to be a very small number of members who are unable to do this on a consistent basis. I'd ask everyone to keep this in mind if they'd like to continue participating here.

--jeremy

orbea · 07-06-2018, 10:40 AM

@a4z Thanks for explaining that. I changed it to the limited example and now it runs without taxing my ram and swap.

Code:

    d1 = d1 + measure<>::execution([](){doSomeThing<10>(2);});
    d2 = d2 + measure<>::execution([](){doSomeThing<100>(3);});
    d3 = d3 + measure<>::execution([](){doSomeThing<1000>(4);});

Code:

$ strace -fc ./a32 
strace: [ Process PID=9380 runs in 32 bit mode. ]
964
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000007           7         1           execve
------ ----------- ----------- --------- --------- ----------------
100.00    0.000007                     1           total
System call usage summary for 32 bit mode:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.62    0.136085          40      3355           brk
  0.13    0.000180          13        13           mmap2
  0.07    0.000097          16         6           openat
  0.06    0.000084          12         7           mprotect
  0.03    0.000044           7         6           close
orbea@Akita:/tmp$ strace -fc ./a32 && strace -fc ./a64 
strace: [ Process PID=9584 runs in 32 bit mode. ]
1292
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0         1           execve
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                     1           total
System call usage summary for 32 bit mode:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.148291          44      3355           brk
  0.00    0.000005           5         1           write
  0.00    0.000002           0         7           fstat64
  0.00    0.000000           0         4           read
  0.00    0.000000           0         6           close
  0.00    0.000000           0         1           access
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         7           mprotect
  0.00    0.000000           0        13           mmap2
  0.00    0.000000           0         1           set_thread_area
  0.00    0.000000           0         6           openat
------ ----------- ----------- --------- --------- ----------------
100.00    0.148298                  3402           total
1546
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.77    0.356752          54      6550           brk
  0.07    0.000268          17        15           mmap
  0.05    0.000166          16        10           mprotect
  0.04    0.000126          21         6           openat
  0.02    0.000070          11         6           close
  0.02    0.000057          14         4           read
  0.02    0.000056           8         7           fstat
  0.01    0.000025          12         2           munmap
  0.01    0.000020          20         1           arch_prctl
  0.01    0.000018          18         1           access
  0.01    0.000018          18         1           execve
  0.00    0.000007           7         1           write
------ ----------- ----------- --------- --------- ----------------
100.00    0.357583                  6604           total

If I understand correctly this is about half the system calls and certainly shows why its faster. Of course I understand this is not the most meaningful example since different code bases may react differently.

a4z · 07-06-2018, 12:30 PM

Quote:

Originally Posted by ponce

sorry, why this is not comparable?
containers are just compartmentalized processes running under the same kernel, you even see them running along the others with ps on the host, and you also will have available a native 32bit compiler in the container...
I sincerily don't understand.

since they do not cover all use cases, like , nvida drivers, gaming , .....
whole picture, remember

a4z · 07-06-2018, 12:36 PM

Quote:

Originally Posted by Darth Vader

You do not need to do something like this - because I talk about the Slackware 32bit and a clean installation of it.

I talk about this one: https://mirrors.slackware.com/slackw...ware-14.2-iso/

Let's put that in layman's terms: you are able to compile your 32bit applications on a standard and full installation of Slackware 32bit? Yes or No?

IF YES, then replace the kernel with the one from Slackware64 with no other changes, reboot and be happy.

you know what, Darth, create such a system as a VM that you share so that we can verify what you are talking about, compile the sample code I provided, show that it covers the other use cases like gaming wine etc and is superior to a multilib that come as default install, than I might believe that you are not a troll.
But until you have delivered what you are talking and prove that what you say is true, like I did with my claims, take a break from the forum You will of course not do this because you can not deliver what you are talking about. That shows the value of your posts. 0 , zero, nothing

ponce · 07-06-2018, 12:42 PM

Quote:

Originally Posted by a4z

since they do not cover all use cases, like , nvida drivers, gaming , .....
whole picture, remember

sorry, I thought your point was all about the multilib compiler, games seemed to be out of the picture.

BTW, with a little effort even that is possible

https://devblogs.nvidia.com/gpu-containers-runtime/