Technical Discussion
  >> Linux Issues


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | [3] | 4 | 5 | >> (show all)   Print Thread
Standard User AEP
(knowledge is power) Fri 01-Apr-11 19:22:06
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
Well then, prove it. It doesn't look like that on my installation.
Standard User 12eason
(eat-sleep-adslguide) Fri 01-Apr-11 19:26:26
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
You are the one making the claim that 64bit and 32bit are the same size mate, when clearly common sense says that 32<64, it up to you to prove it.
Standard User AEP
(knowledge is power) Fri 01-Apr-11 19:31:58
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
Whatever.


Register (or login) on our website and you will not see this ad.

Anonymous
(Unregistered)Fri 01-Apr-11 21:12:38
Print Post

Re: Re: 32- and 64-Bit & Vista Memory


[re: camieabz] [link to this post]
 
[slightly OT]

I would have preferred 75% allocated for regular usage and 25% set aside for other things


The problem here is that your analysis is flawed not the design, no offence. The "available" memory is simply a read only (largely) copy of what is on disk so can be safely overwritten without extra cost. i.e its the difference between overwriting 0xabcdef and changing the page index from cached>application or overwriting 0x0000 and changing the index from free>application. Given the choice between your RAM being filled with zeros or filled with something I might need later I know what I would choose. OK some (only new allocations and not page-ins or code/data loads) RAM needs to be zeroed (for security) before handing it to an application but most other OSes do this on demand. WindowsNT does in fact use idle CPU to pre-zero free memory but unless all CPU cores are pegged at 100% you don't need more than a few MB buffered for this. Also since you have a large cache the NT kernel can delay memory writes when the disks are idle (lazy writes) or even opportunistically pre-write in memory data that's still in use rather than get in the way of reads.
The other point people are unaware of is this is EXACTLY the same as XP (+prefetcher), Win2000, NT4.0, NT3.51 and of course VMS (Thank you Mr. Cutler). You could achieve the same thing on prior versions by simply loading then closing all your most frequently accessed applications in the morning. The problem is on modern PCs (with bags of RAM) its takes a lot of time to warm up (i.e. fill) the cache and an empty cache is a useless cache so why not fill it in idle time? In fact the only significant change in Vista's memory manager is the addition of memory priority so it can give preference to OS>applications>actively cached stuff>superfetched stuff which is a big improvement.
[/OT]

OK back on topic the other big change in 64bit is the change in OS calling conventions, since extra registers allows more function params to be passed in register and not on stack, also (with reference to windows) a totally different exception handler mechanism is used i.e. read-only complier generated stack unwind data + fixed prolog/epilog styles rather than (easily exploited) exception handler chains. This then makes writing ASM for inner loop optimization in applications very different. However, while the extra memory space and the extra registers are very useful (8 is not really enough) the increase from 32->64bit really doesn't help 90%+ of algorithms as evidenced by most other archutectures (e.g. PPC) usually getting slightly slower (5-10%) when moving from 32 to 64bit code due to extra pressure on the code/data cache. x86 is unusual in this regard as it usually gets about 5-10% faster in 64bit mode largely due to the extra GPRs even though most 64bit code only actually using 32bit operands. That is not to say that the odd bit of code can not really benefit from 64bit. For example, SHA512 is much (~x2) faster.

Stuart
Anonymous
(Unregistered)Fri 01-Apr-11 21:26:27
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
I have to agree, 64bit programs are bigger, they are just not 2 times bigger more like 1.2-1.5x depending on a lot of things so still an issue if your space constrained. Persisted data should be the same size though as you really shouldn't be loading pointers from disk. Although I have heard of people doing it!!!! frown

Stuart
Standard User AEP
(knowledge is power) Fri 01-Apr-11 21:39:53
Print Post

Re: 32- and 64-Bit


[re: Anonymous] [link to this post]
 
I did check, as a matter of interest, IE on XP64. A 3% difference in size, which is hardly going to worry me. Most hard disk reads and writes are, as you point out, data. Comments about 64-bit programs requiring twice the disk space aren't really worth arguing with.

Truth is, that poster delights in trying to show how much cleverer than anyone else he is. In this case he's come a bit of a cropper. smile
Standard User 12eason
(eat-sleep-adslguide) Fri 01-Apr-11 21:53:03
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
Comments about 64-bit programs requiring twice the disk space aren't really worth arguing with.

Truth is, that poster delights in trying to show how much cleverer than anyone else he is. In this case he's come a bit of a cropper. smile
No AEP. We have an expert here now to correct you on your 'google-wise' gibberish. You should really stick to a topic you stand a chance of understanding, perhaps in the Apple forums? It is common knowledge that 64 bit takes up twice the RAM, generates nearly twice the HD I/O and increases processor temps because of the extra electricity it needs. You have yet to prove any of your crazy speculation, which flies in the face of modern computer science.
Anonymous
(Unregistered)Fri 01-Apr-11 21:59:52
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
Err, nobody apart from you is suggesting x2 anything. The most I have seen is 1.5x (code) usually a lot less. Memory overheads are fairly slight but as for disk IO - I doubt you could really measure any difference.

Stuart
Standard User AEP
(knowledge is power) Fri 01-Apr-11 22:11:38
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
I've written a small OS in x86_64 assembler, so I do have some understanding of its architecture. But I wouldn't consider myself an expert.
Standard User 12eason
(eat-sleep-adslguide) Fri 01-Apr-11 22:43:37
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
The world has moved on from bbc basic programs AEP. I doubt your 10 line 'assembler' program really tested the disk IO and power usage, open source or not.
Pages in this thread: 1 | 2 | [3] | 4 | 5 | >> (show all)   Print Thread

Jump to