>there is software still being released in 32-bit in 2018 - 1/12
>there is software being released today that doesn't even have a 64-bit version (e.g. Steam client)
wtf
>there is software still being released in 32-bit in 2018 - 1/12
>there is software being released today that doesn't even have a 64-bit version (e.g. Steam client)
wtf
So?
There's no need for the client to be 64-bit. All it really is is a web browser and some fancy in-game overlays, none of which benefit from the extended addressing capabilities of a 64-bit process.
All your video games are 32-bit anyway you dumb child
>tfw running w10 x86 on my memepad x60
your moms vigiania is 64bits wide tho.
yuck
Slow af without an SSD and sad that it needs one to operate.
>All your video games
definitely not all you dumb faggot nigger
Im kind of on the fence on this issue. On the one hand I see it from the side that industry standards should be continually evolving at roughly the same pace, and 64 bit is empirically "better". But at the same time, most programs aren't using taking advantage of the 64 bit architecture because they don't need to; think, how often do you see a program use over 4gb of ram? Also, if for whatever reason you need to run 16-bit programs, but still have the ability to run 32-bit ones as well, making something 64-bit could potentially eliminate a demographic of your users. Or end up causing wasted money on customer service over and issue that's irrelevant because the program doesnt need the capabilities that 64-bit provides.
At the moment its kind of irrelevant though, unless you absolutely need to run 16-bit programs on a modern machine
MOST games are 64-bit these days
well no shit it does it's like an 11 year old laptop
runs nicely with one though
Not everything needs to be 64 bit. Why do we need 64 bit text editors or image viewers? Or media players, client front-ends like Steam (which essentially renders web pages)?
Until 64 bit instructions are fundamental to all applications (and more than 4GB of RAM usage is trivial) you cant defend needing 64 bit for everything
32-bit OS or programs on a 64-bit CPU are a waste of not only memory, but cycles.
the fastest everything moves to 64-bit the fastest I won't need what is basically an extra copy of the OS installed to run all that 32-bit shit. Not to mention the mess it creates.
-->
THIS
Finally someone gets it
>extra copy of the OS to run 64 bit
An OS is a lot more than lib32's.
64bit application on x86_64 generally have no performance benefits and only defecits in comparison to their 32bit brothers.
If you have enough RAM and CPU power you won't notice it but there's also no reason to make an application that won't address more than a few hundred MB of memory 64bit.
There's plenty of benchmarks about this.
Same system with sub-4GB of memory.
32-bit OS and programs are slower than 64-bit OS and programs.
So are 64-bit OS and 32-bit programs slower than 64-bit OS and programs.
There's more to 64-bit binaries and CPUs then just a memory barrier.
This has ALWAYS been like that.
False. There's a performance benefit.
Sure it's not usually noticeable, but it exists.
Stop being dumb teenagers for once. Sup Forums is full of tech illiterates.
I'm conflicted by those dubs.
>There's a performance benefit.
>Sure it's not usually noticeable
Why should I care about performance improvement that aren't even noticeable?
macOS doesn't have this problem.
why use 64bit if your software could be run perfectly well on 8bit?
Two cycles of 32bit program can be simultaneously processed with 64bit bus.
32bit needs to disappear, I'm tired of dealing with fucking lib32 dependencies.
There is 32bit software for macOS as well.
Apple is dropping 32bit software next release just like they did with iOS 11.
There is no reason for 64-bit unless your application needs more than 2gb of ram
What the fuck does this even mean? You actually have some sort of problem with 32-bit that causes you distress or something?
No they aren't
When is apple gonna drop a security update for root login?
Blah, if devs/programmers actually kept shit to pure functionality standards instead of "oh let's add more wiz bang smoke flashy shit" and "lets add this gimmicky thing that absolutely no one will use" then there would be no need for jumbo install sizes or outrageous system requirements or the need for a 64bit cpu in order for it to install/run/work fine. Perfect examples of products that suffer from this greatly: Windows Ten and Office. Think about it, what do you do now with pc ? What did you do on pc 5 or 10 years ago? If you tally them up I think that you'd get maybe 90% match (assuming your a normal user). Also think about your system specs 5/10 years ago. What has changed? Surely not the shit you do everyday. Has it gotten better? uh, fuck no. if you use Ten, you've actually gone backwards.
Steam doesn't need 64-bit, and the client is already written for 32-bit.
It's an example of "if it ain't broke, don't fix it"
2 days ago.
>64bit application on x86_64 generally have no performance benefits and only defecits in comparison to their 32bit brothers
What am I reading
This is for eligibility for being in the app store only. The OS is still perfectly capable of running 32bit software.
(You)
On most architectures, 64-bit programs are slower than 32-bit ones. x86 is only different because x86-64 also added more registers, standardized on a better ABI and made SSE arithmetic the default for FP.
Even so, though, 64-bit programs use more memory than 32-bit ones, so even if you're on x86, if performance isn't critical for your program (like in the case of the mentioned Steam client), it still makes sense to make it 32-bit just to reduce its memory usage.
Fuck you op. My t60 (>inb4 fell for the Thinkpad meme, I bought it before I lurked on Sup Forums) is 32 bit and because of people like you a lot of shit isn't doesn't have 32bit support and won't ever have it. See discord for Linux, they won't release a 32 bit Linux client, so I have the option of using the web browser or a custom electron desktop wrapper which is literally just the web version on the desktop. I lose access to a bunch of features because of this.
I've got an old X60s with a soldered 32bit processor running Lubuntu. How long realistically will I be able to use this machine for light browsing?
You can upgrade the processor to a 64bit one, like the Intel T7200 or something. That's what I did with my T60.
Buy a new computer.
Hmm: Office full install, over 1GB. "Why?"
Meanwhile, MS Works 4.5a (last good version), only 100mb (Yes megabytes).
Comparison: (Core shit 90% home users actually use)
Word Processor - OMG, they both got it
Database - Again they both got it
Spreadsheet - Again
Calendar - Again
E-mail - Well there's outlook but wait don't MS also have free Windows Live mail/outlook express or don't most fuckers just use Gmail online these days?
Templates - Works wins, most templates in office has been "offloaded to the cloud"
Help - Works wins, again Office help has been "offloaded to the cloud"
>discord
>linux
Stop halfassing it. Either go full botnet or full freefag.
Really? Any resource info? I would like to upgrade this as much as possible.
(You)
Bloat has nothing to do with 64-bit per se.
TempleOS is 64-bit and small, for instance
wired.com
Wrong again, Macfag
Works wasn't even usable back in the day, moron.
Now it's literally obsolete trash.
(Office 2000, on the other hand...)
Ditching backwards compatibility and outdated standards is one of Apple's positive qualities.
Microsoft should take them as an example.
>tfw System32 contains 64-bit code and SysWOW64 contains 32-bit code because Microsoft is too afraid of breaking badly written 3rd party software
The T60 has a socketed CPU, so you can just buy an upgraded processor (T7200 is like $1 literally), open up the casing, remove the heatsink and swap it out before reapplying thermal paste. It will take you 45 minutes maximum. There are plenty of resources available online if you don't know how to do this.
I use teamspeak that I self host, but there's a few projects I do on the side for extra cash that requires me to use it from time to time, custom bot
I built a few desktops before, just was basically looking for info for whatever can be upgraded on it, then also which is the best option for said upgrades. I'll look it up tomorrow when I'm not working. Thanks.
>they won't release a 32 bit
bless them, bless them all
TempleOS is godly and an unfair comparison in any argument.
64bit software is a meme if it doesn't need to use more than 4GiB of RAM
>how often do you see a program use over 4gb of ram?
>more than 4GB of RAM
>64bit software is a meme if it doesn't need to use more than 4GiB of RAM
r8, r9, r10, r11, r12, r13, r14, r15
Also 64-bit programs can map large files completely into virtual memory which increases efficiency by reducing the number of syscalls for file I/O
rtorrent is a Linux program that gains much of its high performance from memory-mapping torrents
>waaah why does my machine from 2006 which was targeted at enterprise users in the first place who replace their computers every 5 years at most no longer work in 2017/18
>why can't people accommodate my 11 year old laptop waaah
Hilarious.
You clearly have no idea what you are talking about, so why even start a thread before duckduckgoing the topic?
msdn.microsoft.com
>WOW64 enables 32-bit applications to take advantage of the 64-bit kernel. Therefore, 32-bit applications can use a larger number of kernel handles and window handles. However, 32-bit applications may not be able to create as many threads under WOW64 as they can when running natively on x86-based systems because WOW64 allocates an additional 64-bit stack (usually 512 KB) for each thread. In addition, some amount of address space is reserved for WOW64 itself and the data structures it uses. The amount reserved depends on the processor; more is reserved on the Intel Itanium than on the x64 processor.
>Also 64-bit programs can map large files completely into virtual memory which increases efficiency by reducing the number of syscalls for file I/O
Page faults are slower than syscalls.
>r8, r9, r10, r11, r12, r13, r14, r15
That's fine and all, but how often does a text editor suffer from performance issues due to register pressure on a modern CPU? Save the memory instead. Or better use x32, have the extra registers *and* the short pointers.
What makes most sense is to use x32.
It does, but it also means that you need libraries installed x86-64, x32 and probably x86 too, which is a bit weird of a situation.
>Page faults are slower than syscalls.
Just in case there is any doubt, here's a comparison of writing a 1-GB with either method.
mmap:
657.516670 task-clock (msec) # 0.995 CPUs utilized
41 context-switches # 0.062 K/sec
0 cpu-migrations # 0.000 K/sec
262,189 page-faults # 0.399 M/sec
1,967,808,056 cycles # 2.993 GHz
1,061,946,993 stalled-cycles-frontend # 53.97% frontend cycles idle
661,049,275 stalled-cycles-backend # 33.59% backend cycles idle
2,615,330,946 instructions # 1.33 insn per cycle
# 0.41 stalled cycles per insn
227,593,925 branches # 346.142 M/sec
212,330 branch-misses # 0.09% of all branches
Syscalls writing 4096 bytes per call:
451.380384 task-clock (msec) # 0.045 CPUs utilized
736 context-switches # 0.002 M/sec
5 cpu-migrations # 0.011 K/sec
47 page-faults # 0.104 K/sec
843,214,044 cycles # 1.868 GHz
461,461,943 stalled-cycles-frontend # 54.73% frontend cycles idle
305,832,248 stalled-cycles-backend # 36.27% backend cycles idle
794,639,453 instructions # 0.94 insn per cycle
# 0.58 stalled cycles per insn
150,033,918 branches # 332.389 M/sec
314,748 branch-misses # 0.21% of all branches
Fucking statically link it if you have to.
10.13.1 was released Oct 31. The patch was released Nov 29.
I still have to support Windows 7 32-bit on desktops with 8GB RAM because our developers still write Delphi code that can only compile on a 32-bit machine.
It's fucking atrocious.
>write new 32-bit software
>need extra RAM, use AWE, get anywhere from 4-20 extra address lines in protected mode
>AWE requests are handled transparently in long mode (AMD64 only)
>don't care about IA-64
Yeah.....
There's a reason AMD64 beat out Itanium...
>having a duplicate of the libraries in every executable is better
While true, I have had to enable 32bit repos just for Steam before... Then you need all the 32bit versions of GPU stuff. Annoying.
>There's a reason AMD64 beat out Itanium...
Are you saying this reason is that Itanium couldn't run 32-bit programs?
That, and i386 code runs at native speed in long mode
Steam is such an awful piece of shit. It's been the one and only OSX app for years running that isn't hidpi.
Dropbox need to get their shit together then.
That only explains Itanium's non-adoption on the deskterp side, though. See picture for why it failed everywhere else (ignoring FP performance, since these were the days of x87 FP on x86).
ix32 is deprecated. If you're running x86 software on x86_64, you're not running native software.
>If you're running x86 software on x86_64, you're not running native software.
What? Are you trying to imply that modern x86-64 processors aren't executing 32-bit natively, or with performance degradation?
>ix32
There is no such term.
>performance penalty in protected mode
>Because the full x86 16-bit and 32-bit instruction sets remain implemented in hardware without any intervening emulation, these older executables can run with little or no performance penalty...
i.e. the performance penalty is imposed at the operating system API/ABI layer (think WOW64)
otherwise, as IPC or clock speed increase, both i386 and AMD64 code benefit from the increase
>r8, r9, r10, r11, r12, r13, r14, r15
Doesn't register renaming and x86 cpus having more registers than are available to the programmer make these not that useful?
No, the point is that more registers are available to programs, so that they don't have to spill values to memory.
What are you talking about? I can't even tell if you're agreeing or disagreeing with me.
Whilst nearly every device I use (Spare some embedded SBC's) is 64 bit, I see no reason that everything needs to use it, lots of stuff simply doesn't benefit from it.
Unless the program itself uses more than 4GB RAM, and it's not dealing with big chunks of data, it's kinda pointless.
>it's kinda pointless
In and of itself, it is, but retaining the ability to run both 32- and 64-bit programs entails having all of their dependencies in 32- and 64-bit variants as well.
>Get 64 bit computer
>Run only 32 bit programs
>Everything's twice as fast
That's the problem, if you don't have 10.13.1, patch, then update to 10.13.1, the update overwrites the patch
>TFW 10.12
Fuck updating, no "Allow apps from anywhere" was enough.
Fair enough. I only just realised the reason 64 bit windows version where so big was because they had so much 32 bit shit in them.
Fuck it all, ditch 32 bit I say!
oops, meant to reply to
Fuck
Sure, in case everything you're doing is 64-bit arithmetic. In the real world, however, 64-bit arithmetic is pretty rare, even on pure 64-bit systems.
Whereas on the other hand, you're now wasting half your cache since pointers are larger even though you don't need them to be.
He's right you know.
But it could be said about every version of Windows(heck even Linux distros).
Bloat is everywhere making sure even if hardware gets magnitudes faster, our programs get comparably slower as time goes on.
It's pretty sad.
its because people arent writing shit in assembly or C for everything these days