Linked by Thom Holwerda on Sat 3rd Feb 2018 14:15 UTC, submitted by Drumhellar
Mac OS X

When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall.

This is good. I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology.

Thread beginning with comment 653541
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Not a good thing
by ahferroin7 on Mon 5th Feb 2018 20:21 UTC in reply to "RE[2]: Not a good thing"
ahferroin7
Member since:
2015-10-30

Again, as I said in the second half of my comment, you get 8 more general purpose registers when running in Long mode (64-bit mode) on an x86 CPU, which can be pretty damn significant in terms of performance. For reference, 16 and 32 bit x86 have 4 GP registers (which aren't even entirely general purpose in the original ISA, as they have odd hardware level restrictions on which instructions use them for what), while the Motorola 68000 has 8, ARM has 15 (pre ARMv8) or 31 (ARMv8 and newer), MIPS has 32, SPARC has 31, PPC has 32, and IA-64 (Intel's now defunct Itanium ISA) has a whopping 128. More general purpose registers means you need to make fewer memory accesses when working with small amounts of data (or don't have to regularly load and store frequently used values), which is a huge performance boost in many cases.

You also get a measurable boost in performance for math operations involving potentially large numbers (which is also pretty big, as a lot of I/O calls use 64-bit numbers so they can deal with files bigger than 4GB), and moving data to and from memory becomes a bit more efficient in some cases (this really depends more on the memory controller and how the memory modules are connected, but in general a single 64-bit load from RAM is going to be more efficient than two 32-bit loads, even if it's just because the CPU only has to execute one instruction instead of two).

There's also the fact that many of said 64-bit laptops support more RAM, they just don't ship in such a configuration, and while 32-bit x86 can handle a larger hardware address space through PAE, handling of that is a pain in the arse for OS developers and actually can hurt performance pretty significantly relative to not using it, and more importantly that purely 32-bit x86 consumer CPU's aren't really produced anymore beyond some Intel options that are more solidly targeted at ultra-compact embedded designs but for some reason still get used by laptop manufacturers.

Reply Parent Score: 2

RE[4]: Not a good thing
by Kochise on Mon 5th Feb 2018 22:34 in reply to "RE[3]: Not a good thing"
Kochise Member since:
2006-03-03

Well, the 32 bits memory barrier is also dependent not only on PAE but also the BIOS's ability to offer memory remapping, which not everyone allows. My AMD A8 x64 get stuck at 2.25GB of RAM under Windows XP, not matter what, because of this stupid BIOS limitation, even though it features 8GB of memory.

I also understand your register concern, I'm a 68k and SH-4 assembly coder, and I know too well how much these ISA are vastly superior to x86, which despite its flaws bred pretty well its retard architecture at rabbit pace. AMD64 only closes a little bit the gap.

I've made quite challenging graphic processing using byte/word register swapping to avoid as much as possible memory access, abused 64 bits registers to do fixed point color scale dithering, with the expected throughput increase, so I can confess it works.

But the memory consumption, God, Windows x64 is just such a resource hog, Chrome or Firefox with ten tabs open will make any PC with "just" 4GB crawl like a dry snail. How can it be possible, how can it be just acceptable ?

Reply Parent Score: 1

RE[5]: Not a good thing
by ahferroin7 on Tue 6th Feb 2018 12:30 in reply to "RE[4]: Not a good thing"
ahferroin7 Member since:
2015-10-30

Actually, that's the web browsers, not Windows (Chrome on my Windows system sits at roughly 750MB resident with the 16 extensions I use, but is still about 720MB on my 64-bit Linux laptop with the exact same set of extensions and tabs), although Windows is pretty damn bad too (about 20-50% higher memory usage than an an equivalent set of services on Linux).

The problem is that memory efficiency isn't really a developer priority unless they're working with particularly small systems, because it's not something that end users really notice in most cases (that is, if there are memory efficiency issues, they show up as performance issues for most end users). For the example I gave above with Chrome, that 30MB difference is essentially nothing as far as most developers are concerned (and TBH, with 16GB of RAM, I consider it not worth worrying about either).

Reply Parent Score: 2