Installing Windows 8, please help me with these two questions :)

i_hate_toms

New Member
i've been using windows 8 on a virtual machine under windows 7 ultimate for quite some time, and i kinda like it.
the virtual machine performance isn't that good (even after installing the latest vmware tools), maybe my computer (i3 2310M/ 4GB/ Intel graphics).
Now, i'm installing Windows 8 on a new partition to run it natively.
My questions:
1>Can i install Windows 8 Pro on a 20GB partition?
2>32bit or 64bit? This one's important. I also happen to be a student of computer science engineering, although everywhere on the internet you'll find 64bit is more efficient, if I'm to believe my professors and my books, a 32 bit OS is more efficient in memory management. A high level instruction is interpreted as a series of assembly instructions before they are executed, and an instruction like the C++ 'int a;', reserves 4 bytes of memory in a 32bit system, and 8 bytes in a 64 bit system, end result is uselessly committing the extra 4 bytes. 4 bytes is miniscule, but when a program will use lots of variables, this small waste will add up and result in a noticeable waste.
I have 4GBs of installed RAM, and I'll never upgrade, i'll get a new laptop before i add extra RAM. The dilemma here is, 64bit addressing would let windows use all 4GB inefficiently (as explained above), and 32bit will only, lets say, allow 3.5GB, but this 3.5GB will be used more efficiently by the system (by comitting less memory for variables and constructs ).
If u were me, what would you do?
Thanks and HAPPY NEW YEAR everyone :)
 

AlienMenace

Well-Known Member
Windows 8 system requirements
If you want to run Windows 8 on your PC, here's what it takes:
Processor: 1 gigahertz (GHz) or faster with support for PAE, NX, and SSE2 (more info)
RAM: 1 gigabyte (GB) (32-bit) or 2 GB (64-bit)
Hard disk space: 16 GB (32-bit) or 20 GB (64-bit)
Graphics card: Microsoft DirectX 9 graphics device with WDDM driver

http://windows.microsoft.com/en-US/windows-8/system-requirements

I would never go back to a 32 bit OS.
 

i_hate_toms

New Member
but what's the justification of 64bit if you're sure you'll never use more than 4GB?

Windows 8 system requirements
If you want to run Windows 8 on your PC, here's what it takes:
Processor: 1 gigahertz (GHz) or faster with support for PAE, NX, and SSE2 (more info)
RAM: 1 gigabyte (GB) (32-bit) or 2 GB (64-bit)
Hard disk space: 16 GB (32-bit) or 20 GB (64-bit)
Graphics card: Microsoft DirectX 9 graphics device with WDDM driver

http://windows.microsoft.com/en-US/windows-8/system-requirements

I would never go back to a 32 bit OS.

Thanks Alien, I'd install Win8 Pro on a 25GB partition then, cannot shrink more because defragmentor programs are crap.
But then why would you "never" go back to 32 bit?
32 bit is clearly more efficient in committing memory as a resource, reduced word length, at a system architecture level, directly implies reduced memory consumption for representing identical data elements. It makes sense if your system has way more RAM, like 6GB or more, but if you have just 4GBs and you are sure you would never add more RAM, don't you think 32 bit addressing would make more sense?
 

spirit

Moderator
Staff member
Well the main reason people like 64-bit is because you can have more than 3.5GB of RAM. These days 4GB and up is nice to have. It makes sense to go 64-bit now, before you know all it the vast majority of programs will be 64-bit only.
 

farmerblue

New Member
I would never go back to a 32 bit system and do my best to never use 32 bit programs. I do run into wanting add-ons that only work with 32 bit.

I'm not a gamer, but I am a heavy user when it comes to complex calculations.

I have a Excel books that are all most imposable to use on a 32 bit instillation even if the computer has better specs than my laptop that runs it daily.
 

i_hate_toms

New Member
Why cant 32 bit address 3.5GB? I dont see any reason why it cant.

Thanks everyone for sharing your valuable opinion, really appreciated :)
Address space is defined as the number of uniquely addressable locations that the system architecture (using a compatible operating system) can support.
This is calculated as 2 raised to the power of the word-length (in bits) of the system.
Word length is defined as the amount of memory that is required to represent one "word" of data (internally).
On a 32bit system (read: word length = 4 bytes) , total number of addresses that can be generated is 2^32= 4.2949 x 10^9 unique addresses.
However, system RAM is NOT the only resource in computer architecture which requires unique addresses. Other resources require unique addresses too (example:- Graphics accelerators, memory mapped I/O, etc,).
It follows that all the 2^32 addresses generated by the 32 bit addressing scheme cannot be dedicated to address RAM. Hence depending on your system specifics, addressable RAM will almost always be lesser than the theoretical top limit possible.
That's what I've been told in my university classes, and i believe my professors are right. If I'm wrong, feel free to correct me, (i'm only a university student of computer science engineering, NOT an expert, m still learning things)
But this is way off topic.
What I wanted to know is, don't you think sacrificing 0.5GB to make efficient use of the remaining 3.5GB is a fair trade off?
Of course if you have 8 GB of RAM, sacrificing 4.5GB to make the remaining 3.5GB efficient would be really stupid. But when you have 4GB, and you are sure you won't upgrade this computer with more physical memory, 32 bit starts looking good, doesn't it?
I don't have any hard 64 bit applications that won't work in a 32bit environment. My CPU of course supports x64, it's an i3, m typing this on windows 7 64bit. :)
 
Last edited:

StrangleHold

Moderator
Staff member
The OS can read up to 4GB. Because of hardware memory adresses the amount usable to windows will be less then 4GB. The amount less depends on your hardware. So as in saying a 32 bit OS cant read more then 3.5GB is not true.

As far as saying that giving up .5GB is a fair trade off. How, if buying a OS and the 64 bit is the same price as the 32 bit. Why have a trade off if its not needed?
 

i_hate_toms

New Member
The OS can read up to 4GB. Because of hardware memory adresses the amount usable to windows will be less then 4GB. The amount less depends on your hardware. So as in saying a 32 bit OS cant read more then 3.5GB is not true.

As far as saying that giving up .5GB is a fair trade off. How, if buying a OS and the 64 bit is the same price as the 32 bit. Why have a trade off if its not needed?
Thanks StrangleHold :)

Ok maybe my words weren't as carefully chosen, what I meant was the amount of memory that can be addressed and presented as usable general-purpose RAM to the OS, will always be less than the theoretical top-limit possible in the architecture definition, because of, as you've pointed out, some addresses being required to represent hardware, as physical memory is not the only resource that requires addresses. That's exactly what I meant to say, and I 100% agree with you [not taking PAE into account though] :)

On the trade off, I guess you're missing my point, it's not about the 32bit version being cheaper, it's about how the underlying architecture handles the available memory. A 64 bit system actually means that the "word length" of the system is 8 bytes. A 32 bit system means the word length is 4 bytes.
This means a 64 bit system will internally use 8 bytes of memory to represent one word of information. a 32 bit system will use 4 bytes to represent the same word.
This small difference of 4 bytes will keep adding up, as you use loads of high-level variables while writing a real-life application. Each of these variables need to be represented internally.
For ease of understanding, let's use classic 'C' language to explain,
every time you define a variable, as int a; or float b; or char c;, or use "malloc" to allocate temporary storage space for an operation, the operating system must commit memory to the variables. This memory is of course NOT secondary memory, it's RAM.
But a 64 bit system uses more memory to represent the same class of variable compared to it's 32 bit counterpart.
A classic conclusion can be drawn from the above example,
int a;
this simple C language data declaration statement declares a variable of integer type.
as soon as this instruction is executed, the OS responds by reserving a block of memory that can be accessed from a higher-level using the name 'a' (although internally it's NOT 'a', it's just another memory block with a HEX address to represent the first location).
On a 32 bit system, the OS will reserve 4 bytes of RAM to represent this variable.
On a 64 bit system, the OS will reserve 8 bytes of RAM to represent the same variable 'a';
This small difference of 4 bytes doesn't look much, but on a real life application, thousands of temporary variables, unions and classes are used, and this small difference adds up.
End result, you will often find a 32 bit application will use less memory than the 64 bit iteration of the same software. Example: keeping every other parameter same, a 32 bit firefox will consume lesser memory than a 64 bit firefox.
When you're multitasking with 10 applications, this little amount of memory saved by each application will add up to precipitate as a noticeably lesser memory usage.
Bottom line: a 32 bit system will use less RAM to run an application, and a 64 bit system will use more RAM to run the same application.
The main deciding factor here is, how less.
If the total amount of memory saved is 1 GB, then sacrificing 0.5 GB makes sense.
 
Last edited:

S.T.A.R.S.

banned
i_hate_toms I think you are paying attention on RAM usage too much.
Yes it's true that 4 bytes is a SMALL difference and that once it's collected many times it takes a LOT of RAM usage and that THEN difference between 32-bit and 64-bit is NOT a small that's true.

But...

Considering how strong computers 95% of home users have today all over the globe,I would not be worrying about that at all because even if the difference between the 32-bit and 64-bit version of your application is 1 GB,most of the users won't even notice the difference.And yes 1 GB seems much and if that happens,all you need to do is to make optimizations and remove ALL currently not being used variables from that RAM memory by setting their value to NULL every time when they are not being used at the moment.Once that has been done,your application will use only the specified amount of RAM memory as it currently needs for it's current tasks and on that way it will not use SO MUCH RAM memory which is needed for ALL your variables,but only for those that are CURRENTLY being used.

Here is a small C# example:

Let's say you have few picture boxes with loaded pictures,string value and int value like this:

try
{
pictureBox1.Image=Image.FromFile("C:\\Picture_1.bmp");
pictureBox2.Image=Image.FromFile("C:\\Picture_2.jpg");
pictureBox3.Image=Image.FromFile("C:\\Picture_3.gif");
stringValue=" pictures loaded successfuly!";
intValue=3;
textBox1.Text=intValue+stringValue;
}
catch(Exception)
{
pictureBox1.Image=null;
pictureBox2.Image=null;
pictureBox3.Image=null;
stringValue=null;
intValue=null;
textBox1.Text="Operation failed!";
}

You can notice that if the operation fails,all the letters (every bit) are set to NULL and are automatically removed from the RAM memory and on that way more RAM memory is now free for other things.

Or let's say that operation succeeded...if the user let's say minimizes the window,you can again do the same thing by let's say removing all 3 pictures from the picture boxes by again setting all 3 IMAGE properties to NULL and that will again free up RAM memory for other things.Why do that?
Well simply because the user cannot see images if the window is minimized and for that reason why would they even need to be displayed and use RAM memory for no reason.
Same applies for all the variables and everything else.

And of course once the user restores the application window,all you need to do is to restore original IMAGE values by returning the images back on let's say FORM_PAINT event.
Same applies for ALL the variables and everything else

So your applications wether they are 32-bit or 64-bit WILL work great if you watch on every RAM usage and remove currently unneccessary and unused things from RAM memory in the right moments.The above example was just the most simple one.But I think you got my point.




Cheers!
 

StrangleHold

Moderator
Staff member
Thanks StrangleHold :)

Ok maybe my words weren't as carefully chosen, what I meant was the amount of memory that can be addressed and presented as usable general-purpose RAM to the OS, will always be less than the theoretical top-limit possible in the architecture definition, because of, as you've pointed out, some addresses being required to represent hardware, as physical memory is not the only resource that requires addresses. That's exactly what I meant to say, and I 100% agree with you [not taking PAE into account though] :)

On the trade off, I guess you're missing my point, it's not about the 32bit version being cheaper, it's about how the underlying architecture handles the available memory. A 64 bit system actually means that the "word length" of the system is 8 bytes. A 32 bit system means the word length is 4 bytes.
This means a 64 bit system will internally use 8 bytes of memory to represent one word of information. a 32 bit system will use 4 bytes to represent the same word.
This small difference of 4 bytes will keep adding up, as you use loads of high-level variables while writing a real-life application. Each of these variables need to be represented internally.
For ease of understanding, let's use classic 'C' language to explain,
every time you define a variable, as int a; or float b; or char c;, or use "malloc" to allocate temporary storage space for an operation, the operating system must commit memory to the variables. This memory is of course NOT secondary memory, it's RAM.
But a 64 bit system uses more memory to represent the same class of variable compared to it's 32 bit counterpart.
A classic conclusion can be drawn from the above example,
int a;
this simple C language data declaration statement declares a variable of integer type.
as soon as this instruction is executed, the OS responds by reserving a block of memory that can be accessed from a higher-level using the name 'a' (although internally it's NOT 'a', it's just another memory block with a HEX address to represent the first location).
On a 32 bit system, the OS will reserve 4 bytes of RAM to represent this variable.
On a 64 bit system, the OS will reserve 8 bytes of RAM to represent the same variable 'a';
This small difference of 4 bytes doesn't look much, but on a real life application, thousands of temporary variables, unions and classes are used, and this small difference adds up.
End result, you will often find a 32 bit application will use less memory than the 64 bit iteration of the same software. Example: keeping every other parameter same, a 32 bit firefox will consume lesser memory than a 64 bit firefox.
When you're multitasking with 10 applications, this little amount of memory saved by each application will add up to precipitate as a noticeably lesser memory usage.
Bottom line: a 32 bit system will use less RAM to run an application, and a 64 bit system will use more RAM to run the same application.
The main deciding factor here is, how less.
If the total amount of memory saved is 1 GB, then sacrificing 0.5 GB makes sense.

Well, look at it this way. With the 4GB scale, true 64 bit will use more memory in general. With 64 bit you do gain .5GB of memory address/more or less. The trade off either way is minimal. If your peaking your memory to the point that your worried about usage running 4GB. I would still install the 64 bit and later down the road you can upgrade to more memory. Plus you wont have to do another OS reinstall for 64 bit.
 

Calin

Well-Known Member
The OS can read up to 4GB. Because of hardware memory adresses the amount usable to windows will be less then 4GB. The amount less depends on your hardware. So as in saying a 32 bit OS cant read more then 3.5GB is not true.
My 64Bit Win8 can read only 3.5GB, not 4GB.
 

StrangleHold

Moderator
Staff member
My 64Bit Win8 can read only 3.5GB, not 4GB.

You got a problem somewhere then. Its either memory remapping in the bios or you need to uncheck max memory in the System Configuration under the Advanced Options.
 
Last edited:

Calin

Well-Known Member
You got a problem somewhere then. Its either memory remapping in the bios or you need to uncheck max memory in the System Configuration under the Advanced Options.
I don't have that option :p.
I think it's caused by the old bios blah :rolleyes:
 

StrangleHold

Moderator
Staff member
For memory remapping in the bios, try looking under Advanced/Chipset/Northbridge Configuration. Should be there.
 

i_hate_toms

New Member
i_hate_toms I think you are paying attention on RAM usage too much.
Yes it's true that 4 bytes is a SMALL difference and that once it's collected many times it takes a LOT of RAM usage and that THEN difference between 32-bit and 64-bit is NOT a small that's true.

But...

Considering how strong computers 95% of home users have today all over the globe,I would not be worrying about that at all because even if the difference between the 32-bit and 64-bit version of your application is 1 GB,most of the users won't even notice the difference.And yes 1 GB seems much and if that happens,all you need to do is to make optimizations and remove ALL currently not being used variables from that RAM memory by setting their value to NULL every time when they are not being used at the moment.Once that has been done,your application will use only the specified amount of RAM memory as it currently needs for it's current tasks and on that way it will not use SO MUCH RAM memory which is needed for ALL your variables,but only for those that are CURRENTLY being used.

Here is a small C# example:

Let's say you have few picture boxes with loaded pictures,string value and int value like this:

try
{
pictureBox1.Image=Image.FromFile("C:\\Picture_1.bmp");
pictureBox2.Image=Image.FromFile("C:\\Picture_2.jpg");
pictureBox3.Image=Image.FromFile("C:\\Picture_3.gif");
stringValue=" pictures loaded successfuly!";
intValue=3;
textBox1.Text=intValue+stringValue;
}
catch(Exception)
{
pictureBox1.Image=null;
pictureBox2.Image=null;
pictureBox3.Image=null;
stringValue=null;
intValue=null;
textBox1.Text="Operation failed!";
}

You can notice that if the operation fails,all the letters (every bit) are set to NULL and are automatically removed from the RAM memory and on that way more RAM memory is now free for other things.

Or let's say that operation succeeded...if the user let's say minimizes the window,you can again do the same thing by let's say removing all 3 pictures from the picture boxes by again setting all 3 IMAGE properties to NULL and that will again free up RAM memory for other things.Why do that?
Well simply because the user cannot see images if the window is minimized and for that reason why would they even need to be displayed and use RAM memory for no reason.
Same applies for all the variables and everything else.

And of course once the user restores the application window,all you need to do is to restore original IMAGE values by returning the images back on let's say FORM_PAINT event.
Same applies for ALL the variables and everything else

So your applications wether they are 32-bit or 64-bit WILL work great if you watch on every RAM usage and remove currently unneccessary and unused things from RAM memory in the right moments.The above example was just the most simple one.But I think you got my point.




Cheers!

Thanks Stars, a real good suggestion.
But it's kinda too much typing to write all those extra code, i at times don't even use 'calloc' :p
Bad programing i know, but then i'm lazy lol :p
Doesn't solve the problem completely though, the 64 bit platform would still use more memory compared to it's 32 bit counterpart (when the window is not minimized. And for that matter, even when the window is minimized, not everything can be nulled. A picture can be nulled indeed, but a counter variable in a 'for' loop cannot. An array to represent a stack or queue data structure cannot. Plus, executing additional lines of code to optimize memory would reduce memory usage at the cost of consuming extra processor cycles, and hence is not completely overhead proof!)
Nevertheless, a great tip. And I get your point, with real life computers starting at a minimum of 4GB RAM these days, under certain situations the amount of extra memory overhead imposed by a 64 bit platform could be ignored.
Thanks again, great answer :)
 
Last edited:

i_hate_toms

New Member
Well, look at it this way. With the 4GB scale, true 64 bit will use more memory in general. With 64 bit you do gain .5GB of memory address/more or less. The trade off either way is minimal. If your peaking your memory to the point that your worried about usage running 4GB. I would still install the 64 bit and later down the road you can upgrade to more memory. Plus you wont have to do another OS reinstall for 64 bit.

Thanks for your answer StrangleHold :)
To put my point is simple terms,
say,
on 32 bit
memory saved by 32 bit = 1 GB.[let this be x]
memory unavailable by architecture restrictions = 0.5 GB.[let this be y]
actual memory gained =1 GB- 0.5 GB = 0.5 GB. [let this be z]

on 64 bit,
say extra memory used by architecture definition = 1 GB
extra memory gained by moving to 64 bit =0.5GB
actual memory gained = 0.5GB - 1GB = -0.5 GB. (extra .5GB is wasted as overhead). [let this be p]

Of course the numbers used are arbitrary and in no way represent a real life implementation, but the logic still holds. Hence, if z > p, then 32 bit is more appropriate. On the other hand, if p > z, then 64 bit is more appropriate.

Even in the case where z > p, installing a 64 bit OS makes sense if you are planning to add extra RAM in future, which would disproportionately increase the value of 'y' while 'x' would remain the same (assuming you're using the same applications) and hence dramatically reduce the value of 'z', reversing the initial condition to p > z (making 64 bit more appropriate as explained above). You stated this yourself too :-
... and later down the road you can upgrade to more memory. Plus you wont have to do another OS reinstall for 64 bit.

BUT, as stated in a previous post, I wouldn't add more RAM ever, this laptop is 2 years old and i'll get a new computer next year, hence this 'state reversal' stated above is not an issue for me. :)

So, given you won't ever add extra RAM, the real question here is the value of z - p.
If z - p is '+ve', then 32 bit is appropriate. If z - p is '-ve', 64 bit is better.
 
Last edited:
Top