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
(fountain of knowledge) Fri 18-Mar-11 09:14:46
Print Post

32- and 64-Bit


[link to this post]
 
This is likely to be a lengthy post, so stop right now if you are not interested!

Background
In Camie's recent post a few common misconceptions about 64-bit programs have arisen so I thought it might be useful to explain my understanding of the subject. As background, I have been interested in 64-bit assembler for the past 6 or 7 years and have studied the AMD and Intel manuals quite carefully. I have a web site that details some of my research, in particular bootstrapping a processor into 64-bit (more properly "long") mode and then getting it to actually do something. This has been quite favourably received by others trying to understand these things. I am an interested amateur, not a professional.

Memory Addresses
It is a fairly obvious truism that 64-bit addresses are twice the size of 32-bit addresses. But this doesn't mean that a 64-bit program is twice the size of a 32-bit one, or uses twice the RAM. In practice very little of the data in a program consists of absolute addresses. More commonly memory is addressed via addresses stored in registers - in particular local variables to functions are stored on the stack and will be addressed via the BP register. The stack itself would (if other things were equal) be bigger, because it also contains the return address and other details, but other things aren't equal.

Data
No difference here (in general). A 64-bit program can address data in 8-bit increments just as a 32-bit one can. So no more storage space is needed for data. One exception to this is the Interrupt Descriptor, Page, and other Descriptor tables where the entries are always a fixed width. But, each of these tables tends to occupy its own memory page, which is probably not fully used. So it's a bit like the (lack of) difference between a 1 bit file and a 1 Kb file on a disk.

Data Bus
Someone raised the fact that the data bus is 64-bits wide even in 32-bit mode. True, but the processor can only move memory from registers to the data bus (and vice versa) and those registers can only hold 32-bits of data. The upper 32-bits of the data bus are there, but they're empty in most cases. A dual carriageway is fine, but if everyone sticks to the left-hand lane....

Registers
Now we start on the good stuff! In 64-bit mode the processor has 16 64-bit general purpose registers available, as opposed to 8 32-bit registers. Similar considerations apply to floating-point and MMX registers. This means that a lot of data, particular transient variables, can be stored in registers rather than RAM. So, less RAM to store the data, and no pointers needed to access it. The result is more efficient and considerably faster code.

Instruction Set
The 64-bit instruction set offers a richer selection allowing for more efficient programs.

Calling Convention
In 32-bit mode all parameters to a function are passed on the stack. In 64-bit mode the first four parameters are passed in registers (got to make use of all those lovely extra registers). The result is that a 64-bit program uses less RAM for most function calls; and those function calls execute much more quickly.

I/O Ports
No real difference here. The I/O address space is totally different from the memory address space and is plenty big enough for any ports a system might use.

Conclusion
Will a 64-bit program use more RAM? It's difficult to say. All programs are different, so the answer is "possibly" (and possibly it may be less); but the difference will likely be in the order of 5% at the most.

Will a 64-bit program run faster? Undoubtedly; it's got everything in it's favour so, assuming your compiler is making full use of those extra facilities, there's no contest. And modern compilers are very good. As I said in the other thread, to run a 32-bit OS and programs on a 64-bit processor is a bit like buying a Jaguar V-12 and then pulling the spark plugs off 6 of the cylinders. It still works, but....

It is most emphatically not true that, as you often see stated, the only difference between 32- and 64-bit OSs is the amount of RAM they can address.

I should emphasize that all of this is referring to 64-bit programs running on a 64-bit Operating System. This is the Linux forum, so we don't have to worry about compatibility with 32-bit programs. It's trivial to recompile a program to 64-bit and any distro you use will have done so (or for the hard-cases, you'll be doing it yourself in your Gentoo installation).
Standard User camieabz
(legend) Fri 18-Mar-11 10:02:31
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
I can really only comment with regard to how 64-bit Windows utilizes memory over 32-bit Windows (specifically Vista 64 over XP 32). Unfortunately, MS seems to have decided to allow many of the services, processes and apps access to far more RAM than we have previously been used to.

To give an example, my system a month ago used around 1.5GB of RAM to boot (that's leaving the system along for 20 mins after boot; allowing any security software to get going, and have a scan etc.)

Now, since I made the tweaks I did, it's at 1.1GB, which in my mind is still steep for a boot, but is pretty good for Vista. Disabling pretty much everything relating to group policy, shared networking and other excessive services, processes and tweaking other programs, I reduced the load by 27%. Notice from the pic that the Total/Cached/Free is 4093/3070/306 respectively. Vista likes to try to use all the memory it can for pre-fetch and other similar processes, and speed up the user's experience. I think this is a flawed idea. Although people are creatures of habit, they are not all the same. I would have preferred 75% allocated for regular usage and 25% set aside for other things (if such an allocation would actually make any difference).

The system hasn't increased its boot time noticeably, but there's a definite increase in responsiveness from apps, and while we would expect cached programs to be faster on re-load, the responsiveness of these has increased too. Some say that with all that RAM, you should just use it. WHat's the point of having it, if you don't use it? I say that the boot-up RAM is the computer's usage, while the rest is for me. smile

I doubt if my own future PC needs would exceed 4GB of RAM for a while. I experimented with opening 20 tabs, a sizzeable game and numerous other light and heavy apps to see what swapfile usage got involved. I was up to 2.5GB RAM usage and 1.5GB swapfile (Windows does this without my input), so I set my swpafile minimum to 2GB and the max to 3GB (hopefully reducing the likelihood of the swapfile thrashing the disk anytime soon).

With Windows, I feel it's more a case that the software uses what it likes, rather than what it needs. It's fair that some apps have many features and need extra space, but I'm for disabling as many non-regular features, sevices and tools from an automatic perspective, preferring them to be started when I choose to start them.

Does the system feel faster? The RAM is faster, as is the CPU, and the programming of Vista is such that it will try to second guess my regular usage with pre-fetch, and in general the daily stuff runs faster.

Perhaps I can try a test with XP 32-bit sometime down the line, once all my own concerns are sorted. I do remember that on first impressions of Vista, I felt the increase in hardware had been cancelled by the increase in software. Was a little miffed. Over time I've tweaked the system to the point that it's far faster than the XP for daily usage, but can't guess at like for like benchmarks.

Once W2K and XP get dropped (2020ish? wink ), the differences will probably be there, but not noticable, as software will be even more bloated, and hardware will be different. Prolly have 64 cores per CPU, 10PB SSDs and have electrodes attached to the head rather than input devices. grin

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 10:13:56
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
I'm not sure about Vista, but the way that Windows 7 uses memory confuses many people. It does appear that it uses a lot of RAM, but the truth is that most of that memory is used for caches and is immediately released to applications when it is needed. This gives the impression of a very memory-hungry system when, in reality, it is just a system using memory efficiently.

I'm with those who say, if you've got the RAM you might as well use it. To me it's like spare cash (no pun intended). The great thing about Internet banking is that it lets me immediately move money from my current account into a savings account and back again. So if I'm not using that spare £500 I let the bank use it, and they pay me for the privilege (not as much as I'd like, but...). But as soon as I need it I just transfer it back to the current account and it's immediately available for me to buy that new computer. Windows 7 uses memory a bit like that.


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

Anonymous
(Unregistered)Fri 18-Mar-11 10:55:08
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
(carried over from other thread.Long, short summary at end)

"There's a lot of tosh talked about 64-bit processors. "

Absolutely. So many people use 64bit to mean so many different things, and rarely do they make themselves clear. Me included smile You're clear enough for me so far.

But at least when the comparison is between an AMD64 system (or Intel equivalent) in 32bit mode and the same AMD64 in 64bit mode, nothing changes in the physical hardware. No magick happens when you boot a 64bit OS to make the path to memory suddenly twice as wide and therefore up to twice as fast. Obviously if you were comparing a 32bitwide path to memory with a 64bitwide path to memory, there may well be benefits. But that's not happening in an AMD64 box in 64bit mode (as you obviously know, but other readers may not).

"why not use the extra width of the CPU registers,"

The extra width of the CPU registers doesn't matter unless you're working with an operand bigger than 32bits. How much code does that cover? If your operand is bigger than 32 bits it typically has to come from somewhere. If you're lucky, it's another register, otherwise it's cache or main memory.

Addresses (pointers) in a 64bit world are bigger than 32bits smile

"there are twice as many of them" (registers)

As per your base note in this thread, there generally will be something in this one; it would be rather application dependent, real measurements would show if there's anything significant in it. Have you seen any numbers? I haven't.

"Will a 64-bit program run faster? Undoubtedly;"

Seen any actual evidence (numbers, not architectural theory) for this?

"In practice very little of the data in a program consists of absolute addresses"

Probably true, but I cannot see how there can be any argument about the impact of using 64bit addresses where 32bit would do - if you have a collection of pointers, the 64bit one is twice as big, therefore fewer pointers fit in any given amount of memory (be it cache memory or main memory). There are compiler/linker-dependent ways of bodging a given app's code such that it sees only 32bit addresses. The only case where unnecessarily using 64bit addresses isn't a performance loser is where ALL the data of interest fits in registers, which I see as unlikely.

"It is most emphatically not true that, as you often see stated, the only difference between 32- and 64-bit OSs is the amount of RAM they can address."

Yes, in the AMD64 world (and that is where we are). On the other hand, if we were talking about MIPS processors, or other Linux-capable alternatives...


"I am an interested amateur, not a professional."

Nowt wrong with that, sir.

Summary: Unnecessarily using 64bit addresses because of 64bit ("long") mode is not helpful to performance. It may not typically be a disaster either. There may be other benefits in using the different instruction set which outweigh the impact of using more memory for the same application's code+data. These benefits aren't so much to do with being in 64bit mode as from being in AMD64 native (or "long") mode where more registers and more interesting instructions are available, which is generally a winner. Actual performance comparisons for common apps don't seem to be widely available, which leads me to believe that in most cases, contrary to the hype, there's not much in it.

Complicated, isn't it.
Standard User camieabz
(legend) Fri 18-Mar-11 11:01:49
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
I get the feeling that Win 7 is to Vista as Win 2K was to NT. The better developed, more rounded system. Certainly with multi-thrading and multi core usage growing it should be better in some aspects. Perhaps it's fair to say that Vista is/was the Beta of Win 7.

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 11:21:51
Print Post

Re: 32- and 64-Bit


[re: Anonymous] [link to this post]
 
The extra width of the CPU registers doesn't matter unless you're working with an operand bigger than 32 bits. How much code does that cover?
Well, any code that is processing strings, audio data, video data, images, etc. for starters. And that's not that unusual nowadays. The important part of the data of many programs consists of arrays and structures rather than simple variables. Loading this sort of data from memory, and storing it again is more efficient when the data bus usage is twice as wide.
Have you seen any numbers?
Much of my experience is just that, rather than formal benchmarks. But I have seen (and no, I can't lay my hands on them offhand) benchmarks that show that video processing and database processing, for example, are much faster with a 64-bit OS.
how there can be any argument about the impact of using 64 bit addresses where 32 bit would do
There's no impact other than, as you mention, possibly on cache. And don't forget all the pointer access that you are saving by storing data in those 8 extra registers rather than having to read and write it from memory. Not to mention the reduced use of pointers in the function calling convention.
The only case where unnecessarily using 64 bit addresses isn't a performance loser is where ALL the data of interest fits in registers, which I see as unlikely.
ALL the data of interest - really? Suppose that we have a function that uses 9 local variables. A 32-bit program will have to store all of those on the stack with a consequent memory access every time that it wants to refer to that variable. A 64-bit one will be able to store 8 of those variables in registers; that's quite a saving on memory access. How many functions use a small number of local variables? Probably more than you think.
Yes, in the AMD64 world (and that is where we are).
I'm not sure if that was meant to imply that the only difference in the x86 world is the amount of RAM that can be addressed. If so I hope that I have demonstrated otherwise. I certainly know that when I'm writing 64-bit assembler I use a lot less memory accesses and I have the availability of processor instructions that wouldn't be the case in the 32-bit world. And compilers are cleverer than I am.
Complicated, isn't it.
It certainly is. My challenge to anyone who says there is no difference is to try a bit of 64-bit x86 assembler programming and then come back and argue some more. (Apologies if you already fit into that category.)
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 11:23:49
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
Although Vista has improved over it's lifetime it doesn't hold a candle to 7, especially with the newer hardware. Your comparison to the difference between NT 4 and Windows 2000 (I loved 2000) is most apposite.
Standard User camieabz
(legend) Fri 18-Mar-11 12:07:33
Print Post

Re: 32- and 64-Bit


[re: Anonymous] [link to this post]
 
I've seen 8-bit systems, 16-bits systems, 32bit and now 64-bit.

Generally the overall speeds are similar, but the amount of data and quality of output has increased massively. Perhaps that's the benchmark. Speeds are the same. Everything looks better.

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(fountain of knowledge) Fri 18-Mar-11 12:20:41
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
Perceived speed of systems tends to stay the same. (it's fast enough.) But it takes a lot of power to manage all that eye-candy. Not to mention the fact that computers now do many things at once. I certainly remember the days when if, for example, you wanted to print a document you couldn't do anything else until it had finished.

As in many areas of life, innovation always leads to calls of "do we need it". I'm pretty sure that people realised why we needed 8-bit processors rather than their 4-bit predecessors but ever since then it's been "Do we need...?".
Standard User awoodland
(regular) Fri 01-Apr-11 16:10:26
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
Complicated, isn't it.

It certainly is. My challenge to anyone who says there is no difference is to try a bit of 64-bit x86 assembler programming and then come back and argue some more. (Apologies if you already fit into that category.)


I think you missed another benefit of x64 - you can safely assume that all such processors have at least SSE2 available, which means less branching (and development time) in the tight loops where profiling shows it's worth doing this manually.
Standard User AEP
(knowledge is power) Fri 01-Apr-11 16:17:43
Print Post

Re: 32- and 64-Bit


[re: awoodland] [link to this post]
 
SSE2 isn't exclusive to 64-bit processors, not does it require the processor to be in 64-bit mode so I can't count it as an advantage of 64-bit OSs. It is true that when in 64-bit mode there are 16 SSE registers available, as opposed to the 8 in 32-bit mode - I covered this under the registers part of my OP.
Standard User awoodland
(regular) Fri 01-Apr-11 16:21:54
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
There are no 64-bit processors without SSE though, which means no need for extra branch statements (and hence branch prediction failure) to pick if (SSE2) { ... } else { ... } code paths, which definitely is a feature unique to x64.
Standard User AEP
(knowledge is power) Fri 01-Apr-11 16:30:29
Print Post

Re: 32- and 64-Bit


[re: awoodland] [link to this post]
 
There are precious few processors nowadays without 64-bit instructions. But the discussion that I was raising was whether those 64-bit instructions were used or not. (I.e whether to use 32-bit or 64-bit programs and OSs.) In that context, SSE2 is not exclusive to 64-bit, so can't really be listed as an advantage of 64-bit programs.
Standard User camieabz
(legend) Fri 01-Apr-11 16:36:02
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
http://www.phoronix.com/scan.php?page=article&item=u...

Interesting comparison of 32-bit, 32-bit PAE and 64-bit.

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User 12eason
(eat-sleep-adslguide) Fri 01-Apr-11 16:47:57
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
I think the main problem is the huge amount of extra HD space you need, since the HD is the biggest bottleneck. Real world use of 64bit is pretty stupid unless you have SSDs. The artificial tests that are often done ignore the HD usage down sides.
Standard User AEP
(knowledge is power) Fri 01-Apr-11 17:36:17
Print Post

Re: 32- and 64-Bit


[re: camieabz] [link to this post]
 
That's very interesting, and certainly demonstrates my belief that 64-bit is not just about more memory (although PAE clearly is). Most of the results show the performance increase that I would expect, but I am amazed by the Apache and Disk Transaction benchmarks (which are no doubt connected). If you want to run a web server I think you can see which way to go!
Standard User AEP
(knowledge is power) Fri 01-Apr-11 17:39:17
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
I'd suggest you have a look at the benchmarks that Cammie linked to, one of which specifically demonstrates disk transactions. I'm not quite sure what you mean by "huge amount of extra HD space" - you don't need any more HD space with 64-bit programs than 32-bit ones. Why on earth would you?

Ask web serving companies which OS they use and whether they use SSDs.
Standard User 12eason
(eat-sleep-adslguide) Fri 01-Apr-11 17:46:03
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
Obviously because they are twice the size. Web serving companies all use dedicated storage boxes with raid.
Standard User AEP
(knowledge is power) Fri 01-Apr-11 18:35:23
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
I take it you are not very familiar with the architecture and programming of X86_64 processors. That is the only explanation I can find for that unbelievably ignorant statement.

Stick to topics you know something about.
Standard User 12eason
(eat-sleep-adslguide) Fri 01-Apr-11 19:12:33
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
Dude, you only have to check the disk space. It's easy to prove.
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.
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.
Standard User camieabz
(legend) Fri 01-Apr-11 23:15:11
Print Post

Re: 32- and 64-Bit


[re: Anonymous] [link to this post]
 
This article suggests 5%-10% for 64-bit. Page five is the most pertinent.

I think memory and cache management is improving over time. Prefetch is a great feature of Vista. Most of apps take anything from a split second to two seconds depending on the last time used etc. Persoanlly, I boot up with around 1.25GB used in Vista and with the exception of programs causing memory leaks, have struggled to used more than 3GB at any one time (caching aside).

At one point I had set my swapfile to be 2GB with no maximum, but have since resized it to be at least 4096MB (the amount of RAM), primarily due to memory dump requirements. Now it has a fixed 4GB min and 5GB max. If I need 4GB memory and 5GB swapfile on this system, there will be a problem. smile

I'm not inclined to believe that 64-bit take 'x' space of 32-bit until someone can give me like for like installations of program 'x' 'y' and 'z' on either platform. I have a feeling that the programs designed in 2003-2007 (XP 32-bit dominance) used less because they had to and because designer limitations made it so. It still felt bloated. Now there's a new series of bloatware specially designed for 64-bit and it will use as much as it needs since the typical installation has a minimum of 2GB and a likely of 4GB.

~~~~~~~~~~



© Camieabz 2002-2011 - All rights and lefts reserved.

report this link
Standard User AEP
(knowledge is power) Sat 02-Apr-11 07:19:39
Print Post

Re: 32- and 64-Bit


[re: 12eason] [link to this post]
 
Whatever you say. You sure seem to be an expert on thi subject. crazy
Standard User AEP
(knowledge is power) Sat 02-Apr-11 15:47:30
Print Post

I've Got an Idea


[re: 12eason] [link to this post]
 
I do find all this "handbags at dawn" stuff a little boring, so why not make it a little more interesting?
The world has moved on from bbc basic programs AEP. I doubt your 10 line 'assembler' program...
This is a fairly easy thing to settle. I'm going to put up £1000 that says I can prove that my work is more than "BBC Basic" and/or a "10 line 'assembler' program". A little wager that will prove I know what I'm talking about.

Now I have a conscience, so I wouldn't dream of asking you to match my £1000. Let's make it £100. That odds of 10 to 1 in your favour - pretty generous.

No, wait. It's a nice day. I'd still feel guilt about taking your money. Let's make it odds of 100 to 1. £1000 of my money against £10 of yours says that I can demonstrate that my work is substantially more than a "10 line 'assembler' program". That's a pretty tempting offer, isn't it, seeing as how you know I'm talking BS.

There are three possible outcomes:

1. You take the wager, win it, make me look pretty stupid, and take £1000 off me.

2. You take the wager, lose it, make yourself look pretty stupid, and lose £10.

3. You chicken out, refuse to take the wager, and make yourself look really stupid. (That's the one I'm betting on.)

You've got to ask yourself one question: Do I feel lucky? Well, do ya, punk?
Standard User 12eason
(eat-sleep-adslguide) Sat 02-Apr-11 16:13:12
Print Post

Re: I've Got an Idea


[re: AEP] [link to this post]
 
Throwing money around to protect your ego on a worthless internet forum now AEP? How low can you sink?
Standard User AEP
(knowledge is power) Sat 02-Apr-11 16:16:50
Print Post

Re: I've Got an Idea


[re: 12eason] [link to this post]
 
I take it you chose option 3! smile smile smile

At least we now know who's BSing.
Standard User 12eason
(eat-sleep-adslguide) Sat 02-Apr-11 16:19:27
Print Post

Re: I've Got an Idea


[re: AEP] [link to this post]
 
I still can't believe you wrote all that self-aggrandising nonsense over what was obviously an April fools wind up.
Standard User AEP
(knowledge is power) Sat 02-Apr-11 16:20:43
Print Post

Re: I've Got an Idea


[re: 12eason] [link to this post]
 
Chick, chick, chick, chick, chicken, lay a little egg for me.
Standard User BatBoy
(legend) Sat 02-Apr-11 17:31:01
Print Post

Re: I've Got an Idea


[re: 12eason] [link to this post]
 
In reply to a post by 12eason:
I still can't believe you wrote all that self-aggrandising nonsense over what was obviously an April fools wind up.
I don't think he's got it wink



______________________________________________________________________________attack_the_post_not_the_poster__________________
Standard User AEP
(knowledge is power) Sat 02-Apr-11 17:45:05
Print Post

Re: I've Got an Idea


[re: BatBoy] [link to this post]
 
Nah - an April Fool's got to be before midday. But I certainly got the "Fool" bit. A rather foolish little chicken as it turns out. smile
Standard User sponge34
(eat-sleep-adslguide) Sat 02-Apr-11 18:23:07
Print Post

Re: 32- and 64-Bit


[re: AEP] [link to this post]
 
Sorry for 'holy thread resurrection, batman' but did you look at the history of 64 bit O/S and CPUs?

There was a 64 bit version of OpenVMS and a 64bit Unix to go with the DEC Alpha chip many years, like the late 1980s early 1990s, before wintel got hold of the idea (Itanium 2001).

The Alpha was odd - a friend had to write software for it and, apparently, there were many weird things going on in the microcode that really shouldn't have been.

When Digital were taken over by Compaq the AXP range of chips were sold to Intel and the technology buried whilst Intel tried to make their x86 chips always backwards compatible... rumour has it they gave up on that idea when the Pentium and subsequent architectures came along - even though the Pentium can still run x86 code... I don't think there is a 4004 inside Intel CPUs these days but there certainly was in CPUs up to the 486...

Sorry again for the resurrection.

S.

fish != fork

FSM
Standard User BatBoy
(legend) Sun 03-Apr-11 10:08:29
Print Post

Re: I've Got an Idea


[re: AEP] [link to this post]
 
In reply to a post by AEP:
Nah - an April Fool's got to be before midday. But I certainly got the "Fool" bit
You can kill any fun game with too many rules. Rugby football are two that spring to mind.



______________________________________________________________________________attack_the_post_not_the_poster__________________
Pages in this thread: 1 | 2 | 3 | 4 | 5 | >> (show all)   Print Thread

Jump to