Give me a break. Let's not bring up the topic of the UltraSPARC III prefetch bug. Sun hardware has problems too.
PC hardware is less reliable, but with the money you save, you can afford to buy multiple systems for redundancy. In fact, this is what google does.
PC hardware will get more reliable when the market demands it. As PC components make their way into the enterprise (Most notably microprocessors), then the quality will increase.
Now, would -ANYONE- confuse this with the real Fox News?
The point isn't that the viewers would confuse the cartoon for real news. Fox news "brands" themselves as "fair-and-balanced". The cartoon headlines clearly are not fair and balanced. They object to the insinuation that their news is heavily biased towards conservative political views.
Now, I agree that Fox news is hardly "fair-and-balanced", but this is the crux of their grievance -- not that some idiot would confuse a cartoon with real news.
And does one person becoming so obese that they die going to prevent another person from doing it? Experience shows us that it does not. So no, obesity is not self-limiting.
I would argue that obesity is self-limiting in the long run.
Obesity is not a "selected-for" trait, so obese people are less likely to reproduce, thus the obesity genes or genes which produce a behavior which tends towards overeating and inactive behaviours are less likely to get inherited. After some number of generations, the frequency of obese genes will decline.
Let's say you're male. Given a choice between a fat wife and a supermodel wife, all other things being equal, I think the vast majority of men would prefer the supermodel wife.
Good looking people reproduce. Ugly people are less likely to. It's nature's way.
That's not a flaw in the x86 argument. It's a flaw in the compiler. There are good x86 compilers - most notably the Intel compiler and the compiler from the Portland group.
I know this may be hard to hear, but let me break it to you gently...People will be running x86 100 years after I am dead. Blame IBM and Microsoft - the decision was made a few decades ago and there's nothing you or I can do about it. There's far too much software out there already built on x86.
Back in the 80s and early 90s, the ISA actually mattered. You could get a non-negligable performance boost with a good hardware-friendly clean ISA.
These days, the ISA just does not matter anymore. We have enough transistors to make the problem go away in hardware. The ISA is now a 2nd order effect in FP applications and a 3rd order effect in integer applications. Process technology, circuit techniques and microarchitecture are vastly more important.
x86 has been translated to hardware-friendly RISC micro-ops for many years now.
The complicated x86 decoder has been taken out of the critical path by caching decoded instructions in a trace-cache (Intel's method) or a pre-decoded instruction cache (AMD's method).
Brain-dead memory addressing is handled seamlessly in the hardware. Cache-line splits, segments, limit checks etc... All of this is run efficiently on the CPU. The Pentium 4 has a 3.2GHz 2-cycle L1 cache for Christ's sake. All of this done with x86 addressing by the way. Go to www.spec.org and tell me what the fastest CPUs are (Intel and AMD leapfrog each other every quarter).
Computer architects are free to change the underlying micro-ops from one design to another and still maintain the same programming interface so that everything works. The freedom to change the underlying microcode is infinitely useful, because process technology and circuits change over time. These changes necessitate changes in the instruction set! We can and do change the micro-ops and all of this is hidden from the programmer.
Code can be dynamically re-compiled IN THE HARDWARE - completely transparently. Transmeta does this in software. Intel and AMD do this in hardware. The key is to find the most efficient mapping of x86 to the underlying hardware. There are a million ways to do this - expect more in the future.
My last point is this - why should computer users care what the ISA is?
Does grandma care that her web browser runs x86 or Alpha?
Do you write assembly anymore? Do professional developers write assembly anymore?
Are you a back-end compiler writer? If you are, please work on gcc some more so it doesn't suck so much on x86:)
Programmers should want to move to the UPPER levels of the abstraction stack - witness the move to Java and other managed-run-time programming/platforms. The concept of the virtual machine is an implicit admission that the ISA doesn't matter. JITs and managed run-times are in their infancy. In time they will also re-write your code for you on the fly in partnership with the hardware so that the programmer can concentrate on design and robustness instead of performance tuning.
There seem to be lots of complaints about the fairness of the benchmarks.
If you want to compare the performance of CPUs with different ISAs, then you need to have the benchmark source code to compile it to the target ISA. This also brings the performance of the compiler into question but there's just no other way to do it if you want to compare CPUs with different ISAs.
One benchmark that people in the industry use to measure relative CPU performance across different ISAs is the SPEC benchmark. Just about every single computer maker from Dell to HP to Sun have submitted scores. Apple has not. This is in an of itself very telling. What is Apple afraid of? I'm hoping IBM releases a computer based on the G5 so that we can get some idea of the SPEC performance. Apple seems to believe it has something to lose by submitting a SPEC score.
Don't like SPEC? Please suggest some other CPU intensive applications to benchmark that have source code and publish your results.
If there really is a profitable large market for these lower watt CPUs, then either Intel or AMD will just voltage scale down their offerings to be power competitive. It's really not that hard to build a 7 watt x86 CPU. Just do the math with voltage scaling and you'll see that a Banias can be brought down to 7 watts quite easily.
There is no magic here. This processor will not run general-purpose code very well, but it will scream on regular, repetetive code with very predictable memory access patterns. DSP kernels, some types of encryption algorithms, blah blah blah...
It's a very power efficient way to run these kinds of applications.
Do a google search on the Stanford Imagine project for some academic background.
Yes, you would still need a human to do the diagnosis, but that human wouldn't have to go through the grueling years of med school. That person could be a technician studying a 2-3 year degree. The computer would tell the technician what diagnosis to perform (check for abdominal pain, then check eyes, then whatever else the computer comes up with). The key is of course in asking the right questions. The decision tree is vast and appropriate heuristics are needed to prune the tree down to manageable levels. Presumably, you learned all of the right questions in med school. I believe you could teach a computer the correct questions to ask. It would be a tremendous undertaking to build such a vast knowledge-based system, but in theory it is possible.
As for the patient history - that would be the greatest strength of the computer. The computer will remember everything about the patient's history if the data is recorded properly. Given this patient's history it can cross-reference potentially thousands of other similar case histories and do a great job of diagnosis. An ideal database would also have the current information on potentially millions of patients, as well as information on the current state of disease epidemics etc... I'm not saying this will happen tomorrow, but I believe it will happen - maybe in my lifetime or my children's lifetimes.
If the patient wants a real doctor he/she could pay more for one to get a second opinion.
Doctors can't easily be outsourced. Are you going to fly out a patient to India? Video conferencing probably won't cut it.
I think that a bigger threat to the medical professionals will be intelligent databases that are able to diagnose patients better than a doctor could. A doctor that makes a diagnosis is following some sort of standard decision tree that they all learn about in med school. A well trained database could theoretically do the same job. It could potentially be better than a human if it is updated constantly with real life case history and cutting edge reserach. A mere technician could guide the patient through a series of tests that the database suggests, eventually leading to a diagnosis and possible treatment suggestions. You'd still probably need human doctors to do the double check on the computer's findings. Surgeons are probably safe, until the robot overlords take over:)
Lawyers may not be so protected. Drawing up contracts and patents and the like seem like tasks that could easily be moved offshore.
How about running multiple copies of the same OS? Let's say that I'm running a 24/7 application like a webserver. It can run on it's own OS because it always has to be on. It can run totally isolated from the other copy of the OS.
I can run another copy of the OS on the other virtual CPU to do my daily work. If I happen to screw up something on my work CPU and I need to reboot, I can reboot the work-CPU, leaving the webserver happily running along on the first virtual CPU.
Or let's say I want to install something that requires a reboot. I can do that too while the webserver still runs untouched.
Ok, so the average person may not need a webserver. But what about a Tivo-like application? You could run that on it's own OS and have it run 24/7 without interruption.
The Slashdot crowd would probably love the fact that you can run Linux + Windows. Redundancy and isolation make more for more reliable computer systems. I'm sure some very creative people could come up with tons of different application of virtualization technology.
Vanderpool technology is not tied to a multi-core implementation. It's a set of extensions to x86 that make virtualization easier.
Currently, programs like VMWare need to play some extremely ugly tricks to get virtualization to work due to various issues with x86. This technology will make life easier for those wanting to virtualize the CPU.
So, just to be clear... Vanderpool and multicore are completely orthogonal.
Nothing is sacred in the computer industry. People said the same thing about mainframes, until the "low-rent" replacements came in and took over.
ECC is just another commodity feature provided by multiple vendors. It costs more simply because it has more bits (die area on the chip). One vendor's ECC is no better than another's because it's all standardized. Because there is no differentiation between the DRAM that the vendors sell, they are called commodities.
nobody invests the kind of money into shitty x86 systems that would be needed to make something fault tolerant, or have hot swapable CPU's, Motherboard etc....
If there is enough money to be made, someone will do it. Dell has specific business plans to attack the high-margin server market. In their last quarterly conference call they outlined a strategy to push standardization (and hence commoditization) up the enterprise stack.
Vertical business models are no longer economically feasible. You need to invest tons of R&D dollars to be a jack-of-all trades and master-of-none. Horizontal, low cost integrators like Dell will become the computer industry leaders. They can cherry-pick the best components and integrate them in the cheapest most cost efficient manner possible and get favorable pricing due to their size. They leverage the CPU design expertise of Intel and AMD. They leverage the software design expertise of Micrsoft (for Windows) and IBM + the entire open-source community (for Linux). They leverage the vast semiconductor fab capacity of the Korean, Chinese and Japanese DRAM manufacturers. Sun has to compete and win on all of these fronts while at the same time, contain costs to remain competitive. It seems unlikely that their current business model will survive.
A computer is just a system of components - I don't care if you call it enterprise or "big-iron" or "high-rent". There are a specific set of features that are required and once they become standards, the cost of production will go down. Building enterprise systems isn't rocket science. They just require high-uptimes which imply redundancy, fault-tolerance etc... These problems have all been solved years ago.
I used to work for a telecom-equipment maker that sold equipment to the likes of Southwestern Bell, British Telecom etc... If anything defines "enterprise" or "high-uptime" or 99.999999% reliablity - it's the telco -- Try to remember the last time you picked up your phone and didn't hear a dial tone. This industry is awash in cheap equipment now. Vendors are hard pressed to make money on such razor thin margins. That doesn't make their cheap equipment any less reliable or less "enterprise".
Look for Dell to dominate the enterprise in 5-10 years.
Standardization is moving up the enterprise stack. Standard motherboards, CPUs, memory and operating systems are emerging for the server market. Once this happens (when it happens, not "if"), Sun will have no more competitve advantage. All of the components of a server will essentially become commodities and the winner in a commodity market is the lowest cost producer - ie - Not Sun.
Dell spends 0 dollars on R&D. Sun spends boatloads on CPU design, OS development and other generally good things but the return on that investment is NIL in a commodity market.
This technology will become significantly easier to implement once Intel introduces hardware support for virtualization (called VT - Vanderpool technology).
During the Fall 2003 IDF demo, Paul Otellini ran a demo with a Tivo-like app running the Simpsons on one virtual machine, concurrently with another virtual machine booting up windows-xp. One computer was running 2 operating systems and driving 2 monitors concurrently.
802.11B is notoriously power ineffecient for the PDA power envelope.
Wait until Broadcom's new 802.11 chipset starts to proliferate. They've apparently solved some of the major power issues.
Re:Threat to Athlon64: Prescott (not Pentium 4)
on
Athlon 64 Debuts
·
· Score: 1
I believe Opteron is designed to scale to 4, perhaps 8, CPUs...the others go up to the thousands. Opteron would be just fine, however, for a cluster based on 4-cpu nodes.
You believe incorrectly. A shared bus architecture can scale to 4-8 CPUs which is the current state of affairs for Xeon and AthlonMP using the traditional FSB. Opteron's hypertransport can scale to thousands of CPUs. I'm not talking about clustering here.
Shhh...you'll hurt dbx's feelings. I'm not an expert on assembler but occastionally have had to read blocks of SPARC or MIPS code in a debugger. RISC is very comprehensible, which is probably why my computer architecture classes taught it and based CPU-design projects on it (load, store, do stuff to register, easy pipelining, etc.).
Reading x86 isn't that bad. Most software in the world is developed for x86 - there are plenty of tools to deal with it.
Open Source is our hedge against this. Of the four most widely recognized OSS kernels (the BSDs and Linux), all run on more than one non-x86 architecture.
That may be fine, but the reality is that most computers will gravitate towards x86 due to economic reasons.
Now that we have these 64 bit CPUs out in the wild, I would like to see a comparison of 32bit code vs. 64bit code -- To debunk the prevailing opinion that 64bit code will be faster.
Take SPEC, compile it with gcc and generate both 32bit and 64bit code. Let's see how the scores compare.
I'll bet it's a net loss for 64bit code. Has anyone done this?
Re:Threat to Athlon64: Prescott (not Pentium 4)
on
Athlon 64 Debuts
·
· Score: 2, Interesting
The Power4/Itanium/UltraSPARC advantage has always been in their scalability. They have point to point links with gobs of bandwidth to handle many parallel CPUs which are capable of handling large transaction-oriented workloads.
Now that Opteron has Hypertransport -- a highly scalable big bandwidth point to point link protocol, what exactly is the advantage of the other RISC contenders in the high end enterprise space?
A nice instruction set? Sorry, that doesn't cut it anymore. The only thing holding back x86 in the enterprise is the lack of an enterprise class OS. Linux will be dominant here in a few years thanks to large investments made by IBM.
As much as people don't like to admit it. x86 will become the dominant instruction set across all computing sectors with the exception of embedded.
Re:Great for GC and dynamically typed languages
on
Athlon 64 Debuts
·
· Score: 1
These managed-run-time/GC/DT languages are pointer heavy. Your pointers just doubled in size with 64 bits. Therefore, your caches can't hold as much data as before and also your memory bandwidth is narrowed because you need to transfer more data across the bus.
Memory performance has become increasingly dominant in CPU architecture. 64-bit code lowers memory performance for these apps.
Though i hardly see how 'somebody told us a seinor exec said' makes Slashdot.' (I understand that's what the Inquirier bases most of their news on, i thought we had slightly higher standards of reliability)
It's amazing how people spew out assertions without first stopping to think.
The fastest velocity that any human has observed is the speed of light. Some theoretical physicists believe that this is an absolute upper bound on speed:) Last time I checked, that's 3e8 meters/second...
Or in chip dimensions, that's 30 cm/nanosecond. At 10 GHz (0.1 nanosecond cycle time), light can only travel 3 cm in a clock cycle!!! That's approaching the typical dimensions of a chip! That's an absolute upper bound on speed -- this is light traveling through a vaccuum. Electrons traveling through semiconductor material won't go near as fast. You need "on the order" of a clock cycle just to traverse a typical chip. The reality is that as we scale technology forward, it may take several clock cycles just to traverse a chip.
I think you need to stop and reconsider your assertions. Latency is here to stay...it ain't going away unless someone finds a way around the current laws of physics.
What we need to do is realize this and architect around it by trying to hide latency in various ways (caching/buffering, prefetching, etc...)
Slashdot Mirror
Give me a break. Let's not bring up the topic of the UltraSPARC III prefetch bug. Sun hardware has problems too.
PC hardware is less reliable, but with the money you save, you can afford to buy multiple systems for redundancy. In fact, this is what google does.
PC hardware will get more reliable when the market demands it. As PC components make their way into the enterprise (Most notably microprocessors), then the quality will increase.
2) Wasn't IBM working on a new mega-chip that can run x86 and PowerPC codes side by side?
Yes, but this project (based in Vermont) was canned years ago because they couldn't figure out some pretty nasty technical problems.
By the time the X2 comes out, Celeron 733s will probably be cheap enough to put on an add-on card and sell for $49.
Except that Intel doesn't make Celeron 733s anymore.
Now, would -ANYONE- confuse this with the real Fox News?
The point isn't that the viewers would confuse the cartoon for real news. Fox news "brands" themselves as "fair-and-balanced". The cartoon headlines clearly are not fair and balanced. They object to the insinuation that their news is heavily biased towards conservative political views.
Now, I agree that Fox news is hardly "fair-and-balanced", but this is the crux of their grievance -- not that some idiot would confuse a cartoon with real news.
And does one person becoming so obese that they die going to prevent another person from doing it? Experience shows us that it does not. So no, obesity is not self-limiting.
I would argue that obesity is self-limiting in the long run.
Obesity is not a "selected-for" trait, so obese people are less likely to reproduce, thus the obesity genes or genes which produce a behavior which tends towards overeating and inactive behaviours are less likely to get inherited. After some number of generations, the frequency of obese genes will decline.
Let's say you're male. Given a choice between a fat wife and a supermodel wife, all other things being equal, I think the vast majority of men would prefer the supermodel wife.
Good looking people reproduce. Ugly people are less likely to. It's nature's way.
Herein lies the flaw in your argument.
That's not a flaw in the x86 argument. It's a flaw in the compiler. There are good x86 compilers - most notably the Intel compiler and the compiler from the Portland group.
I know this may be hard to hear, but let me break it to you gently...People will be running x86 100 years after I am dead. Blame IBM and Microsoft - the decision was made a few decades ago and there's nothing you or I can do about it. There's far too much software out there already built on x86.
:)
Back in the 80s and early 90s, the ISA actually mattered. You could get a non-negligable performance boost with a good hardware-friendly clean ISA.
These days, the ISA just does not matter anymore. We have enough transistors to make the problem go away in hardware. The ISA is now a 2nd order effect in FP applications and a 3rd order effect in integer applications. Process technology, circuit techniques and microarchitecture are vastly more important.
x86 has been translated to hardware-friendly RISC micro-ops for many years now.
The complicated x86 decoder has been taken out of the critical path by caching decoded instructions in a trace-cache (Intel's method) or a pre-decoded instruction cache (AMD's method).
Brain-dead memory addressing is handled seamlessly in the hardware. Cache-line splits, segments, limit checks etc... All of this is run efficiently on the CPU. The Pentium 4 has a 3.2GHz 2-cycle L1 cache for Christ's sake. All of this done with x86 addressing by the way. Go to www.spec.org and tell me what the fastest CPUs are (Intel and AMD leapfrog each other every quarter).
Computer architects are free to change the underlying micro-ops from one design to another and still maintain the same programming interface so that everything works. The freedom to change the underlying microcode is infinitely useful, because process technology and circuits change over time. These changes necessitate changes in the instruction set! We can and do change the micro-ops and all of this is hidden from the programmer.
Code can be dynamically re-compiled IN THE HARDWARE - completely transparently. Transmeta does this in software. Intel and AMD do this in hardware. The key is to find the most efficient mapping of x86 to the underlying hardware. There are a million ways to do this - expect more in the future.
My last point is this - why should computer users care what the ISA is?
Does grandma care that her web browser runs x86 or Alpha?
Do you write assembly anymore? Do professional developers write assembly anymore?
Are you a back-end compiler writer? If you are, please work on gcc some more so it doesn't suck so much on x86
Programmers should want to move to the UPPER levels of the abstraction stack - witness the move to Java and other managed-run-time programming/platforms. The concept of the virtual machine is an implicit admission that the ISA doesn't matter. JITs and managed run-times are in their infancy. In time they will also re-write your code for you on the fly in partnership with the hardware so that the programmer can concentrate on design and robustness instead of performance tuning.
There seem to be lots of complaints about the fairness of the benchmarks.
If you want to compare the performance of CPUs with different ISAs, then you need to have the benchmark source code to compile it to the target ISA. This also brings the performance of the compiler into question but there's just no other way to do it if you want to compare CPUs with different ISAs.
One benchmark that people in the industry use to measure relative CPU performance across different ISAs is the SPEC benchmark. Just about every single computer maker from Dell to HP to Sun have submitted scores. Apple has not. This is in an of itself very telling. What is Apple afraid of? I'm hoping IBM releases a computer based on the G5 so that we can get some idea of the SPEC performance. Apple seems to believe it has something to lose by submitting a SPEC score.
Don't like SPEC? Please suggest some other CPU intensive applications to benchmark that have source code and publish your results.
If there really is a profitable large market for these lower watt CPUs, then either Intel or AMD will just voltage scale down their offerings to be power competitive. It's really not that hard to build a 7 watt x86 CPU. Just do the math with voltage scaling and you'll see that a Banias can be brought down to 7 watts quite easily.
There is no magic here. This processor will not run general-purpose code very well, but it will scream on regular, repetetive code with very predictable memory access patterns. DSP kernels, some types of encryption algorithms, blah blah blah...
It's a very power efficient way to run these kinds of applications.
Do a google search on the Stanford Imagine project for some academic background.
Yes, you would still need a human to do the diagnosis, but that human wouldn't have to go through the grueling years of med school. That person could be a technician studying a 2-3 year degree. The computer would tell the technician what diagnosis to perform (check for abdominal pain, then check eyes, then whatever else the computer comes up with). The key is of course in asking the right questions. The decision tree is vast and appropriate heuristics are needed to prune the tree down to manageable levels. Presumably, you learned all of the right questions in med school. I believe you could teach a computer the correct questions to ask. It would be a tremendous undertaking to build such a vast knowledge-based system, but in theory it is possible.
As for the patient history - that would be the greatest strength of the computer. The computer will remember everything about the patient's history if the data is recorded properly. Given this patient's history it can cross-reference potentially thousands of other similar case histories and do a great job of diagnosis. An ideal database would also have the current information on potentially millions of patients, as well as information on the current state of disease epidemics etc... I'm not saying this will happen tomorrow, but I believe it will happen - maybe in my lifetime or my children's lifetimes.
If the patient wants a real doctor he/she could pay more for one to get a second opinion.
Doctors can't easily be outsourced. Are you going to fly out a patient to India? Video conferencing probably won't cut it.
:)
I think that a bigger threat to the medical professionals will be intelligent databases that are able to diagnose patients better than a doctor could. A doctor that makes a diagnosis is following some sort of standard decision tree that they all learn about in med school. A well trained database could theoretically do the same job. It could potentially be better than a human if it is updated constantly with real life case history and cutting edge reserach. A mere technician could guide the patient through a series of tests that the database suggests, eventually leading to a diagnosis and possible treatment suggestions. You'd still probably need human doctors to do the double check on the computer's findings. Surgeons are probably safe, until the robot overlords take over
Lawyers may not be so protected. Drawing up contracts and patents and the like seem like tasks that could easily be moved offshore.
Runs multiple OSes? So what?
How about running multiple copies of the same OS? Let's say that I'm running a 24/7 application like a webserver. It can run on it's own OS because it always has to be on. It can run totally isolated from the other copy of the OS.
I can run another copy of the OS on the other virtual CPU to do my daily work. If I happen to screw up something on my work CPU and I need to reboot, I can reboot the work-CPU, leaving the webserver happily running along on the first virtual CPU.
Or let's say I want to install something that requires a reboot. I can do that too while the webserver still runs untouched.
Ok, so the average person may not need a webserver. But what about a Tivo-like application? You could run that on it's own OS and have it run 24/7 without interruption.
The Slashdot crowd would probably love the fact that you can run Linux + Windows. Redundancy and isolation make more for more reliable computer systems. I'm sure some very creative people could come up with tons of different application of virtualization technology.
Vanderpool technology is not tied to a multi-core implementation. It's a set of extensions to x86 that make virtualization easier.
Currently, programs like VMWare need to play some extremely ugly tricks to get virtualization to work due to various issues with x86. This technology will make life easier for those wanting to virtualize the CPU.
So, just to be clear... Vanderpool and multicore are completely orthogonal.
Nothing is sacred in the computer industry. People said the same thing about mainframes, until the "low-rent" replacements came in and took over.
ECC is just another commodity feature provided by multiple vendors. It costs more simply because it has more bits (die area on the chip). One vendor's ECC is no better than another's because it's all standardized. Because there is no differentiation between the DRAM that the vendors sell, they are called commodities.
nobody invests the kind of money into shitty x86 systems that would be needed to make something fault tolerant, or have hot swapable CPU's, Motherboard etc....
If there is enough money to be made, someone will do it. Dell has specific business plans to attack the high-margin server market. In their last quarterly conference call they outlined a strategy to push standardization (and hence commoditization) up the enterprise stack.
Vertical business models are no longer economically feasible. You need to invest tons of R&D dollars to be a jack-of-all trades and master-of-none. Horizontal, low cost integrators like Dell will become the computer industry leaders. They can cherry-pick the best components and integrate them in the cheapest most cost efficient manner possible and get favorable pricing due to their size. They leverage the CPU design expertise of Intel and AMD. They leverage the software design expertise of Micrsoft (for Windows) and IBM + the entire open-source community (for Linux). They leverage the vast semiconductor fab capacity of the Korean, Chinese and Japanese DRAM manufacturers. Sun has to compete and win on all of these fronts while at the same time, contain costs to remain competitive. It seems unlikely that their current business model will survive.
A computer is just a system of components - I don't care if you call it enterprise or "big-iron" or "high-rent". There are a specific set of features that are required and once they become standards, the cost of production will go down. Building enterprise systems isn't rocket science. They just require high-uptimes which imply redundancy, fault-tolerance etc... These problems have all been solved years ago.
I used to work for a telecom-equipment maker that sold equipment to the likes of Southwestern Bell, British Telecom etc... If anything defines "enterprise" or "high-uptime" or 99.999999% reliablity - it's the telco -- Try to remember the last time you picked up your phone and didn't hear a dial tone. This industry is awash in cheap equipment now. Vendors are hard pressed to make money on such razor thin margins. That doesn't make their cheap equipment any less reliable or less "enterprise".
Look for Dell to dominate the enterprise in 5-10 years.
DRAM is a commodity. Even big iron uses DRAM. Why can't other components be reliable and also be commodity?
Dell will eat Sun's lunch.
Standardization is moving up the enterprise stack. Standard motherboards, CPUs, memory and operating systems are emerging for the server market. Once this happens (when it happens, not "if"), Sun will have no more competitve advantage. All of the components of a server will essentially become commodities and the winner in a commodity market is the lowest cost producer - ie - Not Sun.
Dell spends 0 dollars on R&D. Sun spends boatloads on CPU design, OS development and other generally good things but the return on that investment is NIL in a commodity market.
Sun must change or die. McNealy has to go.
This technology will become significantly easier to implement once Intel introduces hardware support for virtualization (called VT - Vanderpool technology).
IDF Demo
During the Fall 2003 IDF demo, Paul Otellini ran a demo with a Tivo-like app running the Simpsons on one virtual machine, concurrently with another virtual machine booting up windows-xp. One computer was running 2 operating systems and driving 2 monitors concurrently.
802.11B is notoriously power ineffecient for the PDA power envelope.
Wait until Broadcom's new 802.11 chipset starts to proliferate. They've apparently solved some of the major power issues.
I believe Opteron is designed to scale to 4, perhaps 8, CPUs...the others go up to the thousands. Opteron would be just fine, however, for a cluster based on 4-cpu nodes.
You believe incorrectly. A shared bus architecture can scale to 4-8 CPUs which is the current state of affairs for Xeon and AthlonMP using the traditional FSB. Opteron's hypertransport can scale to thousands of CPUs. I'm not talking about clustering here.
Shhh...you'll hurt dbx's feelings. I'm not an expert on assembler but occastionally have had to read blocks of SPARC or MIPS code in a debugger. RISC is very comprehensible, which is probably why my computer architecture classes taught it and based CPU-design projects on it (load, store, do stuff to register, easy pipelining, etc.).
Reading x86 isn't that bad. Most software in the world is developed for x86 - there are plenty of tools to deal with it.
Open Source is our hedge against this. Of the four most widely recognized OSS kernels (the BSDs and Linux), all run on more than one non-x86 architecture.
That may be fine, but the reality is that most computers will gravitate towards x86 due to economic reasons.
Now that we have these 64 bit CPUs out in the wild, I would like to see a comparison of 32bit code vs. 64bit code -- To debunk the prevailing opinion that 64bit code will be faster.
Take SPEC, compile it with gcc and generate both 32bit and 64bit code. Let's see how the scores compare.
I'll bet it's a net loss for 64bit code. Has anyone done this?
The Power4/Itanium/UltraSPARC advantage has always been in their scalability. They have point to point links with gobs of bandwidth to handle many parallel CPUs which are capable of handling large transaction-oriented workloads.
Now that Opteron has Hypertransport -- a highly scalable big bandwidth point to point link protocol, what exactly is the advantage of the other RISC contenders in the high end enterprise space?
A nice instruction set? Sorry, that doesn't cut it anymore. The only thing holding back x86 in the enterprise is the lack of an enterprise class OS. Linux will be dominant here in a few years thanks to large investments made by IBM.
As much as people don't like to admit it. x86 will become the dominant instruction set across all computing sectors with the exception of embedded.
These managed-run-time/GC/DT languages are pointer heavy. Your pointers just doubled in size with 64 bits. Therefore, your caches can't hold as much data as before and also your memory bandwidth is narrowed because you need to transfer more data across the bus.
Memory performance has become increasingly dominant in CPU architecture. 64-bit code lowers memory performance for these apps.
Though i hardly see how 'somebody told us a seinor exec said' makes Slashdot.' (I understand that's what the Inquirier bases most of their news on, i thought we had slightly higher standards of reliability)
You're new here aren't you?
It's amazing how people spew out assertions without first stopping to think.
:) Last time I checked, that's 3e8 meters/second...
The fastest velocity that any human has observed is the speed of light. Some theoretical physicists believe that this is an absolute upper bound on speed
Or in chip dimensions, that's 30 cm/nanosecond. At 10 GHz (0.1 nanosecond cycle time), light can only travel 3 cm in a clock cycle!!! That's approaching the typical dimensions of a chip! That's an absolute upper bound on speed -- this is light traveling through a vaccuum. Electrons traveling through semiconductor material won't go near as fast. You need "on the order" of a clock cycle just to traverse a typical chip. The reality is that as we scale technology forward, it may take several clock cycles just to traverse a chip.
I think you need to stop and reconsider your assertions. Latency is here to stay...it ain't going away unless someone finds a way around the current laws of physics.
What we need to do is realize this and architect around it by trying to hide latency in various ways (caching/buffering, prefetching, etc...)