3
\$\begingroup\$

I was developing a graphics engine from scratch using Direct3D11 and some APIs, but I stumbled in a situation where it would beneficial to me to use a certain library, but it's binaries are only available on 32 bits.

I've changed my engine to 32 bits and didn't see much difference in terms of speed, would it be troublesome to use it on 32 bits? What other surprises lie around the corner?

\$\endgroup\$
11
  • \$\begingroup\$ Quite the opposite. Some processor extensions allow operations for two 32-bit numbers simultaneously. Also, smaller variables mean less memory usage, which is particularly relevant in game graphics. Most graphics engines and graphics API use 16 bit variants whenever possible to reduce memory overhead and improve processing speed... Google half4. Older processors required multiple steps to perform operations on 64-bit numbers, but that's far less common nowadays. In game dev, use the smallest you can get away with. One downside: If you need 64 bit maths, it'll be much slower in a 32 bit app \$\endgroup\$
    – Basic
    Jul 12, 2021 at 0:44
  • 3
    \$\begingroup\$ If the number of bits you're using matters, you've likely got other problems. \$\endgroup\$
    – Almo
    Jul 12, 2021 at 1:00
  • 2
    \$\begingroup\$ @Basic this looks like it would be worth writing up as an answer that can be upvoted and accepted. It would also be worthwhile to mention that in a 32-bit app, the amount of memory you can address is more limited than with 64 bit. \$\endgroup\$
    – DMGregory
    Jul 12, 2021 at 11:23
  • 2
    \$\begingroup\$ @Basic How does the 64-bit vs 32-bit influences this? AFAIK, the only differences in sizes are the pointer related types (and std::size_t). Libraries that require float will still require float, not double. \$\endgroup\$
    – Vaillancourt
    Jul 12, 2021 at 14:29
  • 1
    \$\begingroup\$ Ok, thank you all for your answers. \$\endgroup\$ Jul 12, 2021 at 17:38

1 Answer 1

4
\$\begingroup\$

The most obvious thing to consider is that using a 32-bit architecture for your executable allows you to address about ~4gb of RAM on Windows while using a 64-bit architecture allows the program to address 128gb+. This means that you can put much more stuff into RAM before experiencing issues.

A situation where this could ¤ be an issue is loading your 3d models and their textures into Video RAM. For instance, the machine's graphics card allows to load 8gb of data (the nVidia DLL will manage this just fine even using a 32-bit app), and you want to take advantage of it, so you'll create nice models with big, highly detailed textures, which will end up taking 6gb of memory.

With a 64-bit architecture, you would simply have to load everything into RAM, then have the graphics API load it into Video RAM. But with a 32-bit architecture, you'll need to cut down your loading process into smaller pieces: load a chunk of data into RAM, send it to VRAM, unload it from RAM, then repeat with the other chunks, until everything is done.


¤ Note that this will often depend on how you do things, what you need in your game, and how you've arranged your architecture; I used a framework where this was an issue: we loaded an image from disk into RAM, but there was no check telling us that memory couldn't be assigned, so the rest of the code tried to upload a "null" image into VRAM. We either had strange bugs, at strange places, or some parts of the models just appeared black.

\$\endgroup\$
1
  • \$\begingroup\$ See Microsoft Docs and Gamasutra. For Windows PC, it's fine to ship a 32-bit EXE if your memory requirements are modest, but if you plan to ship on Xbox some day you need a 64-bit EXE. In general, make sure your code is portable as much as possible. I'd also be a little concerned about a library that's not available as 64-bit--is it old? Is it maybe unsupported these days? \$\endgroup\$ Jul 31, 2021 at 18:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .