3 ms·
> If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it There are other use-cases, though not exactly pop
by DaiPlusPlus 1y ago
> If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it
There are other use-cases, though not exactly popular or mainstream, but supposing you need dozens, hundreds, maybe even over a thousand currently-supported Windows VMs running off a single VM host box: you'll achieve a higher VM density with an x86 build of an OS compared to the x64 build; right now the only option is some cut-down custom build of Windows 10 Embedded x86[1]
...though I'm sure no-one outside of a DEFCON or CCC meetup's drinking-game will ever find themselves doing this - just so long as I get to see it in a youtube video.
[1] EDIT: Turns out they renamed the (non-CE) NT-based Windows Embedded to "Windows IoT" - which annoys me because it's perfectly allowed to make a Windows IoT build without any networking features enabled - so it'd be like calling Apple's iPod Touch as Apple's "iPod iPhone".
----
I'll admit I'm surprised that "x32" (i.e. AMD64 ISA, but with 32-bit pointers) was never supported on Windows, nor exactly popular on Linux, because (at least before Electon Apps existed) plenty of software really has no business using 64-bit pointers, so it makes sense to keep 32-bit pointers; another benefit-of-sorts is that if your program has a memory-leak then it'll crash once the leak hits 4GB - but with 64-bit pointers your process might end-up gobbling hundreds of gigs of RAM before the next malloc call fails.
While we're at it, let's also bring back Intel's 21-bit NEAR/FAR pointers ("segmented memory") if only to keep Rust programmers (and their compiler team) on their toes.
- alerighi 1y agoTrue, but, the advantage of using 32 bit pointers to save a couple of RAM is not that important, since applications typically don't use that much pointers, thus if you half the size of them you will save probably a couple of kb of RAM. Maintaining the support for a different architecture only for that doesn't make a lot of sense, probably the reason it was never supported. RAM is cheap these days so...
- weinzierl 1y ago"probably a couple of kb" Pointers are everywhere. In real world applications we see an increase between a quarter to a third. For example in 2016 Mozilla reported 25% increase from 32-bit Firefox to 64-bit [1]. Google deemed it necessary to implement pointer compression in Chrome to counter the effect. Java also has pointer compression. [1] https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-bit-for-windows-can-take-advantage-of-more-memory/ https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-b...
- alfiedotwtf 1y agoIt’s not just a problem for size, don’t forget you also have to copy bits across busses and several layers of cache - and doing so is not instant! And that’s just thinking in terms of logical RAM. You then have translation tables which pointers need to index into - having them larger makes indexing even more slower, compounding the issue
- karmakaze 1y agoIt can be important, but also there are ways of using compressed pointers on 64-bit systems for similar savings. Search/prompt "What modern systems or programming/runtime environments use compressed pointers of some form?" for details.
- kstrauser 1y agoSo, the Rust team didn’t say they wouldn’t support it, but more that they couldn’t. They’re don’t have in-house experts today who are experienced enough with that platform to support it efficiently. I’d say that a person or company who needs to run thousands of VMs on a single machine would be exactly the right one to step up and adopt it as a maintainer.
- adgjlsfhk1 1y agothe counterpoint is that if you really are memory stressed, you shouldn't be using windows.
- DrillShopper 1y ago> another benefit-of-sorts is that if your program has a memory-leak then it'll crash once the leak hits 4GB If you want that, you can enable ulimits without changing your ABI.