Policy idea: Change TypeId's implementation details every other release

[ABagOfChips]

std::mem::size_of::<usize>() evaluates to the size of a pointer, which is always 8 on 64-bit and always 4 on 32-bit.

If it was actually determined by operating system like that, it would be a huge, obvious, ecosystem-wide problem.

[Soni]

I just mean Windows programs are still stuck on 32-bit ABI because you only need to build once, whereas everything else is generally 64-bit nowadays

[ABagOfChips]

I don’t understand what you mean by this. Windows exists in both 64-bit and 32-bit forms the same way any other operating system does. I would also put forth that the usage demographics as far as 64-bit vs 32-bit go on Windows are likely to be very similar to what they are on other platforms, leaning rather heavily in favor of 64-bit (at least for what is often called “desktop” usage) nowadays.

Someone wanting to support both 64-bit and 32-bit on Windows with regards to Rust software they’re writing would do so with two separate compiler toolchains, just as is done everywhere else.

[Soni]

Nope, Windows does SysWoW64, and generally programs will be built for 32-bit windows and tested on 64-bit windows.

Unlike Ubuntu (where 64-bit is the default)/Arch Linux (that went as far as dropping support for 32-bit architectures!)/etc.

[ABagOfChips]

generally programs will be built for 32-bit windows and tested on 64-bit windows.

No they aren’t. Yes, 64-bit Windows can run 32-bit binaries via SysWow64, but this is intended just for backwards compatibility use cases. The bulk of the software present on a 64-bit Windows installation is natively 64-bit, and it’s absolutely what people expect.

Again, 64-bit is certainly also the “default” on Windows in 2018, and it has been for years. You haven’t even been able to buy things like prebuilt consumer Windows machines with 32-bit installations of the OS from the vast majority of sources without explicitly going out of your way to do so since like 2009.

Consider that what you’re suggesting would mean that i686-pc-windows-msvc and i686-pc-windows-gnu were downloaded more often than x86_64-pc-windows-msvc and x86_64-pc-windows-gnu, which cannot possibly be the case.

[CAD97]

This is strictly false. Most Windows programs distribute a x86 and x64 build now.

Counting programs on my computer, I counted ~30 programs in %programfiles% and ~15 programs in %programfiles(x86)% (disclaimer: not actually in these folders, rather manually set the installer to use the same but on D:\ which has more space) (disclaimer: may be slightly inaccurate). (My installed program list remains somewhat spartan for now at least, it’ll grow as time passes between now and the next time I decide I need to clean up my computer.)

64 bit

• 7-Zip
• CMake
• Elgato
  • GameCapture
  • SoundCapture
• Git
• HexChat
• Inkscape
• Java (RE and DK)
• NVidia GeForce
• Unity
  • Hub
  • Editor
• VLC
• WordPad
• Microsoft Office
  • Access
  • Excel
  • OneNote
  • Outlook
  • PowerPoint
  • Publisher
  • Skype
  • Word
• Firefox
• Notepad++
• PaintDotNet
• Open Broadcaster System
• Zulip
• Gitter
• JetBrains Toolbox
  • CLion
  • IntelliJ IDEA
  • Rider
• Visual Studio Code
• Internet Explorer
• LiveSplit

32 bit

• Battle.net
  • Hearthstone
• Mendeley
• Visual Studio
• Steam
  • Aseprite
  • A Hat in Time
  • Monster Sanctuary
  • OneShot
• Microsoft Paint
• Windows Media Player
• Audacity
• Google Chrome
• MuseScore
• Deltarune
• Notepad
• Command Prompt

Located elsewhere, so I don't know

• Anaconda
• Discord
• Google Play Music Desktop Player
• OneDrive

Provided in both x86 and x64

• Powershell

To be fair, many of these offer both x86 and x64 downloads, in order to support x86 machines, but when downloading on a x64 machine they default to providing the x64 installer.

[ZerothLaw]

If I might make a note y’all, you seem to have drifted significantly in topic and are getting stuck in the weeds on implementation details and distribution of windows binaries. If I may suggest a new thread for discussing potential changes to TypeId and the reasons for those changes?

Please?

[ABagOfChips]

Don’t have much else to say TBH.

I mostly just wanted to point out more than anything else that size_of::<usize>() is strictly a matter of 64-bit build target vs. 32-bit build target, that has absolutely nothing to do with the specifics of any particular operating system.

[Tom-Phinney]

that size_of::<usize>() is strictly a matter of 64-bit build target vs. 32-bit build target

Until you get to 128-bit build targets on RISC-V, and probably on other architectures that try to stay competitive. Then there are all the old SoC chips and their underlying microcomputers where usize is 16-bits, 20-bits or 24-bits.

[notriddle]

Until you get to 128-bit build targets on RISC-V

For context’s sake, DropBox stores 500 petabytes, and a 64-bit memory address can address 18,447 petabytes.

128-bit memory addresses aren’t going to be needed for a very, very long time. We’re talking about storing a byte in a few atoms and having the resulting computer still not comfortably fit in a laptop types of situations. A cloud-native™ application might have 128-bit “addresses”, but at the bare metal where Rust is for, your individual node ain’t gonna need a 128-bit usize.

[skysch]

128-bit memory addresses already exist in some systems. The extra bits are used to store flags/metadata about pointers.

[mbrubeck]

[The 128-bit pointer thing is getting off-topic. Let’s move on from that.]

[Centril]

[The 128-bit pointer thing is getting off-topic. Let’s move on from that.]

Split the topic?

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.