[Windows] The death of Win32 and 32-bit itself.

[GoldenPorkchop80]

Honestly, I cannot emphasize how happy I am that THIS DAY HAS FINALLY COME!!!

Windows 32 and, really, the entire 32-bit instruction set and system has been a pain in my rear end once 64-bit systems became more accessible.
Please do realize, that I have been a bit behind when it comes to Factorio news, because I can't really play the game as often as I want to.
But when I heard the news that Factorio will eventually be dropping 32-bit updates and builds, I WAS OVERJOYED, AND I STILL AM!

For those who don't know what this is:
32-bit and 64-bit are different types of processor architecture. 32-bit is more reliable, and 64-bit has more speed.
Lately, though, engineers have been making breakthroughs in 64-bit arc's to make them much, MUCH more reliable, while
keeping the speed intact.
So, now, 32-bit is basically dead. There's no real merit or advantage of using a 32-bit system, since 64-bit now beats it in pretty much
every area. The only people who still use 32-bit systems are grandparents who decided to keep using Windows XP even though Microsoft stopped
providing security and system updates after they dropped support, or desk jockeys.

So, really, I am overjoyed. Now the devs can focus on making ONE game better instead of 2.

[ledow]

Programs have been able to make use of more than 4Gb for ages.

Computers have been coming with more than 4Gb by default for ages.

Processors have been 64-bit capable for ages.

Operating systems have been 64-bit for ages.

It's really been longer coming than it should ever have been. Sure, it's a pain if you stuck to 32-bit, but there's nobody who SHOULD have been given 32-bit on a machine that they've bought in the last 5 years at least. I've been having arguments with workplaces for years that they should be 64-bit by default whenever they refresh or upgrade, and so far NOBODY has suffered from doing that - just the opposite. I can name any number of places that would have had to re-do all their clients all over again within only a year or two if they'd stuck with 32-bit.

From a programmer's point of view, it's just a recompile and you're done. And saves so much hassle.

It's the poor unfortunates that can't afford a new computer that I feel sorry for, because I went through the whole 286/386/486/Pentium/MMX/etc. debacles any number of times - IDE LBA limits, FAT16 limits. etc. etc. etc. I know it's never nice but it's precisely because I was trying to cling on to hardware as long as possible.

Games are increasingly demanding far more than 4Gb, and if you want to switch between them and other programs, you really need more RAM, which means 64-bit support too. And now games are enforcing the 64-bit requirement too, it's time to move if you haven't already.

[prg]

32-bit is more reliable, and 64-bit has more speed.
Lately, though, engineers have been making breakthroughs in 64-bit arc's to make them much, MUCH more reliable, while
keeping the speed intact.

...what?

[Yoyobuae]

I personally would've liked the 32-bit binary to remain available. ARM devices are still 32-bit and the efficient x86 emulators for ARM support only 32-bit.

But I also understand the issues that can cause for multiplayer. So I guess my mobile factorio dream will have to wait (there were other significant hurdles besides 32-bit anyway, like OpenGL VS OpenGL ES).

[Xeanoa]

I personally would've liked the 32-bit binary to remain available. ARM devices are still 32-bit and the efficient x86 emulators for ARM support only 32-bit.

ARM processors have moved to 64 bit already.

[Yoyobuae]

I personally would've liked the 32-bit binary to remain available. ARM devices are still 32-bit and the efficient x86 emulators for ARM support only 32-bit.

ARM processors have moved to 64 bit already.

Not all devices. At least not the devices I care about (ie. Linux handhelds).

[Daid]

I personally would've liked the 32-bit binary to remain available. ARM devices are still 32-bit and the efficient x86 emulators for ARM support only 32-bit.

ARM processors have moved to 64 bit already.

At great cost of power per watt, for the processors that support it. And new processors are made that do not support 64bit ARM. Due to the simple fact that power is not free, and battery power is important in quite some applications.

But ARM never had the x86 32bit problem. Which is a great lack of general purpose registers. The difference between 32bit and 64bit is much smaller if you compare 32bit Pentium 4 vs 64bit for example. (A computative expensive application I had became 40% faster just changing the compile options to pentium 4 instead of i368) due to the added registers and better instructions. Without having a single customer complain that the application no longer ran. (This was 5 years ago)

We are also switching to 64bit per default right now. Simply because it is faster and less out of memory issues. However, in general it is not a big problem to support both. Except in a few rare cases. The complexity of Factorio's network code is one of those examples.

[PunkSkeleton]

32-bit and 64-bit are different types of processor architecture. 32-bit is more reliable, and 64-bit has more speed.
Lately, though, engineers have been making breakthroughs in 64-bit arc's to make them much, MUCH more reliable, while
keeping the speed intact.

Sorry but this is simply not true. There was never a problem with reliability of any instruction set - it simply works. The only real problem was support for legacy applications on 64-bit OS version but this is working correctly at least since Windows 7.
The other myth you are referring to is that 64-bit is faster. Yes it is in theory but not twice. Why? Because 64-bit operands are not used that often, especially with applications optimized for speed (like games). It makes absolutely no difference in speed if you add two integers or two floats in 32-bit or 64-bit mode - you can still do one such operation at a time (per ALU but parallelism, including SIMD is another story). The main gain in speed is for applications that use 64-bit data. The other improvement is due to the fact that more registers are available but compilers needed to be upgraded to use all of them. Also very fast caches and shadow registers in modern processors diminish the gain from having more visible registers on x86-64 architecture.

Someone also said that moving from 32-bit to 64-bit needs only recompilation. As someone from Factorio staff already said - it is NOT true.

And FYI: I am not a fan of x86 and its limitations and it's good the world is moving forward.

[bobucles]

You're 10 years late to the party. The first serious 64 bit computing started in 2006 and they've been killing 32bit CPUs ever since.

64 bit integers render most uses of floats to be pretty obsolete. For example you can map every single millimeter of space inside our solar system from the sun's core to the outer reaches of Pluto using 64-bit integers. A float over a hundred bits large loses this level of accuracy before reaching out from the sun's core to its own corona. All finite human numbers such as inventory values and anything subject to linear growth can be stored and handled as 64-bit. A good deal of incremental games can even be contained completely inside a 64-bit integer.

There isn't much reason to use a float where 64 bits of integer (or a decimal shifted int I.E. 20 == 20.00) can get everything done.

[MeduSalem]

32-bit and 64-bit are different types of processor architecture. 32-bit is more reliable, and 64-bit has more speed.
Lately, though, engineers have been making breakthroughs in 64-bit arc's to make them much, MUCH more reliable, while
keeping the speed intact.

Sorry but this is simply not true. There was never a problem with reliability of any instruction set - it simply works. The only real problem was support for legacy applications on 64-bit OS version but this is working correctly at least since Windows 7.

Maybe with the "reliability problem" he was referring to the abysmal 64-bit driver support for 64-bit Windows at the beginning of the x86-64 era. I remember it used to be pretty ugly for a lot of those people who plunged into 64-bit computing early on.

Back then I got myself an AMD 64 4800+ X2 quite early on and with it I used Windows XP Professional x64, which was actually based on Windows Server 2003 branch just with the regular XP Desktop Shell.

Since I used pretty high-end hardware I had luck with the driver support, but a lot of other people using no name hardware couldn't get their computer to run properly on 64-bit hardware using the 64-bit Windows, which lead to an initial bad reputation.

It only became a lot better with Windows 7... even Vista had its share of problems related to 64-bit drivers and software.

The other myth you are referring to is that 64-bit is faster. Yes it is in theory but not twice. Why? Because 64-bit operands are not used that often, especially with applications optimized for speed (like games). It makes absolutely no difference in speed if you add two integers or two floats in 32-bit or 64-bit mode - you can still do one such operation at a time (per ALU but parallelism, including SIMD is another story). The main gain in speed is for applications that use 64-bit data. The other improvement is due to the fact that more registers are available but compilers needed to be upgraded to use all of them. Also very fast caches and shadow registers in modern processors diminish the gain from having more visible registers on x86-64 architecture.

True. I think that the only real benefit is actually the largely increased amount of RAM one can pack into your computer due the 64-bit address range. Though it was already possible to go beyond 4 GB of RAM in 32-bit systems with PAE crap but that wasn't really that efficient and felt really awkward in general.

Also the additional Instruction Set registers that AMD introduced with x86-64 were almost a waste in my opinion... ever since Register Renaming is a thing (which came a long time before 64-bit already) they can have as many Registers in the background as they want independently from what is specified in the ISA and they even profit legacy 32-bit software. So the additional registers artificially bloated the Instruction Set due to maintaining orthogonality... and it only became an even more spectacular mess with the SIMD madness.

But I bet if they would have the possibility to design a new ISA from scratch they would completely design it around SIMD stuff anyways... One can look into Intel's AVX/AVX2 and upcoming AVX-512 specifications and see how they completely changed the way they are going to implement future Instructions Set expansions. They'd never do it the way they originally designed x86 anymore. Nowadays they'd probably rather have non-destructive instructions and using Opmasks for almost everything, reducing the amount of different instructions to handle greatly which in turn would make the whole prefetching/predication part and on-the-fly analysis of instruction-level-parallelism a lot easier to implement.

I personally would've liked the 32-bit binary to remain available. ARM devices are still 32-bit and the efficient x86 emulators for ARM support only 32-bit.

ARM processors have moved to 64 bit already.

At great cost of power per watt, for the processors that support it. And new processors are made that do not support 64bit ARM. Due to the simple fact that power is not free, and battery power is important in quite some applications.

Another problem I see in ARM is that ARM itself doesn't really manufacture any competitive CPUs so they don't really set the bar too high themselves. Instead the implementation of cutting-edge processors for the ISA is left to third-party companies which there are way too many of, most of which don't give a crap about upgrading their product lines to 64-bit ARM designs. The only ones doing it are for high-end Smartphone/Tablet devices which maybe make up the top 5% of all ARM chips sold. The rest is happily ever after using the 32-bit designs.

So it will take quite a long time until the entire ARM sector catches on the 64-bit train. Not only for power reasons... just because most of the companies there are lazy laggards.

But commenting on the power part itself... Most of the Smart Phone companies using 64-bit designs don't care about the power consumption. They figure that the target audience will buy the top-end smart phones no matter if they are absolute battery-hungry nightmares. So they don't even consider optimizing the 64-bit design around power consumption. If they really would consider it then they wouldn't go for ridiculous 8-core designs that increase the total power consumption by magnitudes in the first place... and as far as I know all currently available 64-bit chips implemented in consumer devices are 8-cores.

[BenSeidel]

So is this a question about the cpu architecture or the software running on it?
If it's the architecture, the 64 bit era is not as nice as everyone remembers. Intel's 64 bit CPUs (IA64) were abysmal, having no backwards compatibility with the x86 architecture. It wasn't until AMD released the now default x64 architecture that things started to look promising.

If it's software, it doesn't matter what architecture you run on, it's going to crash.

[MeduSalem]

If it's the architecture, the 64 bit era is not as nice as everyone remembers. Intel's 64 bit CPUs (IA64) were abysmal, having no backwards compatibility with the x86 architecture. It wasn't until AMD released the now default x64 architecture that things started to look promising.

That is not entirely true.

Intel had implemented an emulator to run x86-32 code on the IA64-based Itanium, even with the help of the hardware to a certain degree but the performance was so goddamn awful that it was nowhere able to compete with Intel's own native x86-32 chips. The native x86-32 chips of the time were somewhere like 10 times faster than what Itanium's emulation could deliver. Intel thought that due to lack of adequate x86 support the software companies would migrate a lot faster to native IA64. But since that didn't happen a lot of effort went into trying to make the emulation more efficient and increase the performance but the train had already crashed and nobody wanted to be the guinea pig for HP & Intel anymore so they screwed up their one-time chance to move on to a new age. Intel and HP both truly underestimated the Software industry and its unwillingness to migrate to any other Architectures except if it actually suits their needs.

And this unwillingness can be seen until this day because it took like 12 years for most software companies to finally start bringing native x86-64 software and abandoning their x86-32 branch.

If I think about it I also don't believe that Microsoft even with its market dominance on the OS sector could have done anything to make the transition go any faster because even if they would have never sold 32-bit copies of Vista/7/8/10... the 64-bit Windows systems still have the entire 32-bit Windows-subsystem for compatibility reasons with legacy 32-bit software and therefore Software companies would still not have been forced to migrate to native 64-bit. They could have deprecated certain stuff to force them to migrate but then they would probably face a lot of resistance from the software industry as well as the consumer market, which might have driven off everyone to other platforms, even more so than the tablet/smartphone madness nowadays does.

If it's software, it doesn't matter what architecture you run on, it's going to crash.

If that's a subtle way of saying Windows sucks then that isn't true either. (I guess you mean that because the thread is basically also about Win32)

Actually ever since the Windows NT Kernel became part of Microsoft's mainstream OS the stability and reliability of Windows systems is quite good. I haven't run into a notorious bluescreen for years. (The last time when my SSD crashed after booting but then every OS would start to choke on itself)

At least I find it better than most Linux distributions which suffer technical teething due to how they lack any co-operative effort or vision. Not to speak of usability problems if one digs far into the unknown hells of distribution forks. It's like jumping over the devil's fork itself. It's what I dislike the most about Linux computing... everytime something becomes more "popular" (like Ubuntu back in its time, or Mint nowadays) the Linux community goes all crazy and condemns it for its popularity... like "uh it's so mainstream, everyone dump it immdiately!"... It's either that or because the programmers and developers can't agree on which technical direction to go and that's what marks the spawn of 10 additional forks thinning out the development resources so progress almost stalls. In my opinion that's the reason why Linux never conquered the desktop and probably never will (apart from commercial closed source software conflicting with the free and open source nature of the Linux project). They don't have the ambition to win co-operatively, rather they set out to conquer each other. It's just a hideous monstrosity, much like a Hydra that begs for an Heracles to come and chop all but one of its heads off.

Yes I said that fully knowing I might trigger hordes of Linux fanbois. But I don't care because I don't feel like toying around with an extremely picky OS just to show off how elite I am. I rather want to work with it.

[BenSeidel]

That is not entirely true.

I don't class hardware emulators as having "backwards compatibility" in the architecture, and that part was purely about the hardware. No matter how fast the emulation could come, it would never viable in a production environment.

It's strange that Intel, a company that spent ALL it's resources developing chips for decades that were backwards compatible would suddenly decide to drop it entirely. Even a side-by-side implementation would have allowed them to win the day. Microsoft have known (they seem to have forgotten recently) that backwards compatibility is essential to business development. Windows 3.x went to great lengths to include DOS application support and Windows95 even had dedicated code to allow Simcity to run (there are articles everywhere about it).

But recently many companies have been dropping their backwards compatibility "guarantees". Oracle and Java is another example. Some have been burnt, some are getting frustrated. I still see many businesses running WindowsXP because their applications don't run on 7. I even set up a VM farm of XP boxes at one place so that they could continue to operate.

And this unwillingness can be seen until this day

I can so agree there. The software industry has known (and should have known) that the CPU clock speeds have an upper limit to them since at least the 80's. The predictions of multicore machines have been floating around a bit in the 90's, but was "big" news in the late 2000's. Yet still we write essentially single threaded code 20-30 years later. Even Microsoft realised that multicore was the way to go and released WindowsNT back in 1993! So yes, even Microsoft can't force us to drink.

If that's a subtle way of saying Windows sucks then that isn't true either

Not just Win32, All software. No matter who it's written by. I still drop to Win32 when I need to, and it's not bad, dated, but not bad. The comment was actually a subtle dig at software developers and their methodologies that really have not changed since they wrote Windows95, and we all remember how that turned out.

Yes I said that fully knowing I might trigger hordes of Linux fanbois

Ahhh! Quick! get a pitch fork! We have tons of them in our code base, SO PLEASE TAKE ONE OUT!

Yes, Linux is a pain in the neck. So are any of the Apple OS's. They all have their issues. I do disagree on the Linux won't take over the world comment though. It's everywhere in the embedded device market. You will find it in just about every router, all the smart TV's, etc. On a desktop though, it's doubtful for the reasons you have already gone through.

[Yoyobuae]

At least I find it better than most Linux distributions which suffer technical teething due to how they lack any co-operative effort or vision. Not to speak of usability problems if one digs far into the unknown hells of distribution forks. It's like jumping over the devil's fork itself. It's what I dislike the most about Linux computing... everytime something becomes more "popular" (like Ubuntu back in its time, or Mint nowadays) the Linux community goes all crazy and condemns it for its popularity... like "uh it's so mainstream, everyone dump it immdiately!"... It's either that or because the programmers and developers can't agree on which technical direction to go and that's what marks the spawn of 10 additional forks thinning out the development resources so progress almost stalls. In my opinion that's the reason why Linux never conquered the desktop and probably never will (apart from commercial closed source software conflicting with the free and open source nature of the Linux project). They don't have the ambition to win co-operatively, rather they set out to conquer each other. It's just a hideous monstrosity, much like a Hydra that begs for an Heracles to come and chop all but one of its heads off.

A bit of misconception going around here. Linux distros are not "out to conquer each other", neither do they "thin out the development resources". The Linux kernel is the same for all distributions. The vast majority of the software is the same at the source level. They are just packaged differently.

Distros also provide a desktop environment, theming, and some defaults. Even those can be changed if desired (or use different flavors of the same distro).

Linux distros are just a bunch of customization placed on top of basically the same software stack. Probably no more different than the customizations that can be done on Windows, if one tries hard enough.

Yes I said that fully knowing I might trigger hordes of Linux fanbois. But I don't care because I don't feel like toying around with an extremely picky OS just to show off how elite I am. I rather want to work with it.

Depends on your line of work. If you work requires a Windows only software, then there's no choice. But if there's good software alternatives on Linux, then it's quite possible to do work with Linux. Development is usually OK, maybe working with graphics (Blender, Krita). Linux video editing software is lacking from what I've heard.

The thing Windows still has an edge on is with gaming. Hardware (video cards specially) get better support on Windows and games often don't have Linux ports (or the port is not very good). But the gaming situation on Linux is always improving (Factorio being a great example of that ).

Yes, Linux is a pain in the neck. So are any of the Apple OS's. They all have their issues. I do disagree on the Linux won't take over the world comment though. It's everywhere in the embedded device market. You will find it in just about every router, all the smart TV's, etc. On a desktop though, it's doubtful for the reasons you have already gone through.

And Windows is a pain in the neck for me.

As for Linux on the desktop, market share doesn't matter. It's like in the movie 300:

You see, old friend? I brought more soldiers than you did!