"The Direct Marketing Association, an industry group, filed a lawsuit against the FTC last month on grounds the registry unlawfully restricts free speech."
IANAL, but does "free speech" cover calling me on a telephone service that I pay for? I would side with them if the law was talking about hawking from street corners but they are using my money to annoy me.
At a place I worked at a while back, the sysadmin ran a nightly crack on the password file. If it was able to figure out your password, you got an automated nastygram and had to change your password. Doesn't prevent all boneheadedness but it cuts down on it.
Well... the fact is that r0 = 0 is just too handy to have. There are tons of reasons to have r0 hardwired to 0.
NOP = add r0, r0, r0 (actually, add any two registers with the destination r0)
All your arithmetic comparisons are based off subtractions/additions (which are really the same thing). Compare with 0 for a lot of stuff.
Also, lots of assignments are to 0. Lots of if, for, while conditionals are to 0.
Also, there are few addressing modes, one is register + immediate offset. There is no register only addressing mode. How do you do direct addressing? r0 + immediate offset.
Besides, you can use r0 in any instruction you can use any other register, there are no restrictions. Just remember that no matter what you do to/with r0, the value is always (and always will be) 0.
Orthogonality is nice, and it isn't academically clean to have r0 = 0. It is just too handy to have. Zero is used too much and you'd end up having to create special instructions for loading(clearing) registers to zero and such to handle them. Hardcoding r0 to zero actually keeps you from having to add more instructions just to handle the special cases of zero.
If it had been open source, this problem would have never happened. With millions of eyeballs detailing the code, we'd have found and corrected this bug before it ever occurred. Whats more, if the flaw did get thru, the operator could have jumped in and fixed the problem real time.
OMG... man are you brainwashed. First, as impossible as it may seem (gasp), open source software has bugs in it too. Second, even if it were open source, what million eyes would be looking at the code? I bet there isn't any source in the OSS archives that a "million eyes" have looked through. Third, you assume that the operator is an a) programmer, and b) at all familiar with the code enough to debug it and understand just what in the hell the code is doing anyway. Keep repeating your mantras fan boy, may they always give you a warm tingly feeling as you say them.
The driver support for robotics and other real-time systems is also likely to improve dramatically.
Quite possibly, but since they won't be required to release the source since they will be using it in-house (thus the GPL won't be in effect), we don't know if the public source tree will see much/any of it.
To me, it would mean that the memory subsystem of the New Macs is still messed up. There is a substantial increase in bandwidth going to DDR. The fact that the machine can't make use of it means that either the CPU has a bottleneck or that the memory subsystem is still designed around the PC133 throughput and just DDR support was bolted onto that.
Actually, in the past, Apple has had a history of practically crippling their machines by design. Look back at all the 68040 Macs that didn't have a L2 cache while their competition 80386/80486/Pentium did. Sure... the L1 cache was enough. Look at all the Macs that came out with poor memory buses - PowerPC processors that were nice but slaved to PC-100 or PC-133 memory. Sure, some of those design decisions are for cost but like this:
At work, my officemate has a P4@1.8 tied to PC-133 memory - made because at the time PC133 memory was the cheapest memory solution (compared to Rambus). He has a P4-1.6 at home that *smokes* his work machine (by a factor of 2 or more when doing the same work from home) but it uses PC800.
The i860 was a cpu prototype? That's news to me and probably all the users of those Paragons, iPSC860s, Mercury, CSPI, Sky, and a host of other vendors who sold i860 based computers (just to name a few vendors/products I worked with).
I'm hoping you are meaning that a version of Windows NT 3.51, which never made it beyond being a prototype version, existed on the i860.
Average performance per clock is a stupid measurement - used only by people who have no other measurement that they can win by. That's what benchmarks are for... compare the best cpu when released to the best cpu from the other families. That's all that matters (other than comparisons of $$$ in some cases and W/FLOPS in others or by comparing cpu/machine of the same cost - a $1000 machineA vs a $1000 machineB could make sense in some situations).
Otherwise, we should compare this new cpu with the 6502 or the 80286 or the 68040 or some other completely meaningless measurement as well.
Compare on availability. I buy my machines based on how long they will take to get my task done, not on how many IPC it gets. Otherwise, you might as well buy nothing but Athlon 850s instead of a P4-3.06 because, hey... it has higher IPC so it *must* be better and help me get my job done faster.
So you are saying that software has to be backwards AND forwards compatible? So... let me know what oracle you use to figure out future file formats. I have some other questions to ask em.
At some point, you have to say that older software is "dead". Even in OSS, at some point some software is going to fall by the wayside. Of course, if you can find someone to keep updating the older stuff, then you are gtg, but at some point you will just use the new stuff instead of hiring a programmer to continually update older code.
Most importantly, your upgrades were for your reason (to get better functioning/support). They weren't artificially imposed on you by Microsoft, who needed to regularize their money flow.
Actually, they were forced upon me by the folks releasing that OSS software and it didn't matter that I was or wasn't paying them money, it still cost me/us money. Many folks forget that salaries of personnel to maintain hardware/software also adds into the TCO.
To fix a bug that was in the version I had, I had to download the latest source and compile. It would not compile because it depended on several libraries that were versions ahead of the ones I had. I had to then download and install either binary deliverables of those libraries or the source and recommpile them. In at least one case, I had to download and install the latest versions of gcc and glibc in order to even do that -- which broke a number of other things which caused me to upgrade them... So... upgrading that application to a version that fixed the bug actually ended up costing me around 5+ hours of work to get back to a stable state. Luckily, I didn't do all of this on a production machine or it would have caused havoc. However, it did require me to do quite a bit of work to get the production machines up to the point of working, which did cause some downtime on them too, although it was much less than that caused on my own machine.
Cost: ~5 hours of my time for my own machine, ~2 hours of my time for a production machine. My time is costed by my salary at the place I work so ~7 hours of my salary.
For the next few years at least IMO, there will still be a few programs that are only available on MSWindows, which will require some machines to support that. Also, for the "home use", folks are going to want to install MSWindows for things like games. This will cause support issues even if not required by the university to purchase the OS/other software licenses.
Most TCO compares only one system or another. This one assumes that the environments will EITHER be MSWindows or Un*x/Linux and not some hybrid, which is what you see in the real world.
Yeah... jack up their prices like this: http://www.theinquirer.net/?article=7992
force you to upgrade hardware/software on their schedule, not yours.
I think I've probably done more Linux kernel compiles and package upgrades than MS Windows upgrades and patches by a significant amount - and not just because it seemed cool... it was to get some piece of hardware supported better or to enable some functionality/software I needed that wasn't available previously. The worst case was where one piece of software used the absolute latest libraries (3 of them) and every time I had to upgrade that software (seemed like every month) I had to go through the pain of updating those other packages as well... as well as keeping the older versions also installed because the newer stuff broke older software AND keeping the package management system sane by having multiple versions of the same thing installed.
Neither OS is without faults. They are different and approach things differently. You trade one set of problems for another. It all has to be worked out eventually by someone at the keyboard like me.
It means that Linus's employer has licensed a technology, so he will obviously badmouth a competing technology.
I mean... with all the folks who constantly stare dreamy-eyed at Linus, anything he says will instantly be aped by his following. What better way for Transmeta to sell their chips than to have such a spokesman?
Is the need for more register bits because the native datatypes are larger? or is it because you can process more datatypes per clock? What is the resolution of the "chunk" of data? Is the chunk a file? or it is your chunk of data simply an integer or a vector?
For example, MMX, SSE, SSE2, etc. operations are on datatypes that are basically native to the 32-bit cpu already. They simply process multiple pieces of that data at a time. An MMX instruction processes multiple 32-bit, 16-bit, or 8-bit chunks of data at the same time (SIMD), not a larger 64-bit chunk of data. It doesn't use a 64-bit adder (in the conventional sense) to do those operations. An SSE (or SSE2) instruction simply operates on multiple 32-bit and 64-bit FP values (types the 32-bit CPU already handles these types without MMX, SSE, SSE2, Altivec, or whatever). In image editing, is there some call to go to 64-bit integers rather than use the 32-bit and smaller types today? or would processing more 32-bit integers (or more floats/doubles) per clock be better? (I don't know, I'm really asking.) If there is some reason to start using 64-bit integers rather than the 32-bit, 16-bit, and 8-bit integers we are using now, then yes, these things will benefit from 64-bit registers. Simply having an ALU that can add two 64-bit values together doesn't necessarily speed up what you are doing, if all you are doing is manipulating 32-bit integers.
You can increase the size of the SIMD registers, along with making the datapath to memory be much wider, using a 32-bit processor, if what you want is simply better SIMD. It seems what you are saying is that you want more bandwidth to the CPU from memory.
However.... these days, there is little that is "reduced", certainly not the count of legal operands, between processors touted as RISC vs. those touted as CISC (go count the G4 ISA opcodes, then count the P4 ISA opcodes).
Being a 64-bit CPU generally refers to the size of the general purpose integer registers, how many bits wide the ALUs are, how much data can be shipped to/from the register in one data movement, and how many bits of address are used in a virtual address.
The Pentium line is close, but fails the 'test' in the general purpose register department as well as the ALU width department. Also, remember that although an MMX register may be very wide (compared to the general purpose registers), they are treated as if they are some number of smaller registers tacked onto each other. For example, a 64-bit wide MMX register is actually treated (depending on the operation desired) as eight 8-bit registers, four 16-bit registers, or two 32-bit registers. For example, if A, B, C, and D are all 32-bit values, two 64-bit MMX type registers may hold:
The G3 and G4 are 32-bit processors as are the 603 and the 604. The 620 was supposed to be 64-bit but that never left the ground. IBM has been using a 64-bit Power chip for quite some time. IBM is getting ready to release the first 64-bit Power CPU for consumer use this year.
And, as other have stated, whether a CPU is 32-bit or 64-bit has nothing to do with whether is it classified as a "RISC" or a "CISC" processor. Also, make sure you know what the real differences are between what people commonly call "RISC" and "CISC". It has extremely little to do with anything being "reduced" in terms of count. Don't believe me? Go count the number of instruction op codes for the G4 and the current x86 ISA and compare.
It depends. They aren't *only* talking about address lines, sure. But I think it is very subjective to say that the register size is much more important than the addressing.
Scientific applications have been using 64-bit computing for quite a while. What they usually use is floating point for calculations. Double precision floating point (64-bit) has been around for quite a while. Loading/Storing the 64-bit (sometimes 80-bit) FPU (stack) register using single instructions, even though it may require multiple bus transactions, and manipulating them with single instructions has existed for a long time. Scientific applications frequently have very large datasets as well - several GB not being uncommon. For performance reasons, you frequently want to load all this data into memory and not have to worry about processing data in chunks that can fit into memory (although this is an option but is bad for some types of data access and reuse patterns). The data types of scientific applications can typically be handled by 32-bit CPUs today (IEEE double precision floating point - for example) with no problems and those FP registers can be loaded from L1 or L2 64-bits wide 'in one go' - they can even be load/store from memory fast (memory typically operates at a cache-line at a time reads and can be more precisely tuned for writing). It's the amount of data being handled.
Video - I admit, I'm not an expert in this area, but I would imagine that the Altivec/SSE/Whatever are being used heavily here - although these aren't *really* that much different from what the 32-bit CPUs can do already, they just do several at the same time (SIMD). What matters here are very large datastreams (multiple GB) that have to be manipulated. I'm not exactly sure what would need to be done other than having a 64-bit file system though, and that can be (and is) done using 32-bit CPUs today. Maybe simply the ability to pull the entire image into one chunk of memory is what is desired - similar to the scientific computing issues where block read schemes are inefficient because of data access problems and data reuse. If the video files are over ~3GB, then you have a problem on 32-bit systems.
Databases - this is getting the most attention. Here, 64-bit integer manipulation becomes important (not SIMD types either) - Index/address calculations, large trees of data, etc. The other important thing is caching of data so you don't have to hit the disks. For this you want all the memory you can get.
Also... remember that just because a 64-bit CPU will typically have the ability to manipulate and use 64-bit addresses, that does not mean that all 64 address lines will be brought out of the package. For example, I would imagine that more like 40 address lines will be brought out - limiting the amount of physical memory that will actually be able to be used by the CPU to, in this case 256GB, for cost reasons. However, the virtual address space isn't effected by that and will be 64-bit regarless. Of course, over time, more and more address lines may be brought out.
Actually, yes. I listen to a radio station that frequently "forgets" to use the censored versions of the songs they play and they play songs from CDs that you don't usually hear on any other station around here. It is also labeled as an "alternative" station, although it is a little more tame than some college stations I used to listen to. I also listen to a few webcast stations from London and Rome occassionally (not Euro-pop stations).
At least when I turn on my radio, I can pick between, probably 5 genres of music as I feel like it. There is only one genre of music in many places (see the posts elsewhere specifically about China's genre).
Slashdot Mirror
"The Direct Marketing Association, an industry group, filed a lawsuit against the FTC last month on grounds the registry unlawfully restricts free speech."
IANAL, but does "free speech" cover calling me on a telephone service that I pay for? I would side with them if the law was talking about hawking from street corners but they are using my money to annoy me.
"Telemarketers say the registry will devastate their business. "
God I hope so.
I hope they start allowing sign-ups soon.
At a place I worked at a while back, the sysadmin ran a nightly crack on the password file. If it was able to figure out your password, you got an automated nastygram and had to change your password. Doesn't prevent all boneheadedness but it cuts down on it.
http://www.urbanlegends.com/celebrities/bill.gates /gates_memory.html
Freelancer just came out too. It is a different model, not MMOG but player run servers (each can support up to 128 players) and has persistent data.
Well... the fact is that r0 = 0 is just too handy to have. There are tons of reasons to have r0 hardwired to 0.
NOP = add r0, r0, r0 (actually, add any two registers with the destination r0)
All your arithmetic comparisons are based off subtractions/additions (which are really the same thing). Compare with 0 for a lot of stuff.
Also, lots of assignments are to 0. Lots of if, for, while conditionals are to 0.
Also, there are few addressing modes, one is register + immediate offset. There is no register only addressing mode. How do you do direct addressing? r0 + immediate offset.
Besides, you can use r0 in any instruction you can use any other register, there are no restrictions. Just remember that no matter what you do to/with r0, the value is always (and always will be) 0.
Orthogonality is nice, and it isn't academically clean to have r0 = 0. It is just too handy to have. Zero is used too much and you'd end up having to create special instructions for loading(clearing) registers to zero and such to handle them. Hardcoding r0 to zero actually keeps you from having to add more instructions just to handle the special cases of zero.
If it had been open source, this problem would have never happened. With millions of eyeballs detailing the code, we'd have found and corrected this bug before it ever occurred. Whats more, if the flaw did get thru, the operator could have jumped in and fixed the problem real time.
OMG... man are you brainwashed. First, as impossible as it may seem (gasp), open source software has bugs in it too. Second, even if it were open source, what million eyes would be looking at the code? I bet there isn't any source in the OSS archives that a "million eyes" have looked through. Third, you assume that the operator is an a) programmer, and b) at all familiar with the code enough to debug it and understand just what in the hell the code is doing anyway. Keep repeating your mantras fan boy, may they always give you a warm tingly feeling as you say them.
The driver support for robotics and other real-time systems is also likely to improve dramatically.
Quite possibly, but since they won't be required to release the source since they will be using it in-house (thus the GPL won't be in effect), we don't know if the public source tree will see much/any of it.
To me, it would mean that the memory subsystem of the New Macs is still messed up. There is a substantial increase in bandwidth going to DDR. The fact that the machine can't make use of it means that either the CPU has a bottleneck or that the memory subsystem is still designed around the PC133 throughput and just DDR support was bolted onto that.
Actually, in the past, Apple has had a history of practically crippling their machines by design. Look back at all the 68040 Macs that didn't have a L2 cache while their competition 80386/80486/Pentium did. Sure... the L1 cache was enough. Look at all the Macs that came out with poor memory buses - PowerPC processors that were nice but slaved to PC-100 or PC-133 memory. Sure, some of those design decisions are for cost but like this:
At work, my officemate has a P4@1.8 tied to PC-133 memory - made because at the time PC133 memory was the cheapest memory solution (compared to Rambus). He has a P4-1.6 at home that *smokes* his work machine (by a factor of 2 or more when doing the same work from home) but it uses PC800.
The i860 was a cpu prototype? That's news to me and probably all the users of those Paragons, iPSC860s, Mercury, CSPI, Sky, and a host of other vendors who sold i860 based computers (just to name a few vendors/products I worked with).
I'm hoping you are meaning that a version of Windows NT 3.51, which never made it beyond being a prototype version, existed on the i860.
Average performance per clock is a stupid measurement - used only by people who have no other measurement that they can win by. That's what benchmarks are for... compare the best cpu when released to the best cpu from the other families. That's all that matters (other than comparisons of $$$ in some cases and W/FLOPS in others or by comparing cpu/machine of the same cost - a $1000 machineA vs a $1000 machineB could make sense in some situations).
Otherwise, we should compare this new cpu with the 6502 or the 80286 or the 68040 or some other completely meaningless measurement as well.
Compare on availability. I buy my machines based on how long they will take to get my task done, not on how many IPC it gets. Otherwise, you might as well buy nothing but Athlon 850s instead of a P4-3.06 because, hey... it has higher IPC so it *must* be better and help me get my job done faster.
So you are saying that software has to be backwards AND forwards compatible? So... let me know what oracle you use to figure out future file formats. I have some other questions to ask em.
At some point, you have to say that older software is "dead". Even in OSS, at some point some software is going to fall by the wayside. Of course, if you can find someone to keep updating the older stuff, then you are gtg, but at some point you will just use the new stuff instead of hiring a programmer to continually update older code.
No... you get paid to spend your time doing stuff.
Most importantly, your upgrades were for your reason (to get better functioning/support). They weren't artificially imposed on you by Microsoft, who needed to regularize their money flow.
Actually, they were forced upon me by the folks releasing that OSS software and it didn't matter that I was or wasn't paying them money, it still cost me/us money. Many folks forget that salaries of personnel to maintain hardware/software also adds into the TCO.
To fix a bug that was in the version I had, I had to download the latest source and compile. It would not compile because it depended on several libraries that were versions ahead of the ones I had. I had to then download and install either binary deliverables of those libraries or the source and recommpile them. In at least one case, I had to download and install the latest versions of gcc and glibc in order to even do that -- which broke a number of other things which caused me to upgrade them... So... upgrading that application to a version that fixed the bug actually ended up costing me around 5+ hours of work to get back to a stable state. Luckily, I didn't do all of this on a production machine or it would have caused havoc. However, it did require me to do quite a bit of work to get the production machines up to the point of working, which did cause some downtime on them too, although it was much less than that caused on my own machine.
Cost: ~5 hours of my time for my own machine, ~2 hours of my time for a production machine. My time is costed by my salary at the place I work so ~7 hours of my salary.
For the next few years at least IMO, there will still be a few programs that are only available on MSWindows, which will require some machines to support that. Also, for the "home use", folks are going to want to install MSWindows for things like games. This will cause support issues even if not required by the university to purchase the OS/other software licenses.
Most TCO compares only one system or another. This one assumes that the environments will EITHER be MSWindows or Un*x/Linux and not some hybrid, which is what you see in the real world.
Yeah... jack up their prices like this: http://www.theinquirer.net/?article=7992
force you to upgrade hardware/software on their schedule, not yours.
I think I've probably done more Linux kernel compiles and package upgrades than MS Windows upgrades and patches by a significant amount - and not just because it seemed cool... it was to get some piece of hardware supported better or to enable some functionality/software I needed that wasn't available previously. The worst case was where one piece of software used the absolute latest libraries (3 of them) and every time I had to upgrade that software (seemed like every month) I had to go through the pain of updating those other packages as well... as well as keeping the older versions also installed because the newer stuff broke older software AND keeping the package management system sane by having multiple versions of the same thing installed.
Neither OS is without faults. They are different and approach things differently. You trade one set of problems for another. It all has to be worked out eventually by someone at the keyboard like me.
It means that Linus's employer has licensed a technology, so he will obviously badmouth a competing technology.
I mean... with all the folks who constantly stare dreamy-eyed at Linus, anything he says will instantly be aped by his following. What better way for Transmeta to sell their chips than to have such a spokesman?
Is the need for more register bits because the native datatypes are larger? or is it because you can process more datatypes per clock? What is the resolution of the "chunk" of data? Is the chunk a file? or it is your chunk of data simply an integer or a vector?
For example, MMX, SSE, SSE2, etc. operations are on datatypes that are basically native to the 32-bit cpu already. They simply process multiple pieces of that data at a time. An MMX instruction processes multiple 32-bit, 16-bit, or 8-bit chunks of data at the same time (SIMD), not a larger 64-bit chunk of data. It doesn't use a 64-bit adder (in the conventional sense) to do those operations. An SSE (or SSE2) instruction simply operates on multiple 32-bit and 64-bit FP values (types the 32-bit CPU already handles these types without MMX, SSE, SSE2, Altivec, or whatever). In image editing, is there some call to go to 64-bit integers rather than use the 32-bit and smaller types today? or would processing more 32-bit integers (or more floats/doubles) per clock be better? (I don't know, I'm really asking.) If there is some reason to start using 64-bit integers rather than the 32-bit, 16-bit, and 8-bit integers we are using now, then yes, these things will benefit from 64-bit registers. Simply having an ALU that can add two 64-bit values together doesn't necessarily speed up what you are doing, if all you are doing is manipulating 32-bit integers.
You can increase the size of the SIMD registers, along with making the datapath to memory be much wider, using a 32-bit processor, if what you want is simply better SIMD. It seems what you are saying is that you want more bandwidth to the CPU from memory.
However.... these days, there is little that is "reduced", certainly not the count of legal operands, between processors touted as RISC vs. those touted as CISC (go count the G4 ISA opcodes, then count the P4 ISA opcodes).
Being a 64-bit CPU generally refers to the size of the general purpose integer registers, how many bits wide the ALUs are, how much data can be shipped to/from the register in one data movement, and how many bits of address are used in a virtual address.
The Pentium line is close, but fails the 'test' in the general purpose register department as well as the ALU width department. Also, remember that although an MMX register may be very wide (compared to the general purpose registers), they are treated as if they are some number of smaller registers tacked onto each other. For example, a 64-bit wide MMX register is actually treated (depending on the operation desired) as eight 8-bit registers, four 16-bit registers, or two 32-bit registers. For example, if A, B, C, and D are all 32-bit values, two 64-bit MMX type registers may hold:
MMXreg1: A:B
MMXreg2: C:D
and if you perform a 32-bit MMX addition you get:
MMXreg3: A+C:B+D
The G3 and G4 are 32-bit processors as are the 603 and the 604. The 620 was supposed to be 64-bit but that never left the ground. IBM has been using a 64-bit Power chip for quite some time. IBM is getting ready to release the first 64-bit Power CPU for consumer use this year.
And, as other have stated, whether a CPU is 32-bit or 64-bit has nothing to do with whether is it classified as a "RISC" or a "CISC" processor. Also, make sure you know what the real differences are between what people commonly call "RISC" and "CISC". It has extremely little to do with anything being "reduced" in terms of count. Don't believe me? Go count the number of instruction op codes for the G4 and the current x86 ISA and compare.
It depends. They aren't *only* talking about address lines, sure. But I think it is very subjective to say that the register size is much more important than the addressing.
Scientific applications have been using 64-bit computing for quite a while. What they usually use is floating point for calculations. Double precision floating point (64-bit) has been around for quite a while. Loading/Storing the 64-bit (sometimes 80-bit) FPU (stack) register using single instructions, even though it may require multiple bus transactions, and manipulating them with single instructions has existed for a long time. Scientific applications frequently have very large datasets as well - several GB not being uncommon. For performance reasons, you frequently want to load all this data into memory and not have to worry about processing data in chunks that can fit into memory (although this is an option but is bad for some types of data access and reuse patterns). The data types of scientific applications can typically be handled by 32-bit CPUs today (IEEE double precision floating point - for example) with no problems and those FP registers can be loaded from L1 or L2 64-bits wide 'in one go' - they can even be load/store from memory fast (memory typically operates at a cache-line at a time reads and can be more precisely tuned for writing). It's the amount of data being handled.
Video - I admit, I'm not an expert in this area, but I would imagine that the Altivec/SSE/Whatever are being used heavily here - although these aren't *really* that much different from what the 32-bit CPUs can do already, they just do several at the same time (SIMD). What matters here are very large datastreams (multiple GB) that have to be manipulated. I'm not exactly sure what would need to be done other than having a 64-bit file system though, and that can be (and is) done using 32-bit CPUs today. Maybe simply the ability to pull the entire image into one chunk of memory is what is desired - similar to the scientific computing issues where block read schemes are inefficient because of data access problems and data reuse. If the video files are over ~3GB, then you have a problem on 32-bit systems.
Databases - this is getting the most attention. Here, 64-bit integer manipulation becomes important (not SIMD types either) - Index/address calculations, large trees of data, etc. The other important thing is caching of data so you don't have to hit the disks. For this you want all the memory you can get.
Also... remember that just because a 64-bit CPU will typically have the ability to manipulate and use 64-bit addresses, that does not mean that all 64 address lines will be brought out of the package. For example, I would imagine that more like 40 address lines will be brought out - limiting the amount of physical memory that will actually be able to be used by the CPU to, in this case 256GB, for cost reasons. However, the virtual address space isn't effected by that and will be 64-bit regarless. Of course, over time, more and more address lines may be brought out.
I was going to post the very same thing.
Actually, yes. I listen to a radio station that frequently "forgets" to use the censored versions of the songs they play and they play songs from CDs that you don't usually hear on any other station around here. It is also labeled as an "alternative" station, although it is a little more tame than some college stations I used to listen to. I also listen to a few webcast stations from London and Rome occassionally (not Euro-pop stations).
At least when I turn on my radio, I can pick between, probably 5 genres of music as I feel like it. There is only one genre of music in many places (see the posts elsewhere specifically about China's genre).