Unfortunately, I'm unable to mod your post up right now (and it deserves it).
Re:Why do they always screw up Moores Law
on
Intel Makes 45nm Chip
·
· Score: 2, Interesting
Even worse is that people actually think it's some sort of technology limitation. It's based on economics more than anything else. The Fab companies can afford to upgrade every 18 months (it's very expensive) because that's the rate at which most consumers (be they businesses or individuals) are willing to upgrade their existing equipment.
Moore's "Law" is just where the lines "how fast are people willing to upgrade" vs. "how much does a new fab cost and we remain profitable" cross. It's more of "Moore's Economic Observations" than anything technological.
Heh, the rumor was that SUN, before opening up the SPARC CPU, took it to Motorola and asked if Moto would build it. Moto looked at it and said, no, but we can make you something better, and showed SUN the 88k. Unfortunately, the 88k died but at least its bus lived on in the first PPC processors.
Yeah... one day if/when you have a business, let's find someone to trash your systems and destroy your backups and see if you still preach the same story. For that matter, let's see your identity get stolen because of the 'net and see you say "aw shucks" when it takes 3+ years of your life or more to straighten out your credit report (no loans, no mortages, no cars, your credit card interest goes sky high, etc. because your credit raiting sucks). Yeah, slap the guy on the wrist who stole your indentity information and send them on their way.
As other posters have said, the bill seems to have included a lot more than restoring some files from a backup tape... IBM people inspected the rest of the systems at the site to make sure that other damage hadn't been caused as well (security backdoors, timebombs, and the like). That can add up to a bit of work depending on the number and types of systems inspected.
Cell counters this problem by using SIMD [wikipedia.org] in combination with what they call "Local Storage". Instead of having to wait for every single memory transfer, threads can read blocks of memory into storage actually on the SPE, process it, and then read it back. All with a couple of instructions, and execution continues even while the memory is been read/written.
The closest that present-day multi-processor computers can get to that is by caching the data. However, that still means that a cache miss will halt execution for many cycles, and each processor / core has to constantly check what other processors / cores have in their caches, ocassionally invalidating them.
What this all adds up to, is a level of efficiency that hasn't been seen before. However, I don't think it's gonna be anyway near "movie quality" graphics, you'd need a farm of Cells for that.
The Cell is not that new of an idea. Just look up the various TI 32xxx series of DSPs (RISC core plus a number of DSPs) which are at least/nearly 10 years old. The idea of this "local storage" is just high speed SRAM on a chip that has a bunch of DMA engines to it. Again, see many DSPs - particularly the SHARC (and again, nearly 10 years old in production). And, of course, SIMD is as old as the hills relatively.
If you are already VPNing into a system, what's the advantage of SSH over telnet?
You get into the habit of using ssh and always use ssh no matter what type of network you are on (and you don't have to spend time figuring out what type you are on). Get used to using telnet and you'll use it sometime when you really didn't want to use it. Plus, ssh does a bunch of things for you automagically if you let it that telnet won't, such as automagically tunneling X and stuff like that. ssh is just all around 'better' and the overhead of encryption/decryption isn't that much on any resonably modern box so "performance" isn't much of an argument, either.
Correctness covers a lot of things. You could even put transactions under that category (correctness of data at query time), for example.
Also, if you were worried about free (as in beer) databases, Microsoft (note that I didn't use M$ like a child) has offered a free RDBMS for a long time (Access, which was replaced by MSDE, which has been replaced by SQL Server Express). So, while MySQL *is* a free alternative to SQL Server, I would argue that your product selection to meet your criteria was flawed (as you didn't actually consider various free alternatives).
And yes, for some queries, MySQL is documented as being able to return incorrect values (as another poster has said). In fact, you should check out this site to see what all else some versions of MySQL do for you that are.... unexpected.
There have been a number of 3D circuit attempts. One of the largest problems to overcome is heat dissipation (particularly from the center of that 3D shape).
Most health issues are solved more effectively and cheapy with preventative measures not corrective measures, especially expensive ones.
Not always. For example, when talking about his donation to malaria research, he said he could have spent the same amount of money buying mosquito nets and bug repellant or insecticide but that wouldn't stop the problem. Two years from now, the mosquito nets would have holes in them and the bug sprays would have been used up and nothing appreciable would have been seen from all that money.
Granted, many issues can be prevented by education (wash your hands often, don't eat undercooked pork, etc.) but, as Gates has also said, it's actually very difficult to give money away to groups who are tackling the problems in the "correct" ways (ways that aren't just covering symptoms but actively searching for ways to end the problem once and for all - such as a cure for malaria).
I think one of Gate's main driving forces right now is to be remembered throughout history as "the man who funded the ending of X" where X is some nasty diseases or something, rather than being "The Microsoft Guy". I think it would have been more interesting if he somehow could have donated the money anonymously, though.
It is not that hard. Most game companies just go the easy and sure way.
When the non-easy and non-sure way can cost the company millions of dollars in losses (look up how much it takes to develop a game these days), the way is even easier and more sure. Cross-platform development isn't that easy. The consoles have it easy because they are fixed hardware and the various companies give out kits (or, like EA, develop their own libraries) to enable them to do so. Supporting cross platform is expensive. It's not just a "put the new guy on it for a week" thing. It's almost exponentially hard. I once worked on a product that worked on Windows NT, AIX, and another small special UNIX - client and server pieces, any/all pieces could be on any one of the platforms - and it was nasty. Not just three QAs - one for NT AIX and other - it was nine (server on each of the three had to interact with any of the three clients). That took time and money to do.
Anyway, like the others said, you'll have to convince Linux users to pay for the stuff and to not "freely distribute" it for the game company to make money and convince the game companies themselves that they can make money making Linux ports of games before you'll see serious gaming on Linux.
From other rumors, it sounds like they are going to introduce a new graphics core around that time. I saw one rumor that said it was going to be wider and on 90nm. Why have an uber-expensive card like this when you are going to beat it with a cheaper card.
I guess it depends on circumstance. If I just walked into a store, got a 360 and took it home and it didnt work, sure I would return it. But if I waited in line 6 hours, fought customers just to purchase a broken item for my kid who is crying, then if I called Microsoft and got the run around, hell yeah I would sue. Of course I dont have the whole story, so he could just be wanted to cash in.
Sorry, that was YOUR choice to I waited in line 6 hours, fought customers just to purchase a broken item for my kid who is crying. No one said you had to bend to every whim of your children and both you and your kid would be better off if you didn't.
Right. But assuming that the timings on the memory are identical on the two systems, the amount of time to fill a cache line should be the same, from the DDR side of the pictures (tCAS, tRAS, all those good things - all at 200MHz which is 5ns signalling - and at DRAM speeds - also measured in double digit ns). The difference between the two will be the additional time between the CPU (Athlon64 or P4) issuing the command and it being finished.
According to one benchmark, the Pentium4 has a latency of ~64ns and the Athlon64 FX is ~57ns. A difference of about 7ns. Now, add that to the amount of time it takes to transfer all the data. Even if the data transfer were instantaneous, that would be around a 12% increase. Since the transfer actually will take some time (assuming that it takes the same time on both CPUs - it's basically the bandwidth to/from main memory), that cuts that increase down a bit. Suppose the transfer was 50ns itself (it'll actually take longer than that). That's 114 vs. 107. Now we're down to 7% increase of total cache line fill time. What really looks scary is if you translate that into CPU cycles. The Athlon64 running at 2.4GHz spends around 256 clock cycles waiting that long while the P4 at 3.6GHz spends around 410 clock cycles waiting. 410 looks a lot bigger than 256 but it is nearly the same amount of time (114ns vs. 107ns). of course, this is what kills performance... high clock speeds waiting. Pretend the P4 could have an IMC that was just like the Athlon64s. That would save it around 26 clock cycles of waiting. Since the P4 is quite narrow, those clock cycles that are spend doing nothing are what kills it. If an instruction stream that was 100 instructions long, all of which can be retired 1 per clock on each CPU, comes along before having to wait on main memory, the P4 would be 100/410 efficient while the Athlon64 would be 100/256 efficient. That's what hurts the P4.
So, while the IMC helps, I would still maintain that it is not the end-all, be-all of memory performance. Just using the numbers from some web site, we get around 7%. I still maintain that what kills the P4 are just high clock rates compared to main memory and this is really bad because of the nature of program codes. We see that streaming things on the P4 runs fast. This is because there is lots of overlap between computation and waiting on memory. More "normal" codes have lots more jerks and starts because of branching and that type of code will kill a P4 while the Athlon64 will handle it much better.
Early in the manufacturing of a part, the speed grades are generally determined by testing. They design the parts to run at 2GHz and everything on the wafer should run at that, but reality being what it is, they get fewer 2GHz capable parts due to defects and the like. Some test to be good if you slow down to 1.6GHz, others 1.8GHz so they are sold at those speeds to recover costs from what would otherwise be chips thrown away. The key, though, is that they were all made with the idea of running at 2GHz. As the manufacturing gets better (bugs fixed in the CPU, etc.) they get more yield at the desired speed of 2GHz (like all of them) but for marketing reasons, they bin select some to sell at 1.6GHz and aome at 1.8GHz to tap other markets. So, the part that will test to run fine at 2GHz is marked to be a 1.6GHz part and sold at a lower price.
Overclocking bets on two things. The first is that the chip was really designed to run at 2.2GHz and the company limits the top speed to 2GHz because of a safety margin. The second is that bin selection for marketing meant that a part actually test-capable of running at 2.2GHz was marked to sell at 1.6GHz.
Celerons (and parts like the 486SX) are typically sold because of another reason. That 2GHz part was designed to have a 1M L2 cache, but manufacturing defects make some of the cache unusable. However, the chip was designed to be able to handle such faults in the cache and 512K of the L2 cache is actually just fine. The chip logic is able to handle having bad parts and just not using those parts of the cache. The defective part is marked as a "Celeron" with 1/2 the L2 cache so the company can actually make money off what would otherwise be something they'd throw away.
The original 486SXs were exactly this. They were 486DXs that had bad FPUs but were otherwise OK. The FPU was disabled and the chip was sold as a 486SX. Because these 486SX chips were popular for the "value" market segment, they actually made a new chip design which was the 486DX without an FPU and ran a line of those designs. This allowed for more chips per wafer, which translates into more yield and more 486SX chips per wafer than 486DX chips on the same wafer, which means more money per wafer.
Man... I'll be glad to see the day when people stop thinking that the IMC is the end-all, be-all of the memory subsystem. Additionally, I'd like to see the day when people realize that the vast (vast (vast)) majority of memory reads are done on an entire cache-line basis, not one byte at a time. The initial latency (time to first byte) is only one part of a cache line read and that is where an IMC shines. When you take the time of the entire cache-line read, the IMC solution is still better but its effect compared to the initial byte latency is greatly reduced simply because you are running at DDR speeds at that point. (a cache line fill for the current x86 DDR dual channel read is a two stroke operation - two 128-bit wide reads - for single channel it's a four stroke operation - four 64-bit wide reads, IIRC). I'm not saying that the IMC is hype or anything of that nature. I'm just saying that it isn't the end-all, be-all of memory performance and anyone thinking that the obvious solution to all CPU woes was the "fantastic invention" of the IMC. The reality is that it does give some performance benefit and due to Moore's Economic Guidelines for processor fabrication growth, there was space on the chip for an IMC and it gave a performance benefit to have it there so it was low-hanging-fruit or the design team at this time because of the increased chip area given by 130nm and smaller processes.
Additionally, IIRC, Yonah is still a single channel chip. The chipset may do dual channel but the chip itself is still single channel. This is better than all-the-way single channel but not as good as all-the-way dual channel.
Additionally, Yonah still doesn't have a great FPU compared to the Athlon64.
Additionally, Yonah still makes a number of design decisions with power consumption being higher priority than performance.
Yet, despite these weaknesses, it still manages to be competitive to a full-blown, dual channel, better FPU, designed for performance desktop chip.
Probably not for the user. As was said, this is a *huge* deal for many existing applications, though. Most applications are written GUI/engine together in the same program (just one program). If you would like 64-bits on OSX, many/most applications will have to be rewritten to seperate the GUI from the rest of the program and then made, as was described, more into a client/server type model. I imagine lots of Mac application writers are pretty pissed about it.
Another issue... we still don't have broadband all over the USA. I'd hook my mother up with a SuSE box or something but I know she'll have to get a dialup ISP. As soon as she has problems, she'll have to call the ISP to deal with it and they will not know what to do with Linux and she'll be stuck and I'll be on the phone trying to diagnose something I'll most likely have no control over. How many of you have called up an ISP and their first thing to say was "can you pull up Internet Explorer?". Saying "I don't have IE" blows their scripts away. Also, it costs more for ISPs to have both Windows and Linux training and the people who take those CSR jobs usually don't know anything about computers anyway and just read scripts.
Luckily, the broadband ISP providers I've had have had Linux knowledgable CSRs (whether by luck that their CSRs happen to be enthusiasts or through actual training) and I ask for them when I can't fix whatever it is. I actually helped (one very large national service carrier) diagnose their network from home and identified a router that they had in another city that was going bad. When I *finally* got to a knowledgable rep (took about 3 days) and explained the problem (for the umpteenth time), he confirmed the issue, thanked me, and it was fixed within 2 hours.
Slashdot Mirror
Unfortunately, I'm unable to mod your post up right now (and it deserves it).
Even worse is that people actually think it's some sort of technology limitation. It's based on economics more than anything else. The Fab companies can afford to upgrade every 18 months (it's very expensive) because that's the rate at which most consumers (be they businesses or individuals) are willing to upgrade their existing equipment.
Moore's "Law" is just where the lines "how fast are people willing to upgrade" vs. "how much does a new fab cost and we remain profitable" cross. It's more of "Moore's Economic Observations" than anything technological.
It's in his trousers!
Heh, the rumor was that SUN, before opening up the SPARC CPU, took it to Motorola and asked if Moto would build it. Moto looked at it and said, no, but we can make you something better, and showed SUN the 88k. Unfortunately, the 88k died but at least its bus lived on in the first PPC processors.
Yeah... one day if/when you have a business, let's find someone to trash your systems and destroy your backups and see if you still preach the same story. For that matter, let's see your identity get stolen because of the 'net and see you say "aw shucks" when it takes 3+ years of your life or more to straighten out your credit report (no loans, no mortages, no cars, your credit card interest goes sky high, etc. because your credit raiting sucks). Yeah, slap the guy on the wrist who stole your indentity information and send them on their way.
As other posters have said, the bill seems to have included a lot more than restoring some files from a backup tape... IBM people inspected the rest of the systems at the site to make sure that other damage hadn't been caused as well (security backdoors, timebombs, and the like). That can add up to a bit of work depending on the number and types of systems inspected.
Cell counters this problem by using SIMD [wikipedia.org] in combination with what they call "Local Storage". Instead of having to wait for every single memory transfer, threads can read blocks of memory into storage actually on the SPE, process it, and then read it back. All with a couple of instructions, and execution continues even while the memory is been read/written.
The closest that present-day multi-processor computers can get to that is by caching the data. However, that still means that a cache miss will halt execution for many cycles, and each processor / core has to constantly check what other processors / cores have in their caches, ocassionally invalidating them.
What this all adds up to, is a level of efficiency that hasn't been seen before. However, I don't think it's gonna be anyway near "movie quality" graphics, you'd need a farm of Cells for that.
The Cell is not that new of an idea. Just look up the various TI 32xxx series of DSPs (RISC core plus a number of DSPs) which are at least/nearly 10 years old. The idea of this "local storage" is just high speed SRAM on a chip that has a bunch of DMA engines to it. Again, see many DSPs - particularly the SHARC (and again, nearly 10 years old in production). And, of course, SIMD is as old as the hills relatively.
If you are already VPNing into a system, what's the advantage of SSH over telnet?
You get into the habit of using ssh and always use ssh no matter what type of network you are on (and you don't have to spend time figuring out what type you are on). Get used to using telnet and you'll use it sometime when you really didn't want to use it. Plus, ssh does a bunch of things for you automagically if you let it that telnet won't, such as automagically tunneling X and stuff like that. ssh is just all around 'better' and the overhead of encryption/decryption isn't that much on any resonably modern box so "performance" isn't much of an argument, either.
Correctness covers a lot of things. You could even put transactions under that category (correctness of data at query time), for example.
Also, if you were worried about free (as in beer) databases, Microsoft (note that I didn't use M$ like a child) has offered a free RDBMS for a long time (Access, which was replaced by MSDE, which has been replaced by SQL Server Express). So, while MySQL *is* a free alternative to SQL Server, I would argue that your product selection to meet your criteria was flawed (as you didn't actually consider various free alternatives).
And yes, for some queries, MySQL is documented as being able to return incorrect values (as another poster has said). In fact, you should check out this site to see what all else some versions of MySQL do for you that are.... unexpected.
Well... they are also comparing it to BETA software (in the case of SQL Server Express Edition (Beta2). So, it is even more flawed from the start.
There have been a number of 3D circuit attempts. One of the largest problems to overcome is heat dissipation (particularly from the center of that 3D shape).
Most health issues are solved more effectively and cheapy with preventative measures not corrective measures, especially expensive ones.
Not always. For example, when talking about his donation to malaria research, he said he could have spent the same amount of money buying mosquito nets and bug repellant or insecticide but that wouldn't stop the problem. Two years from now, the mosquito nets would have holes in them and the bug sprays would have been used up and nothing appreciable would have been seen from all that money.
Granted, many issues can be prevented by education (wash your hands often, don't eat undercooked pork, etc.) but, as Gates has also said, it's actually very difficult to give money away to groups who are tackling the problems in the "correct" ways (ways that aren't just covering symptoms but actively searching for ways to end the problem once and for all - such as a cure for malaria).
I think one of Gate's main driving forces right now is to be remembered throughout history as "the man who funded the ending of X" where X is some nasty diseases or something, rather than being "The Microsoft Guy". I think it would have been more interesting if he somehow could have donated the money anonymously, though.
Same here. I've been touch typing (homerow and all) for over 20 years now. I've never had anything I would even think was carpal tunnel.
It is not that hard. Most game companies just go the easy and sure way.
When the non-easy and non-sure way can cost the company millions of dollars in losses (look up how much it takes to develop a game these days), the way is even easier and more sure. Cross-platform development isn't that easy. The consoles have it easy because they are fixed hardware and the various companies give out kits (or, like EA, develop their own libraries) to enable them to do so. Supporting cross platform is expensive. It's not just a "put the new guy on it for a week" thing. It's almost exponentially hard. I once worked on a product that worked on Windows NT, AIX, and another small special UNIX - client and server pieces, any/all pieces could be on any one of the platforms - and it was nasty. Not just three QAs - one for NT AIX and other - it was nine (server on each of the three had to interact with any of the three clients). That took time and money to do.
Anyway, like the others said, you'll have to convince Linux users to pay for the stuff and to not "freely distribute" it for the game company to make money and convince the game companies themselves that they can make money making Linux ports of games before you'll see serious gaming on Linux.
The other rumor is that Nvidia is coming out with a new core in that timeframe that is better/faster/etc.
From other rumors, it sounds like they are going to introduce a new graphics core around that time. I saw one rumor that said it was going to be wider and on 90nm. Why have an uber-expensive card like this when you are going to beat it with a cheaper card.
For some reason, OpenOffice segmentation faults on me about 90% of the time when I close it running on 32-bit SuSE 10.
Of course... anyone with a desire to do such things would have done them *before* actually turning in notice so it doesn't really solve anything.
I guess it depends on circumstance. If I just walked into a store, got a 360 and took it home and it didnt work, sure I would return it. But if I waited in line 6 hours, fought customers just to purchase a broken item for my kid who is crying, then if I called Microsoft and got the run around, hell yeah I would sue. Of course I dont have the whole story, so he could just be wanted to cash in.
Sorry, that was YOUR choice to I waited in line 6 hours, fought customers just to purchase a broken item for my kid who is crying. No one said you had to bend to every whim of your children and both you and your kid would be better off if you didn't.
Right. But assuming that the timings on the memory are identical on the two systems, the amount of time to fill a cache line should be the same, from the DDR side of the pictures (tCAS, tRAS, all those good things - all at 200MHz which is 5ns signalling - and at DRAM speeds - also measured in double digit ns). The difference between the two will be the additional time between the CPU (Athlon64 or P4) issuing the command and it being finished.
According to one benchmark, the Pentium4 has a latency of ~64ns and the Athlon64 FX is ~57ns. A difference of about 7ns. Now, add that to the amount of time it takes to transfer all the data. Even if the data transfer were instantaneous, that would be around a 12% increase. Since the transfer actually will take some time (assuming that it takes the same time on both CPUs - it's basically the bandwidth to/from main memory), that cuts that increase down a bit. Suppose the transfer was 50ns itself (it'll actually take longer than that). That's 114 vs. 107. Now we're down to 7% increase of total cache line fill time. What really looks scary is if you translate that into CPU cycles. The Athlon64 running at 2.4GHz spends around 256 clock cycles waiting that long while the P4 at 3.6GHz spends around 410 clock cycles waiting. 410 looks a lot bigger than 256 but it is nearly the same amount of time (114ns vs. 107ns). of course, this is what kills performance... high clock speeds waiting. Pretend the P4 could have an IMC that was just like the Athlon64s. That would save it around 26 clock cycles of waiting. Since the P4 is quite narrow, those clock cycles that are spend doing nothing are what kills it. If an instruction stream that was 100 instructions long, all of which can be retired 1 per clock on each CPU, comes along before having to wait on main memory, the P4 would be 100/410 efficient while the Athlon64 would be 100/256 efficient. That's what hurts the P4.
So, while the IMC helps, I would still maintain that it is not the end-all, be-all of memory performance. Just using the numbers from some web site, we get around 7%. I still maintain that what kills the P4 are just high clock rates compared to main memory and this is really bad because of the nature of program codes. We see that streaming things on the P4 runs fast. This is because there is lots of overlap between computation and waiting on memory. More "normal" codes have lots more jerks and starts because of branching and that type of code will kill a P4 while the Athlon64 will handle it much better.
(Numbers like GHz made up for example purposes)
Early in the manufacturing of a part, the speed grades are generally determined by testing. They design the parts to run at 2GHz and everything on the wafer should run at that, but reality being what it is, they get fewer 2GHz capable parts due to defects and the like. Some test to be good if you slow down to 1.6GHz, others 1.8GHz so they are sold at those speeds to recover costs from what would otherwise be chips thrown away. The key, though, is that they were all made with the idea of running at 2GHz. As the manufacturing gets better (bugs fixed in the CPU, etc.) they get more yield at the desired speed of 2GHz (like all of them) but for marketing reasons, they bin select some to sell at 1.6GHz and aome at 1.8GHz to tap other markets. So, the part that will test to run fine at 2GHz is marked to be a 1.6GHz part and sold at a lower price.
Overclocking bets on two things. The first is that the chip was really designed to run at 2.2GHz and the company limits the top speed to 2GHz because of a safety margin. The second is that bin selection for marketing meant that a part actually test-capable of running at 2.2GHz was marked to sell at 1.6GHz.
Celerons (and parts like the 486SX) are typically sold because of another reason. That 2GHz part was designed to have a 1M L2 cache, but manufacturing defects make some of the cache unusable. However, the chip was designed to be able to handle such faults in the cache and 512K of the L2 cache is actually just fine. The chip logic is able to handle having bad parts and just not using those parts of the cache. The defective part is marked as a "Celeron" with 1/2 the L2 cache so the company can actually make money off what would otherwise be something they'd throw away.
The original 486SXs were exactly this. They were 486DXs that had bad FPUs but were otherwise OK. The FPU was disabled and the chip was sold as a 486SX. Because these 486SX chips were popular for the "value" market segment, they actually made a new chip design which was the 486DX without an FPU and ran a line of those designs. This allowed for more chips per wafer, which translates into more yield and more 486SX chips per wafer than 486DX chips on the same wafer, which means more money per wafer.
Man... I'll be glad to see the day when people stop thinking that the IMC is the end-all, be-all of the memory subsystem. Additionally, I'd like to see the day when people realize that the vast (vast (vast)) majority of memory reads are done on an entire cache-line basis, not one byte at a time. The initial latency (time to first byte) is only one part of a cache line read and that is where an IMC shines. When you take the time of the entire cache-line read, the IMC solution is still better but its effect compared to the initial byte latency is greatly reduced simply because you are running at DDR speeds at that point. (a cache line fill for the current x86 DDR dual channel read is a two stroke operation - two 128-bit wide reads - for single channel it's a four stroke operation - four 64-bit wide reads, IIRC). I'm not saying that the IMC is hype or anything of that nature. I'm just saying that it isn't the end-all, be-all of memory performance and anyone thinking that the obvious solution to all CPU woes was the "fantastic invention" of the IMC. The reality is that it does give some performance benefit and due to Moore's Economic Guidelines for processor fabrication growth, there was space on the chip for an IMC and it gave a performance benefit to have it there so it was low-hanging-fruit or the design team at this time because of the increased chip area given by 130nm and smaller processes.
Additionally, IIRC, Yonah is still a single channel chip. The chipset may do dual channel but the chip itself is still single channel. This is better than all-the-way single channel but not as good as all-the-way dual channel.
Additionally, Yonah still doesn't have a great FPU compared to the Athlon64.
Additionally, Yonah still makes a number of design decisions with power consumption being higher priority than performance.
Yet, despite these weaknesses, it still manages to be competitive to a full-blown, dual channel, better FPU, designed for performance desktop chip.
Yeah... I'm sure *that* wouldn't change anything... like the rotation speed, the orbit, or anything else.
Probably not for the user. As was said, this is a *huge* deal for many existing applications, though. Most applications are written GUI/engine together in the same program (just one program). If you would like 64-bits on OSX, many/most applications will have to be rewritten to seperate the GUI from the rest of the program and then made, as was described, more into a client/server type model. I imagine lots of Mac application writers are pretty pissed about it.
Another issue... we still don't have broadband all over the USA. I'd hook my mother up with a SuSE box or something but I know she'll have to get a dialup ISP. As soon as she has problems, she'll have to call the ISP to deal with it and they will not know what to do with Linux and she'll be stuck and I'll be on the phone trying to diagnose something I'll most likely have no control over. How many of you have called up an ISP and their first thing to say was "can you pull up Internet Explorer?". Saying "I don't have IE" blows their scripts away. Also, it costs more for ISPs to have both Windows and Linux training and the people who take those CSR jobs usually don't know anything about computers anyway and just read scripts.
Luckily, the broadband ISP providers I've had have had Linux knowledgable CSRs (whether by luck that their CSRs happen to be enthusiasts or through actual training) and I ask for them when I can't fix whatever it is. I actually helped (one very large national service carrier) diagnose their network from home and identified a router that they had in another city that was going bad. When I *finally* got to a knowledgable rep (took about 3 days) and explained the problem (for the umpteenth time), he confirmed the issue, thanked me, and it was fixed within 2 hours.