Thread 106932805

so, i have been looking into the advantages of running 32 bit on 64 bit OS.
i'm currently testing 32 bit firefox and it is absolutely flying!!
it uses considerably less memory, some pages load instantly.

using the exact same profile on both firefoxes and holy shit, the difference is enormous.
i'm starting to think that pushing 64 bit exactly everywhere is a scam by hardware manufacturers.
i get it that you need 64 bit to address more than 4 gb per program but this is completely fine for so many programs.
in rare instances that you need more than 4, you can use the 64 bit version of the program.

try it out guys. i'd like to hear how it works on your machines.

i will start phasing many of my 64 bit programs with 32 bit version where it makes sense.

the main advantage is almost halved memory usage. i'm not yet sure how cpu processing gets affected but for sure it has to work a little bit less in terms of memory.
seems like it would be less efficient in some regards but the gains from the smaller memory footprint might balance those out.

i am only now remembering that i did feel a slowdown in performance when i went over to 64 bit back in 2009 or something but i just accepted it as "the cost of progress" or some other bullshit.

>>106932805 (OP)
>main advantage
only

>>106932817
another advantage may be that since a program can't use more than 4gb, it prevents some memory hogs to down the system with them.

anyway, i'm interested in the hybrid approach.
i'm not going back to 32 bit linux because they are phasing it out in a year or two or five but its over.

however, nothing will prevent me from making my own 32 bit binaries and that is pretty good news.

Is it time to actually consider x32 (64-bit instruction set, 32 bit pointers)?

seriously, for some stuff it makes no sense to even have 64 bit binaries. benchmarks in favor of 64 bit focus on 64 bit calculations but on probably the majority of tasks you don't even need 64 bit.

>>106932865
is this what you're talking about?
https://wiki.debian.org/X32Port

address space layout randomization

>>106932957
easier to crack?

>>106932865
picrel

>>106932805 (OP)
the whole point of 64bit is so it can use memory greater than 3-4gb. if you mod oblivion you quickly hit this limitation and need to convert it to 64bit.

>>106933365
thats common knowledge by now.

however. i just ran a browser benchmark speedometer 3.1 and 32-bit binary does it considerably faster than the 64 bit.

i will repeat the benchmark again and post the results.

first time results are (higher is better i suppose since its a speedometer)
64-bit: 4.88
32-bit: 5.79

i will repeat this now.
just making sure nothing is interrupting in the background

post any benchmarks you'd like me to try.

>>106933365
64-bit also has a fuckton more registers so there's less loads and stores to caches and main memory. And a faster syscall mechanism.

>>106933447
speedometer is a hw acceleration test. if you turn it off in your browser your score drop drastically or doesn't even finish. if you want to improve speedometer you need better gpu drivers + any cpu enhancements you can get (like avx512 if you use v4 on linux)

>>106932805 (OP)
this would make sense to me since javascript puts everything on the heap.
So each variable would create a pointer to where the data lives.

i don't know but its at least its not placebo. it is definitely faster on my machine. might be worth running it for a while. i appreciate the lower memory usage on my 8gb machine.
switching some commonly used applications might be worth it.

it implies multilib but i already have that.

its the same profile and extensions and everything.

now a fairer comparison would be to get both firefox binaries from firefox.com because here, the 64 bit one is the distribution package

JetStream gives the opposite result.
64 bit is a little bit faster.
not by much though.
i'd say 32 bit passed it.

some things are better some things are worse.

64bit better

the brws

the 32bit browser does feel quicker to start and some complex sites open a bit quicker. must be the smaller memory footprint. this is enough reason for me to use 32 bit in some cases.
the rest is almost tied except the graphics where 64 bit seems to do better.

>>106932840
>32 bit linux because they are phasing it out in a year or two or five but its over.
i thought le open source good, everything is supported & faster & better than proprietary
everything's fucked

>>106934382
Lmao imagine believing what freetards say

>>106934382
thats why there is stuff like netbsd.

quickly tested the two firefoxes with the same set of 20 tabs, 2 web apps, two youtube videos (one playing) and the rest normal websites.

hard to say exactly but close to 2.96 G for 64 bit and 2.32 G for 32 bit.
definitely some tangible savings.

now i tried some 29 tabs, same here. the difference scales with memory use. difference is now passed 1 G

since i get more mileage per ram, isnt it fair to say that 4GB in 32 bit is more like 6 in 64 bit mode? so the cap is not even that bad, i mean really depends on your requirements.

32x should be more popular

It’s far more likely your shitbox is so slow and outdated that background tasks take such a large % of your system resources that it skews the results.

>>106934318
>>106934325
That's squarely in the margin of error, they're literally less than one sigma away from each other
You're splitting hairs, 64 bit has so many advantages and all disadvantages have been basically nullified by hardware support
babyduckies get the roooooope

>>106933449
16 instead of 8 and it takes black magic to enable them. PPC had 32 from the beginning.

>>106936806
nah, i basically turned them all off.
slackware is pretty quiet by default.

its a 4th gen intel i5, so its fairly old now.

anyway, as someone pointed out, the only real advantage is the lower memory usage.
no one can dispute that.

>>106938291
for me, its the memory gains.

i have run out of memory many times before so this is pretty good for me.
its always the browser using the most memory on my computer.

certain compilation jobs can also be memory hungry but for those i just lower the job count.
>>106936781
my kernel config has no x32 by default.
no one seems to care about it unfortunately.
gives me a reason to recompile the kernel.

many programs never even need that one process gets more than 4gb. i doubt that firefox needs more than that for any given subprocess it launches.

i tried 'stress' and stress can definitly eat up more than 4 on the 32 bit version depending on how big each spawned memory hog is so if you spawn 20 hogs with 256mb each, you obviously go above 5 gb usage.

as soon as you tell one worker to use more than 4gb, it crashes like its supposed to on 32 bit

>>106938543
performance gains from better cache residency.

How long y'all all been on 64 bit?
I switched when I first got an Athlon64 CPU way back in the day, when it was actually wildly inconvenient to do so, but I wasn't about to run no 32 bit OS on my 64 bit CPU. That was back when GNOME was still good, and then they first started fucking shit up, back in the KDE 3 days. I remember you had to do hacky bullshit to use 32 bit Firefox for Flash player to work lol.
I also only had 512Mb of RAM so there was literally no point lmao.

>>106939906
i've on 64 for some 15 years.
in the beginning i definitely noticed the machine got heavier in most regards.

>>106932805 (OP)
The point of 64-bit (at least the way x86-64 implements it) is not just the memory, you could access arbitrarily large memories with 32-bit anyway though it requires you to jump (pun intended) through some hoops.
64-bit allows your CPU to access more bigger registers, which is like super fast almost instantaneous RAM. By having access to more registers, your 64-bit programs can do some fancy optimizations like fitting 8 8-bit variables in one 64-bit register, and then you need a specific one you can access it or modify it with a couple of CPU cycles instead of loading it from RAM or cache which is orders of magnitude slower.
In CS uni in Computer Architecture one exercise had us write MIPS assembly that fit 4 8-bit numbers on one 32-bit register and then adding all 4 numbers with only 1-2 MIPS assembly instructions on each loop iteration. Much faster and less wasteful than putting those 4 numbers on 4 separate 32-bit registers and then making 4 separate additions.

tl;dr 64-bit should be faster as well. If it's slow something's wrong with your setup.

>>106932865
It's called ECS

>>106940018
whats your opinion on x32 then? didn't they try to get best from both worlds?

>>106932805 (OP)
64 bit solves so many problems. and you complaining about higher memory usage is so out of touch when we have tons of memory nowadays. go back.

>>106940145
>repeating the same stuff everyone heard since 30 years.

its simple.
have a browser.
notice hugely decreased memory usage when using i686 or x32 version
conclude that it can be useful to save memory without sacrificing 64 bit computing -> try x32.

the cpu literally has to work on less things while still being able to use 64 bit instructions. thats what x32 allows.
in some cases, this is objectively superior and whatever trade-off is balanced out by less memory use.
obviously it makes most sense where there is not enough memory.
i dont see any problem

>>106940083
To a 32-bit program your Ryzen 9 OVER 9000 Ultra AI MAX looks like an overclocked Pentium 4. There's no "best of both worlds" here. The ability to execute 32-bit programs on modern processors (i.e. anything non-Atom made since 2008) is just a compatibility mode for old programs. You're leaving parts of your CPU unused if you run 32-bit shit on it.
Also browsers hogging all memory is a meme concern. Modern browsers are proactively hogging all RAM for themselves to enhance benchmark numbers, if your system doesn't have a lot of memory installed, the browsers magically won't need 10+GBs of RAM, like my 2008 X61 that has 2GB RAM and runs Firefox just fine albeit it's kinda slow on media heavy pages. You can even tweak them to not spend so much memory.

>>106940356
read this first
https://en.wikipedia.org/wiki/X32_ABI

>>106940272
you seem to be a nocoder, so I have to adjust my response. we solved problems that needed wider registers back before 64 bit was mainstream. we can still do that, but why? 64 bit makes many things much easier and simpler to implement. we already went from 8 bit to 16 bit, 16 bit to 32 bit and it was always this blah blah blah. there will be no 64 bit to 128 bit, but many things will transition to tensor accelerators. so stop whining and appreciate the progress.

>>106940356
they even added some memory feature called Shadow Stacks to the x32 abi in 2024 so there is definitely some niche interest around it.

>>106940383
>>106940419
ok that looks like a more reasonable compromise. It looks quite niche tho.

why do video games still make me install 32 bit libraries

>>106940417
i get it, its not worth the effort maintaining since there is no market for this.

still, x32 is not the same as i686 which you refer to right? x32 is made for 64 bit processors, you cant run x32 bit stuff on old 32 bit processors.

i understand the difference between the 3 architectures.
x86(classic),
x86-64 (64 bit cpu only)
x32 (64 bit cpu only)

i'm already recompiling the kernel to try this out.

>>106940477
Because they're either 32-bit or their launcher is 32-bit. :^)

this was CERN's own experience with the Linux x32 ABI.

>https://cds.cern.ch/record/1554547/files/LHCb-PROC-2013-033.pdf

>>106940018
>instead of loading it from RAM or cache which is orders of magnitude slower.
loading things from L1 cache is not really much slower than from registers.
L1 cache is basically just extra registers

>>106942069
>we wrote object-oriented bloatware that uses billions of layers of indirection so we need a supercomputer to run it but even that's not enough so we had to enable all these settings to reduce the memory usage
lmao, retards

a zilog80 and Fuzix is all any faggot on this board needs but they’ll never accept it

>>106932840
>>106934382
>>106934397
>i'm not going back to 32 bit linux because they are phasing it out in a year or two
what you disingenuous faggots fail to mention is that it only affects i386 native 32-bit CPUs which are probably older than you. x32 is still supported and so are 32-bit ARMs

>>106940145
>you complaining about higher memory usage is so out of touch when we have tons of memory nowadays. go back
kill yourself

>>106940417
>you seem to be a nocoder, so I have to adjust my response
you seem to be a nocoder, so I have to adjust my comment
Java uses compressed 32-bit pointers to address 32GB of memory exactly because a) it uses less memory and b) by not having to load unnecessary data you improve cache usage

>>106942925
Shut the fuck up you retard, nobody lies your jeetposts.

We'll do what we want and if that means using BSD instead of Linux, so be it. BSD has fewer NSA niggers trying to shit it up.

Didn't Linus threaten to kill the x32 ABI?

op here again.
i ran the re-made kernel debootstrapped the only big repository i know of which is the debian x32 port.
it is not exactly maintained well, barely anyone uses it. read somewhere that at some point only 18 users were using it or something.
i couldn't find any firefox in the repo to try it out and i can't be bothered compiling firefox right now so i went back to the normal kernel.

i discovered something else.
did the fair comparison that i was talking about comparing only the official builds of firefox and not my distribution's 64 bit firefox vs the official 32 bit firefox.

the official 64 bit performed better than the official 32 bit.
about 6.8 for 64 and about 6.3 for 32

testing the distributions firefox 64 netted a lower speed. than both official builds by almost a full point about 5.8.

the memory footprint is still larger in both 64 bit builds vs the official 32 bit build.
in the end, 64 bit seems to be at least equal or faster but without the memory savings so i'm still not decided. will have to do more testing between the two now that i know i have to skip the distro one for now.

wonder why the distro build is slower in that benchmark..

why not go even further
return to 16 bit