00:00:00
So you go to download some program and you see
there's a couple options, a 64-bit version and
00:00:04
a 32-bit version, but I mean, Windows is 64-bit
these days. So why does the 32-bit version even
00:00:10
exist? Should you EVER bother downloading it?
Well I wanted to know, is there ever any reason to
00:00:16
use a 32-bit version if the 64-bit is available?
And to my surprise, turns out, yes. And actually
00:00:22
this means going forward, I'm going to have
to be considering, "hmm, maybe I do want to
00:00:26
get the 32-bit version actually of some program",
depending on what it is. Now to be clear, I'm not
00:00:31
talking about Windows itself. There's really no
reason for using 32-bit Windows. What I'm talking
00:00:36
about is the programs themselves, which Windows
supports running both 32-bit and 64-bit. And by
00:00:42
the way, if you see x86, that actually is talking
about 32-bit. Don't get confused by that. So then,
00:00:48
what are the differences between running a 64-bit
version of a program versus the 32-bit? I'll do a
00:00:53
quick rundown and then we'll get into the details.
The two main differences are the amount of RAM
00:00:58
they support and their speed. 64-bit programs
support a lot more memory, effectively unlimited.
00:01:04
You're not going to run up against that limit.
However, 32-bit programs are limited to just two
00:01:09
or four gigabytes of RAM. It does depend. I'll
explain that later. However, in terms of speed,
00:01:15
it turns out that 32-bit programs can actually be
significantly faster than 64-bit. And depending on
00:01:23
if the program inherently does not need a lot of
RAM, then it might actually be the better choice.
00:01:30
Now, if you're like me, you might've seen people
mention that 32-bit can be faster than 64-bit and
00:01:35
thought that it's probably just negligible.
But I actually wanted to know for sure. So I
00:01:40
created a test program that does a bunch of
different operations in a loop and compiled
00:01:45
it in both 32 and 64-bit and then compared the
differences, and it is significant. Of course,
00:01:50
I'll get into how much and why this is too later.
Now, there are some other differences I've read
00:01:55
about. One is that potentially the EXE files
themselves might be a bit bigger for 64-bit,
00:02:02
but this seems to be negligible. And also another
potential difference is the 64-bit version might
00:02:09
have a bigger memory footprint in terms of how
much memory space it actually takes up. And
00:02:14
that'll become clear why later. But again, this
doesn't seem to be huge. Like in the difference
00:02:18
for my test program, the 64-bit version was 15.5
KB of RAM versus 11.5. Now percentage-wise, that's
00:02:28
pretty significant, but for a bigger program, it
probably won't make much of a difference. Now,
00:02:32
at the end of the day, if you don't want to worry
about it, just get the 64-bit version and don't
00:02:36
worry about it. It'll be fine, most of the time
that's the right choice. Now, before getting
00:02:40
into the more specifics of the differences,
something else that you shouldn't have to worry
00:02:44
about is all your data being collected and spread
online, which is where today's sponsor comes in,
00:02:48
Aura. There are so many sketchy data brokers
out there that collect and sell your information
00:02:53
to scammers, spammers, and anyone else who may
want to target you. I'm talking your full name,
00:02:57
email address, home address, health records,
your relative's info, it's all out there. But
00:03:02
that's where Aura comes in. For example, it
can show me which data brokers it found that
00:03:06
are selling my info and automatically submit
opt-out requests for me. Cleaning up this
00:03:10
info not only helps reduce the amount of spam
coming my way, but protects me from hackers,
00:03:14
who might leverage this info to try and access
my accounts or even do personalized phishing
00:03:19
attacks. I was even surprised when it showed me
that the collected public info out there even
00:03:24
includes what kind of car I drive. But Aura also
has a ton of other features, such as an antivirus,
00:03:29
a VPN, password management, parental controls,
identity theft insurance, all in one place instead
00:03:35
of needing a bunch of separate apps. Even if you
already have one or two of these tools, you could
00:03:39
still be leaving doors open to bad actors, but
Aura is always on so you can have peace of mind
00:03:44
and focus on the important stuff. So if you don't
want to leave you and your family vulnerable,
00:03:47
to get started you can go to Aura.com/ThioJoe and
start your two week free trial. Link is also in
00:03:53
the description. And with all that being said,
let's continue. Alright so let's talk about that
00:03:57
first major big difference between the two, which
is the amount of memory they support. Like I said,
00:04:02
sometimes you'll see people talk about how 32-bit
programs have a limit of two gigabytes, and other
00:04:08
times you'll see it's four. And why is that? And
actually it is both. It depends on how the program
00:04:15
was compiled. You see, when you go to create
or compile the program from the source code,
00:04:20
there is a "flag" that you can set in the compiler
called "IMAGE FILE LARGE ADDRESS AWARE". And if
00:04:28
you set this flag, and presumably you might have
to add a little bit extra support in the code,
00:04:32
then it will actually support up to four gigabytes
of RAM. And if you don't set this flag, it is
00:04:37
limited to two gigabytes. Now this thing, "image
file", is not talking about picture type files.
00:04:42
It's talking about "image" in the sense of like
the binary file, the program file. That's what he
00:04:47
means by image. And random fun fact - it turns out
that you can actually, if you really wanted to,
00:04:53
set the flag here to negative on a 64-bit program,
by default it's set to support it. But if you set
00:05:02
it to false, that means that even the 64-bit
program will only support up to two gigabytes
00:05:08
of RAM, but you would have to specially do that
for some reason. However, for 32-bit programs,
00:05:14
this flag is not set by default. So it turns out
that most programs I've seen that are 32-bit are
00:05:18
actually limited by two gigabytes and don't have
this flag set. In Windows, there's surprisingly
00:05:24
not really an easy way to detect whether a program
is 32 or 64-bit. It's not in the properties
00:05:30
window. But you can actually tell indirectly if
you go to the Compatibility tab of an EXE and then
00:05:36
you click the dropdown for which operating system
to try and use it based on. If it says Windows 95
00:05:44
as the top one, then it means it's 32-bit EXE. And
if it says Windows Vista, then it's 64-bit. Out
00:05:49
of curiosity, I wrote up a quick C# program that
would go through all the programs in a folder and
00:05:56
check whether each one was 64 or 32-bit, and in my
Program Files x86 directory, of the 800 in there,
00:06:03
75% of them did not have this flag set. So yeah,
most of the time it's going to be a two gigabyte
00:06:09
limit of RAM for 32-bit programs. Now, why are
these limits two and four gigabytes specifically?
00:06:16
Without getting too technical, it has to do with
how the computer stores the addresses in the RAM.
00:06:21
On a 32-bit operating system, they use 32-bit
integers for the memory address. And that just
00:06:27
means that the amount of places you can address
a single specific byte of data is Two to the 32
00:06:34
power, which ends up being around 4 billion
bytes or four gigabytes to be specific. On a
00:06:39
64-bit operating system, you have 64 bits to work
with, and it's not simply double, it's actually
00:06:44
exponential. So a 64-bit address can store around
18 quintillion different locations. That would
00:06:52
be around 18 million terabytes of RAM, but that
basically just means unlimited. Any limits that
00:06:59
are in Windows are effectively just arbitrarily
set, but just know that there's really no limit
00:07:04
with this. Now, as for where the two gigabyte
comes from, back in the day when it was 32-bit
00:07:10
Windows, Windows actually split up the amount of
RAM that was available to a program running to max
00:07:16
out at two gigabytes for the user space, which was
like how most programs were running, and then it
00:07:22
would also have half of it to the kernel space.
So basically for a program running, half of it
00:07:28
was used by the system for that program, and then
half of it was like the program related stuff. Not
00:07:34
going to get too much more technical than that.
All right, so now on to the speed difference,
00:07:38
which is probably more interesting. So I wrote up
a C# program with the help of AI, because I didn't
00:07:42
know how to make these tests, but basically it
just does a bunch of different various operations
00:07:46
in a loop, and then I compiled it in 32-bit
and 64-bit. It's just a dropdown setting in
00:07:53
Visual Studio. And going off the results, it
seems that basically all of the time, 32-bit
00:07:59
is going to be faster to varying degrees. For
some operations like this linked list traversal,
00:08:05
it's really not much of a difference, it's like
1%. Probably just margin of error. But you can see
00:08:09
that for most of the other operations, it's like
a 20% increase in speed over 64-bit. And then for
00:08:17
the binary tree operations, which apparently are
more memory intensive, that's like 40% faster,
00:08:23
which is kind of crazy. Now as for why this is
the case, why it's faster, from my understanding,
00:08:27
I'm not going to pretend to fully understand it,
but basically since the addresses themselves are
00:08:31
smaller, that means that it's actually faster to
work with getting the data and moving it around
00:08:39
and stuff like that. And it probably does make
more of a difference for a lot of little small
00:08:42
operations where it's small amounts of data,
especially for repeated operations where you
00:08:47
might be able to fit the whole thing into
the CPU's cache, which if you didn't know,
00:08:52
is way faster than the RAM. There's L1, L2, and
L3, which usually is not a lot. It's maybe on the
00:08:59
order of kilobytes for L1 cache and then megabytes
for L2 and L3. And since the size of the addresses
00:09:06
and stuff are half for 32-bit, that means you
could probably fit more in there to have access
00:09:12
to that way more faster. So for applications
that you know will never need more than two or
00:09:17
potentially four gigabytes of RAM, then you might
actually want to go with the 32-bit if it's there.
00:09:22
Of course like always, I should mention this
is a synthetic test. It doesn't always resemble
00:09:27
real life. And potentially in most cases, it is
preferable to have the extra RAM available than
00:09:33
it is just being able to do some operations
faster. However, at least it does mean that
00:09:39
if you're going to look for a program and you're
like, "Oh, it's only the 32-bit version available,
00:09:44
it's so old!", you don't necessarily have to be
mad about it. You know, it's not the end of the
00:09:48
world, might actually be the better choice. So
with all that context, it kind of does explain
00:09:52
why you still do see 32-bit programs. Like if
you go into the Windows "C:\Program Files",
00:09:58
you'll also see that there's a "Program Files x86"
folder. And again, x86 is talking about 32-bit,
00:10:03
and there's actually a lot of programs that
go into here. If you're wondering why they
00:10:07
decided to make the new folder for x86 instead of
64-bit, well basically the convention in Windows
00:10:14
is that the regular Program Files folder just gets
assigned to whatever is the native architecture of
00:10:19
that installation of Windows. For example, if
you have the ARM version, like on this virtual
00:10:24
machine I had that runs on Mac, it's Program
Files has all the ARM stuff in there. It's not
00:10:30
like Program Files ARM, though there is one called
ARM, but that's actually for 32-bit ARM programs.
00:10:36
So it's a bit confusing. So as for why you see
a lot of programmers who offer both the 32 and
00:10:42
64-bit version of the program, I highly doubt that
they're thinking about it as, "Oh, this one might
00:10:49
be a bit faster if it doesn't need as much RAM". I
think they probably just do it because potentially
00:10:55
there's people on really old Windows that might
need the 32-bit. And also it's easy enough to just
00:11:02
usually compile it in both versions automatically.
It's not much more difficult for most programs. As
00:11:07
for some popular programs that are only made
in 32-bit, like I think Steam is only 32-bit,
00:11:16
it probably, again, comes down to the fact that
they probably determined that for their purposes,
00:11:20
it doesn't make sense to introduce the extra
overhead of development, as small as it might be,
00:11:25
to have to offer two different versions if they
don't need that extra memory overhead, if Windows
00:11:31
is always going to support the 32-bit version
anyway. And also I'll point out that potentially
00:11:36
they could just have like helper programs that
maybe run as like a separate process for some
00:11:42
parts that do use 64-bit or something like that,
I don't know. So yeah, it's not necessarily that
00:11:47
everyone should always upgrade to 64-bit. Turns
out it is not as important as I thought. So I
00:11:53
would be very curious to know what you guys
think, and whether you were as surprised as
00:11:57
I was that maybe 32-bit EXEs are not as useless as
you thought. So we can talk about that all down in
00:12:02
the comments. Thanks again to Aura for sponsoring
the video. If you want to protect you and your
00:12:06
family's data and take advantage of all the other
features it has, go to Aura.com/ThioJoe for a
00:12:11
two-week free trial. Link is in the description.
Now, if you want to keep watching, the next video
00:12:14
I'd recommend is a really cool tool for image
manipulation that you probably have never heard
00:12:19
of before and does not use AI or anything, but
it's still extremely cool. So I'll put that link
00:12:23
right there you can click on. So thanks so much
for watching and I'll see you in the next one.
