Friday facts #158 - The end of the 32 bit era

[Kryzeth]

I support your discontinuation of 32bit version. The needs of the many outweigh the needs of the one percent! Or something like that

[bobingabout]

How do I 16bit?

Personally, 64bit isn't the future, 64bit is the present. 16bit was brilliant back in 1984, but it is time that 32bit became the past. 128bit is the future, and 256bit after that.

And in a world where the processor is starting to reach it's limits in speed and miniaturisation scale (Because, get much smaller, and you start getting quantum tunnelling issues) we have already started looking into paralleling things (Multiple processors, then multiple cores within a processor. You can have systems with up to 24 physical processing cores from what I understand). Unfortunately, even though people have been doing it for 10 years or so, multithreaded programming still needs some encouragement.

128bit and 256bit systems are basically just another way to parallel things up. I'm sure 64bit did that sort of thing too, but I know a lot of it from the programming perspective was basically just allowing you to work with bigger numbers.

Having said that though, I'm still unsure of the proper universal method of declaring a 64bit variable in C/C++. Last time I looked into it about 3 years ago, windows did one thing, while Linux did something else, and some versions of Linux defaulted to 64bit when specifying an int. I kinda quit programming (or more accurately put it on hold) to mod Factorio.

[hansinator]

@bobingabout This is a little OT. You're having a wrong understanding of things. x86 processors today can handle arithmetic with numbers larger than 64bit, specifically 128bit with AVX instruction set extensions and 256bit with AVX2. Then there's also AVX512.

The 64-bit thingy is mostly about the CPU internal data-paths and memory addressing width with memory being the key point. A 32-bit architecture can adress just 4 GB of memory whilst 64bit can handle 17179869184 GB (16 million terabyte) of memory.

So if 128bit or more is the future, then this future is very far off. 128bit allows you to address more memory locations than there are atoms on earth. It's overkill even for the next 100 years I'd suppose.

[hoho]

128bit is the future, and 256bit after that.

It's extremely unlikely that either of those would come to fruition in foreseeable future. We'll probably have a completely new architecture with radically different concepts for computing and memory before moving x86 to >64bits.

There were two main reasons for going to 64bits:
1) breaking the 4GB memory limit
2) getting more usable CPU registers

With 64bit, possible memory support is so massive that you could store all the contents of Google servers in that memory space.

Adding extra registers won't make much sense as with SIMD, modern CPUs already have added a LOT of registers to x86-64 (IIRC AVX-512 has 16x more register space than SSE2).

Even changing memory bus width doesn't require a new processor architecture. Modern CPUs already have effective 128bit memory interfaces.

So, yeah, you can be quite certain that x86-64 will be here for a while with no replacement in sight.

You can have systems with up to 24 physical processing cores from what I understand

Yes. Intel has server CPUs with 22 physical/44 logical cores and you can have two of them in same case. For special cases they also offer "massively parallel CPUs" with 72 physical/288 logical cores per chip.

Unfortunately, even though people have been doing it for 10 years or so, multithreaded programming still needs some encouragement.

True, people aren't doing all that much multithreaded programming.

Problem is, a LOT of stuff computers are used for aren't all easy to parallelize. There are bottlenecks that limit the amount of parallelization that one can do. E.g in Factorio, you need to gather up all the calculations from various threads at some point before being able to continue. When sorting things, no matter how tiny pieces you split your dataset to, the final merge of individual solutions will be limiting the overall speedup you gain: https://en.wikipedia.org/wiki/Amdahl%27s_law

128bit and 256bit systems are basically just another way to parallel things up.

No, not really. At least not more than going from SSE2 to AVX-256 did and, just as with parallel processing, going to wider SIMD units won't really benefit in most situations.

I'm sure 64bit did that sort of thing too

Not really. Going to 64bit architecture in itself didn't improve parallel computations one bit.

but I know a lot of it from the programming perspective was basically just allowing you to work with bigger numbers.

True, goin 64bit allowed for "native" computations on 64bit integers. "Problem" is, before 64bit architecture you could do same sort of calculations in MMX registers and vast majority of calculations aren't really using 64bit ints in first place so benefits are questionable at best.

Having said that though, I'm still unsure of the proper universal method of declaring a 64bit variable in C/C++

Standards say it's int64_t or uint64_t depending if you want signed or unsigned integer.

Last time I looked into it about 3 years ago, windows did one thing, while Linux did something else, and some versions of Linux defaulted to 64bit when specifying an int.

You confuse compilers with operating systems
Yes, visual c++ has some weird ways of defining integer sizes and GCC has also supported their versions for equivalent things. Good thing is that both also support the things listed in the standards.

As for int defaulting to 64bit, that's what standards say - int should be the most efficient type of integer the underlying CPU supports. For 64bit machines that's 64bits. For others it can be something else. It makes a whole bunch of sense once you learn what and why the standards say.

[White-Tiger]

[...]

Actually, this is not true. My PC still has a 32-bit processor, an AMD Sempron 140 and still is able to play factorio with bobs mods. So that is really just not true.

Sempron 140 is a 64bit CPU:
http://www.cpu-world.com/CPUs/K10/AMD-S ... OX%29.html

Apparently not all of the semprons where 64-bit..
http://www.hardwaresecrets.com/how-to-i ... pron-cpus/

Not all Semprons
Yes all Sempron 140's

Yep.. since it's actually an "Athlon II X2" so the "single core" is a dual core with one core disabled... besides that CPU isn't even that old... being AM2+/AM3

But even though most CPU's (>99%) might be 64bit by now, there's still a valid reason why one would stick to 32bit.. that is if the system got less than 4 GB of memory. 64bit will use up more of your free memory... it's a fact. And being <4GB means you're already pretty low on it.

[...]
Having said that though, I'm still unsure of the proper universal method of declaring a 64bit variable in C/C++. Last time I looked into it about 3 years ago, windows did one thing, while Linux did something else, and some versions of Linux defaulted to 64bit when specifying an int. [...]

Well... int should be 32bit, even on 64bit platforms, even on GNU/Linux by now. But long means 64bit on GNU/Linux while it's still 32bit on Windows which requires long long
Though there's always int32_t, int64_t and so on. Might not look as nice, but it got the correct size
Supporting both 32bit and 64bit platforms is mostly hassle free, code just runs on both (though, not necessarily as fast on 32bit if code makes heavy use of 64bit arithmetic) That is, unless you need atomic 64bit operations... because 32bit platforms can't do them usually. But who needs these anyway?
I'm even writing stuff that still supports Windows 2000, it's surprisingly easy because it has been the NT architecture already... so doesn't behave much different to Windows XP. Only difference there is stuff that later OS's added, like 64bit (WoW64), UAC elevation, file protection, multi-user support, DWM and some more. But that's usually optional stuff I don't need myself

[Oxyd]

Supporting both 32bit and 64bit platforms is mostly hassle free, code just runs on both

Except that in practice – at least in Factorio practice – there are subtle differences between the resulting 32-bit and 64-bit executables, which then lead to desyncs, which are fairly time-consuming to debug and fix.

Unfortunately, none of us is a prodigious whiz-kid for whom debugging desyncs is “mostly hassle free”.

[White-Tiger]

[...]
Except that in practice – at least in Factorio practice – there are subtle differences [...]

I would like to know which ones...
The related changelog mentioned floating point arithmetic which can't be used anyway... since floating points have different implementations even on the same platform and from the same CPU vendor.

Lua might also work if all platforms use the same configuration, that is the same bit size for numbers and so on... There are games like Warframe that use the same precompiled Lua code for both 32bit and 64bit although it's not usually supported by Lua.

[Balinor]

Secondly, TOS don't really mean much at all what matters is consumer law and in some places you may be forced to offer a refund for things being different than at the time of sale, just fyi.

Well we have made things very clear, on our site we promise you will have access to all future factorio updates for free,
However we make no promise of the game content, and it would be impossible to develop any software if we refunded our supporters for every decision they didn't like.

In the end we aren't trying to screw over our 32 bit players,
It is just better for the game development and the rest of the community for the sacrifice to be made,
And with any change to the game, some people won't like it of course,
But we hope we can keep the communities trust to do what is best for the game

Oh I certainly understand where you guys are coming from and as I said the switch to 64bit doesn't affect me but is a good thing (as far as I am concerned, biased because I'm already on 64bit obviously). I was also just pointing out that it could probably have been handled a little better and that you also have to understand the anger coming from people that may be stuck (for whatever reason) on 32bit machines. The original quote was just to show that "we can do whatever we want and you can do nothing" is not a great attitude nor is it one that is likely to go down well if someone were to make a complaint to their local consumer/trade group after being denied a refund for something that seems pretty fundamental.

Wube sold access to a finished game for 32bit machines and are now not delivering. There are definitely grounds for issuing refunds in certain cases there and I expect most consumer protection groups would happily come down on the side of refunds.

Still, hopefully this can be resolved amicably enough for everyone and I can't wait to see what .15 brings.

[SoulForge]

Yep.. since it's actually an "Athlon II X2" so the "single core" is a dual core with one core disabled... besides that CPU isn't even that old... being AM2+/AM3

AMD has been using those sockets for a long time now so not really a valid thing to say.

That processor is around............7 years old.

But still 64bit capable even if slowly.

And honestly anyone who is still using 32 needs to upgrade. This game is still in development. The programming gods are working there way through adding things they want and fixing stuff. At some point a new feature or fix may not play well on old hardware. Thats just the way it is with still in development games.

[lingnau]

And that's why you don't buy games in EA, Devs like to change things and fuck you up.
Hope we get 1.0 before they stop supporting 64 bits

I guess we could also drop 64bit support in 0.15.

Of course that would mean no one would be able to play the game, but we have a right to do that, don't we? Everyone agreed to the Terms of Service which clearly state the cases in which you're eligible for a refund and that we can change anything at any time just because we feel like it.

I don't see any harm in dropping 32-bit support, but still no reason for being a d***. You're not eletronic arts (hurray), don't try to be.

[hoho]

But even though most CPU's (>99%) might be 64bit by now, there's still a valid reason why one would stick to 32bit.. that is if the system got less than 4 GB of memory. 64bit will use up more of your free memory... it's a fact. And being <4GB means you're already pretty low on it.

Yes, in 64bit pointers have twice the size and so do some int's you've not declared specifically as 32bits. In reality, that's just a few percentages of more memory used. As long as you aren't completely out of RAM, you'll likely gain more performance from 64bits thanks to having more general purpose registers available for the code to run on.

Highest memory differences I've seen between 32 and 64bits have been extremely pointer-intensive applications that have had about 20% increase in memory usage. For majority of "normal" applications, it's <10%.

[Rseding91]

The related changelog mentioned floating point arithmetic which can't be used anyway... since floating points have different implementations even on the same platform and from the same CPU vendor.

No they don't. We use floating point numbers (float and double) all over the codebase without desync issues. In fact we have a multitude of tests that ensure they are in fact stable across platforms and CPUs.

[GyroByte]

Both versions work fine on their own, but 32bit kills multiplayer.
How about this:keep updating the game for both (32bit and 64bit), but disable multiplayer in the 32bit version (since that's where the problems are). That way more people are satisfied.

[aka13]

There is literally no reason to support x32, if the more or less represantitve steam survey says that the share of those system is under 10%. Its just wasteful, especially if it is indeed slowing down development.

[Dharmy]

Everyone using 32 bit now will eventually upgrade to 64 bit, it's just a matter of when.

[Nova]

I don't like the idea to remove 32 bit support. Yes, not much people use it, but think another way about it: When only 1% of users use 32 bit systems, that are still 5000 people. (Yes, you said "under" 1%, I know. ^^)

But maybe it's the right way. I'm not sure. Just take into account that some people will not like it. So please only do it if you really can save a big amount of development time.

[DOSorDIE]

You cant make big Bases with only 32bit (<4GB RAM)!!!
With my old PC with 6GB RAM it crys ever 10 min that he have no RAM left and only Factorio runs!
See that it was 5 Years old and updatet to a new PC.
Who cares 32bit ...

[DaveMcW]

I don't like the idea to remove 32 bit support. Yes, not much people use it, but think another way about it: When only 1% of users use 32 bit systems, that are still 5000 people.

Let's assume there are 2500 more 32-bit sales, and they are worth $10 profit each. $25000 is a year's salary for a developer in Czech Republic. It might take a year of developer time to fix every 32-bit bug. (If you don't fix them all, you will get complaints and negative publicity). And you end up with zero profit.

Now factor in the disruption on all the other developers' workflow when the 32-bit guy breaks their code. And sorting through 32-bit bug reports. It's easy to see how the numbers don't add up.

[FrozenOne]

And that only if you ignore more than 50 % taxation on income ^^

[Vxsote]

I'm pretty sure most of the remaining 32 bit holdouts are likely because of Windows XP (which had a 64 bit version, but it was poorly supported so most people stuck to 32 bit)

As to migrating from Windows XP 32bit to 64bit - I would strongly discourage this as the last never worked fine. If your hardware is that bad you should not aim for playing new games. Windows XP was discontinued in 2013 for a reason so please don't expect anyone to continue supporting it when Microsoft itself stopped it.

Couldn't resist chiming in on this... I actually maintain one machine running XP 64bit. I say "maintain" loosely, because as others have pointed out, updates from MS stopped long ago. It has relatively modern hardware... Core i7-2600K, 8GB RAM, etc. The biggest problem I had was needing to slipstream SATA drivers into the installer. A lot of the issues people had getting software running on xp64 back in the day were because having a 64-bit OS was not mainstream. When Windows 7 came out, that all changed, and I have had surprisingly few problems with it over the years. That IS starting to change, however, as more software requires things only present in Windows 7. The day I retire this installation is probably not too far in the future.

The reason for all of this? Well, there was something I wanted to run that needed some horsepower and was specifically incompatible with windows 7. And I have the luxury of being able to afford dedicated machines when I want them.

Anyhow, my advice regarding 64 bit XP - don't bother. If you don't have it already, you probably don't need it and you probably don't want it.

The other thing I wanted to mention, though, about 32-bit hardware.... recent CPUs are much more power-efficient than those from only a few years ago. If anyone is somehow still playing games on actual 32-bit hardware, besides treating yourself to a miserable experience you are probably running your electric bill higher than it needs to be. Just a thought