The US must be doing something right, since so much of truly world-class science is done there.
One thing could simply be university management. Here in Europe we're constantly complaining about the academic brain-drain to the US. One reason could be super-hierarchial university culture here. Basically, in the US you get your $XXX grant and you do whatever you wish with the money, whereas here in Europe you have to fight the bureocracy for 2 months to get a pencil sharpener. Which means that the best and brightest get pissed off and go to the US.
I don't think Intel's goal was to kill the competition in performance alone. I thought their goal was to be "somewhat competetive" in performance and kill them in price/performance.
Yes, price/performance was supposed to be the big seller of the Itanium. When Intel started bragging about the Merced in the mid 90:ies the whole project was supposedly based on:
1) The radical VLIW architecture would allow it to run circles around any competition. So at least in Intel marketing, Itanium was supposed to kill the competition in performance also.
2) As Intel was supposed to replace the x86 with Itanium, the economies of scale would also allow Intel to provide superior price/performance.
Using their supposedly superior manufacturing capabilities, Intel was to churn out high volumes of high-margin Itaniums that are way cheaper than RISC CPUs from Sun and IBM.
Not superior manufacturing as such. The point was more along the lines of economy of scale. Much of the price of a processor is the cost of the design, which has to be shared among all the processors sold. Clearly, if you then sell a billion processors where the competition sells a million, the design cost per processor will be much lower for you.
Maybe they will reach this goal eventually.
Given the recent death of Itanium workstations, this goal seems further away than ever before. For 64-bit price/performance x86-64 seems to be the way to go. I wouldn't be too surprised if Intel eventually decides to cancel IA-64 to better concentrate resources on x86-64.
The biggest fiasco for Intel was the Itanium project, which showed while it was a technically-excellent CPU it also exposed the big problem of lack of software to support the CPU.
I wouldn't say excellent. Itanium is a somewhat competetive cpu in the high end market, but it's far from the original goals of running in circles around the competition. Not to mention that currently Sun and IBM are selling dual-core cpu:s, which Intel isn't.
As I see it, Itanium was a very interesting experiment in cpu architecture, that in the end really wasn't enough better than the status quo.
Meanwhile, AMD brought new life to the X86 architecture with a modern developed from scratch CPU design using the Athlon CPU core.
AMD is not alone. Ever since the original Pentium, Intels own x86 cpu:s have essentially been RISC processors inside, just like the Athlon.
Note that AMD's CPU's have truly impressive performance per CPU clock cycle, and AMD's decision to move the memory controller onto the CPU die with the Opteron/Athlon 64 CPU's allows AMD to match the performance of the latest Intel Pentium 4 CPU's without Intel's need to run very high CPU clock speeds.
I agree, I think Intel made a big mistake by focusing on maximizing clock speed for the P4. Apparently they didn't foresee the rising importance of power consumption (and associated cooling).
Re:Maybe I'll do my part next year...
on
Crossroads for Intel
·
· Score: 3, Insightful
I would like them to only release chips within a regularly defined cycle of say 500Mhz speed increases rather than release every improvement they can squeeze out of the chip. I think people would find it easier to plan and commit to a purchase this way. I think processors are fast enough now to handle the needs of the vast majority and theres not a great deal to be gained by flooding the market with differerent processor speeds and people _always_ waiting to maybe purchase the next small incremental release.
Umm, no. That wouldn't be a very good idea. The reason, in short, is price discrimination. By having a wide variety of products, they can better milk the customers. And the customers win too, since they can choose which product best matches their requirement. It's a win-win situation, so to speak.
Uh, that's pretty bad. With my Radeon 9200 i get 1900 fps in glxgears with the opensource dri driver. And the cpu is no screamer either, 800 MHz duron.
As somebody already said, this wouldn't be a very good thing for a single position such as the president. There's always a chance that the person chosen is some nutjob.
OTOH, for a parliamentary election, i.e. where you choose lots of people, this would probably be the best way to get a bunch of people who approximate the population in general. As such, this could be an extremely stable kind of government, since there is little possibility that the opinions of the parliament differ significantly from the population.
The obvious counterpoint to the previous paragraph is that should parliament approximate the population, or should we select the most able individuals to represent us?
The two round system still suffers from strategic voting, i.e. you still have to vote for the lesser evil in the first round to avoid that there's two bigger evils left in the second round.
And besides, two round elections are more expensive, and usually there's significantly less voter turnout in the second round.
I have to agree with RussP here, approval voting is about as simple as it gets, has pretty desirable characteristics, and can settle the issue in one round. About as good as it gets.
The point is that it turns out that a government system where you have a number of single-winner-takes-all districts (like the US Senate or Presidency) favours two big parties.
Or to put it another way, two big parties is the equilibrium position under the current voting system in the US (and some other countries as well).
For example, in many countries the legislative branch is elected from essentially one big district (the entire country), or generally, from pretty big multi-winner districts. In these countries there typically are a quite a lot of political parties, providing a larger diversity of opinion in the legislative branch.
I don't agree with you. If you believe people are so stupid that they can't comprehend to rank candidates in order of preference (Condorcet) or simply put a mark on the ballot for all the candidates they approve (approval voting), how the h*ll do you think they are going to make an informed decision as to which politician best represents their interests?
Yes, there's always going to be some dofus who doesn't get it (Florida anyone?), but for the most part the electorate understands perfectly well how to vote.
Now, the real reason why any of these better voting methods aren't implemented is simply that the current incumbent parties are in power partly because of the current system. As they are the ones with power to enact new laws, why should they enact laws which reduce their own power? Ain't gonna happen, sorry.
You *DO NOT* have to set anything to null to get it gc'd and in fact you can make your code run slower by doing so.
I know that slashbots hate java, but marking out and out lies as insightful is going a bit far with the FUD.
You could of course have checked my responses to the other comments, where I clarify my point so as to avoid any misunderstanding, instead of writing or own little "me too" flame. Oh well, can't expect too much from the "slashbots", now can we?
Setting references to null is only needed in one special case (see links below) and even then the reasone for it should be obvious (you're retaining a reference).
Precisely the point I was trying to make. Evidently I didn't say it clearly enough since my comment got 10 responses flaming me for I something I didn't mean.
Garbage collectors can determin which objects are reachable. You don't need to tell them.
Well duh, that's the entire point of garbage collectors, now isn't it.;-)
The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).
Oh good grief. Isn't that blindingly obvious? Apparently not...
Perhaps I should have clarified my original comment by saying something like "nullifying references to reachable objects you no longer use", considering that my comment got, uh, about 10 responses which all totally missed the point. *sigh*
Yes, in most cases nullifying references is not needed since the application is usually designed so that objects go out of scope when they're no longer used. However, in certain circumstances that approach might not be enough.
Consider a situation like, say:
a = new SomeHugeClass();// some very big object b = a.doSomething(); a = null; if (doSomethingElse(b)) {
a = new SomeHugeClass("foo"); } else {
a = new SomeHugeClass("bar"); }
Now, if doSomethingElse() takes a long time to finish (say, doing i/o or a heavy calculation etc.), or requires lots of memory, it might not be a bad idea to first nullify a, as in the example above.
So? Are you jealous? Seriously, if/. moderation scores are important to you, go see a shrink...
As far as I'm aware, I don't think your entire app is supposed to be in main().
No shit, really? I better go reread all my CS books then... *smirk*
I normally don't ever nullify references, but my code is modular enough, (i.e. not all in main()) that objects go out of scope when they are no longer needed.
Good idea, I try to do that too. However, there are plenty of situations where nullifying an in-scope object is useful.
This is one of the most ridiculous examples of a straw man argument I have seen.
Wrong. The point of a straw man argument is to attack something. What did I attack in my previous post? Oh right, nothing.
The original question, as I understood it, was that the poster wondered how any kind of memory leak would be possible in Java, given that it has GC. I pointed out that if objects that are not needed anymore are still reachable, then the GC cannot collect them, and that can be considered a memory leak. I fail to see how that statement can be understood as an attack against Java; rather it means that a GC cannot protect against ALL kinds of memory mismanagement, although it takes care of most.
1) array access too slow due to boundary checking (no, their optimizer doesn't work for my cases, and this is a problem a lot of scientists/performance hungry people have).
Yeah, well that's why over here in the real world we use Fortran for numerics.;-)
Although some misguided souls use C/C++, but that has its own share of problems.
The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner when you are iterating over a collection or an array.
Great. Give it another decade or two, and Java might even have Fortran style array syntax!;-)
Java should never have memory leaks... All the memory managment should be done by the VM as far as I know... unless there is some advanced stuff i'm just not aware of?
Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..
Ok, you clearly know what you're talking about, a welcome change here on/.:)
I thought your comment about scalability of the system software meant the traditional scalability woes of SMP systems, complicated lock hierarchies and the like. Clearly the problems faced by MPP systems are different, and not as limiting since we can build MPP systems with about 2 orders of magnitude more CPU:s than shared memory systems.
But then the application does something like write(file, offset, &buffer). That can't be handled by microkernel, and must be handled by an OS node. The system call might even be handled by a different node from the I/O node connected to the disk drive. The system call is performed by a "server" on the OS node that may be part of that node's operating system, or might be a user-space daemon.
IIRC the compute nodes on the BG do provide some subset of POSIX, which suggests that the compute kernels forward i/o requests to the i/o nodes, which run Linux. However, the disks are not directly connected to the i/o nodes either, the i/o nodes in turn access a parallel filesystem (GPFS) shared by all i/o nodes.
Since there is only 1 thread on the compute node, it blocks until the i/o request is serviced.
Actually, on the BG there's 2 threads per compute node (2 cpu:s). Depending on configuration, both can compute/communicate or one can be dedicated to computation and the other to communication.
This is not a hard thing to do if there are 60 compute nodes, 2 OS nodes and 2 i/o nodes. But with 100,000 compute nodes, there would have to be hundreds or thousands of OS nodes.
BG does have one i/o node for every 64 compute nodes, meaning that for the full system with 130000 cpu:s, there will be about 1000 i/o nodes. I don't know how many OS nodes there are, probably not that many.
I don't see anything wrong with embedded & non-preemptive it's not like the entire embedded world runs hard real time kernels, I don't on the PPC I use.
I agree, but I didn't say anything about that topic.;-)
Actually being that lifted every single fact from IBM's blue gene website (which I linked to)
What a coincidence, I also have read a lot of the material on that site.
I feel comfortable saying there is no contradiction
The contradiction I pointed out was that first you said that each node runs embedded Linux, in the next sentence you said that each node runs a custom kernel. Clearly both of these cannot be true at the same time.
As I said, compute nodes run the custom kernel and i/o nodes run Linux.
IBM is running a custom non-preemptive kernel, just like they said they did.
I expect a lot of this system's performance depends on the scalability of the system software, and the compilers / libraries.
The blue gene is an all out MPI machine. System software scalability is not that crucial, since every compute node kernel only controls 2 cpu:s. With this modest number of cpu:s per node, I'd guess it doesn't require any extreme trickery from the scalability point of view to achieve near hardware performance.
Software-wise, all the scalability problems lie in the design of the applications.
Did they use infiniband? Or a proprietary interconnect, perhaps?
Proprietary. Actually, it has 3 networks, one mesh network for point-to-point communication, one tree network for collective communication and a service network for disk i/o, control, health monitoring etc. The service network is ethernet IIRC, the other two are custom.
each node has 2 cpus and 4 fpus, custom non-preemptive kernel
I see a contradiction with your previous statement here...:) Luckily, you got it right this time.
As I said in my comment above, the compute nodes run an IBM proprietary kernel (apparently the kernel you're describing), and every 64 compute nodes are managed by an i/o node running Linux.
I can't resist adding that GCC won't use the second FPU on each die...
So what's the problem? It's not like anybody who could afford a highly specialized and expensive machine like this one couldn't afford to shell out some $$$ for xlf.
Anyways, I'm sure that if this modified PPC core gets popular outside multi-million dollar supercomputers, the gcc team will figure out how to utilize the second FPU.
So does this mean the finished product, with almost 10x as many procs will be much faster still?
Yes. Assuming the machine scales linearly (might be possible with linpack) the real thing will have a linpack score 8x than that of the earth simulator.
Impressive yes, but keep in mind that the earth simulator was 5x faster than the next fastest machine when it was introduced in 2002.
It's the result of the linpack benchmark, i.e. the number Rmax in the top500 list, as opposed to Rpeak which is a theoretical estimate of peak performance.
It's a sort of two layer system. The compute nodes (2 cpus per compute node) run a IBM proprietary, very small and simple, kernel. 64 compute nodes are managed by an i/o node running Linux.
Slashdot Mirror
The US must be doing something right, since so much of truly world-class science is done there.
One thing could simply be university management. Here in Europe we're constantly complaining about the academic brain-drain to the US. One reason could be super-hierarchial university culture here. Basically, in the US you get your $XXX grant and you do whatever you wish with the money, whereas here in Europe you have to fight the bureocracy for 2 months to get a pencil sharpener. Which means that the best and brightest get pissed off and go to the US.
I don't think Intel's goal was to kill the competition in performance alone. I thought their goal was to be "somewhat competetive" in performance and kill them in price/performance.
Yes, price/performance was supposed to be the big seller of the Itanium. When Intel started bragging about the Merced in the mid 90:ies the whole project was supposedly based on:
1) The radical VLIW architecture would allow it to run circles around any competition. So at least in Intel marketing, Itanium was supposed to kill the competition in performance also.
2) As Intel was supposed to replace the x86 with Itanium, the economies of scale would also allow Intel to provide superior price/performance.
Using their supposedly superior manufacturing capabilities, Intel was to churn out high volumes of high-margin Itaniums that are way cheaper than RISC CPUs from Sun and IBM.
Not superior manufacturing as such. The point was more along the lines of economy of scale. Much of the price of a processor is the cost of the design, which has to be shared among all the processors sold. Clearly, if you then sell a billion processors where the competition sells a million, the design cost per processor will be much lower for you.
Maybe they will reach this goal eventually.
Given the recent death of Itanium workstations, this goal seems further away than ever before. For 64-bit price/performance x86-64 seems to be the way to go. I wouldn't be too surprised if Intel eventually decides to cancel IA-64 to better concentrate resources on x86-64.
The biggest fiasco for Intel was the Itanium project, which showed while it was a technically-excellent CPU it also exposed the big problem of lack of software to support the CPU.
I wouldn't say excellent. Itanium is a somewhat competetive cpu in the high end market, but it's far from the original goals of running in circles around the competition. Not to mention that currently Sun and IBM are selling dual-core cpu:s, which Intel isn't.
As I see it, Itanium was a very interesting experiment in cpu architecture, that in the end really wasn't enough better than the status quo.
Meanwhile, AMD brought new life to the X86 architecture with a modern developed from scratch CPU design using the Athlon CPU core.
AMD is not alone. Ever since the original Pentium, Intels own x86 cpu:s have essentially been RISC processors inside, just like the Athlon.
Note that AMD's CPU's have truly impressive performance per CPU clock cycle, and AMD's decision to move the memory controller onto the CPU die with the Opteron/Athlon 64 CPU's allows AMD to match the performance of the latest Intel Pentium 4 CPU's without Intel's need to run very high CPU clock speeds.
I agree, I think Intel made a big mistake by focusing on maximizing clock speed for the P4. Apparently they didn't foresee the rising importance of power consumption (and associated cooling).
I would like them to only release chips within a regularly defined cycle of say 500Mhz speed increases rather than release every improvement they can squeeze out of the chip. I think people would find it easier to plan and commit to a purchase this way. I think processors are fast enough now to handle the needs of the vast majority and theres not a great deal to be gained by flooding the market with differerent processor speeds and people _always_ waiting to maybe purchase the next small incremental release.
Umm, no. That wouldn't be a very good idea. The reason, in short, is price discrimination. By having a wide variety of products, they can better milk the customers. And the customers win too, since they can choose which product best matches their requirement. It's a win-win situation, so to speak.
Uh, that's pretty bad. With my Radeon 9200 i get 1900 fps in glxgears with the opensource dri driver. And the cpu is no screamer either, 800 MHz duron.
Mesa started as a software renderer, but since, uh, the DRI thing in xfree86 4.0 many moons ago, Mesa has also provided hardware support.
As somebody already said, this wouldn't be a very good thing for a single position such as the president. There's always a chance that the person chosen is some nutjob.
OTOH, for a parliamentary election, i.e. where you choose lots of people, this would probably be the best way to get a bunch of people who approximate the population in general. As such, this could be an extremely stable kind of government, since there is little possibility that the opinions of the parliament differ significantly from the population.
The obvious counterpoint to the previous paragraph is that should parliament approximate the population, or should we select the most able individuals to represent us?
The two round system still suffers from strategic voting, i.e. you still have to vote for the lesser evil in the first round to avoid that there's two bigger evils left in the second round.
And besides, two round elections are more expensive, and usually there's significantly less voter turnout in the second round.
I have to agree with RussP here, approval voting is about as simple as it gets, has pretty desirable characteristics, and can settle the issue in one round. About as good as it gets.
The point is that it turns out that a government system where you have a number of single-winner-takes-all districts (like the US Senate or Presidency) favours two big parties.
Or to put it another way, two big parties is the equilibrium position under the current voting system in the US (and some other countries as well).
For example, in many countries the legislative branch is elected from essentially one big district (the entire country), or generally, from pretty big multi-winner districts. In these countries there typically are a quite a lot of political parties, providing a larger diversity of opinion in the legislative branch.
I don't agree with you. If you believe people are so stupid that they can't comprehend to rank candidates in order of preference (Condorcet) or simply put a mark on the ballot for all the candidates they approve (approval voting), how the h*ll do you think they are going to make an informed decision as to which politician best represents their interests?
Yes, there's always going to be some dofus who doesn't get it (Florida anyone?), but for the most part the electorate understands perfectly well how to vote.
Now, the real reason why any of these better voting methods aren't implemented is simply that the current incumbent parties are in power partly because of the current system. As they are the ones with power to enact new laws, why should they enact laws which reduce their own power? Ain't gonna happen, sorry.
5, insightful for a lie?
You *DO NOT* have to set anything to null to get it gc'd and in fact you can make your code run slower by doing so.
I know that slashbots hate java, but marking out and out lies as insightful is going a bit far with the FUD.
You could of course have checked my responses to the other comments, where I clarify my point so as to avoid any misunderstanding, instead of writing or own little "me too" flame. Oh well, can't expect too much from the "slashbots", now can we?
Setting references to null is only needed in one special case (see links below) and even then the reasone for it should be obvious (you're retaining a reference).
Precisely the point I was trying to make. Evidently I didn't say it clearly enough since my comment got 10 responses flaming me for I something I didn't mean.
Garbage collectors can determin which objects are reachable. You don't need to tell them.
Well duh, that's the entire point of garbage collectors, now isn't it.
http://www-106.ibm.com/developerworks/java/libr
http://java.sun.com/developer/T
Thanks. Those articles explain precisely what I had in mind.
a = new Class1();
a = new Class2();
The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).
Oh good grief. Isn't that blindingly obvious? Apparently not...
Perhaps I should have clarified my original comment by saying something like "nullifying references to reachable objects you no longer use", considering that my comment got, uh, about 10 responses which all totally missed the point. *sigh*
Yes, in most cases nullifying references is not needed since the application is usually designed so that objects go out of scope when they're no longer used. However, in certain circumstances that approach might not be enough.
Consider a situation like, say:Now, if doSomethingElse() takes a long time to finish (say, doing i/o or a heavy calculation etc.), or requires lots of memory, it might not be a bad idea to first nullify a, as in the example above.
5 insightful?
So? Are you jealous? Seriously, if
As far as I'm aware, I don't think your entire app is supposed to be in main().
No shit, really? I better go reread all my CS books then... *smirk*
I normally don't ever nullify references, but my code is modular enough, (i.e. not all in main()) that objects go out of scope when they are no longer needed.
Good idea, I try to do that too. However, there are plenty of situations where nullifying an in-scope object is useful.
This is one of the most ridiculous examples of a straw man argument I have seen.
Wrong. The point of a straw man argument is to attack something. What did I attack in my previous post? Oh right, nothing.
The original question, as I understood it, was that the poster wondered how any kind of memory leak would be possible in Java, given that it has GC. I pointed out that if objects that are not needed anymore are still reachable, then the GC cannot collect them, and that can be considered a memory leak. I fail to see how that statement can be understood as an attack against Java; rather it means that a GC cannot protect against ALL kinds of memory mismanagement, although it takes care of most.
1) array access too slow due to boundary checking (no, their optimizer doesn't work for my cases, and this is a problem a lot of scientists/performance hungry people have).
Yeah, well that's why over here in the real world we use Fortran for numerics.
Although some misguided souls use C/C++, but that has its own share of problems.
The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner when you are iterating over a collection or an array.
Great. Give it another decade or two, and Java might even have Fortran style array syntax!
Java should never have memory leaks...
All the memory managment should be done by the VM as far as I know...
unless there is some advanced stuff i'm just not aware of?
Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..
Ok, you clearly know what you're talking about, a welcome change here on /. :)
I thought your comment about scalability of the system software meant the traditional scalability woes of SMP systems, complicated lock hierarchies and the like. Clearly the problems faced by MPP systems are different, and not as limiting since we can build MPP systems with about 2 orders of magnitude more CPU:s than shared memory systems.
But then the application does something like write(file, offset, &buffer). That can't be handled by microkernel, and must be handled by an OS node. The system call might even be handled by a different node from the I/O node connected to the disk drive. The system call is performed by a "server" on the OS node that may be part of that node's operating system, or might be a user-space daemon.
IIRC the compute nodes on the BG do provide some subset of POSIX, which suggests that the compute kernels forward i/o requests to the i/o nodes, which run Linux. However, the disks are not directly connected to the i/o nodes either, the i/o nodes in turn access a parallel filesystem (GPFS) shared by all i/o nodes.
Since there is only 1 thread on the compute node, it blocks until the i/o request is serviced.
Actually, on the BG there's 2 threads per compute node (2 cpu:s). Depending on configuration, both can compute/communicate or one can be dedicated to computation and the other to communication.
This is not a hard thing to do if there are 60 compute nodes, 2 OS nodes and 2 i/o nodes. But with 100,000 compute nodes, there would have to be hundreds or thousands of OS nodes.
BG does have one i/o node for every 64 compute nodes, meaning that for the full system with 130000 cpu:s, there will be about 1000 i/o nodes. I don't know how many OS nodes there are, probably not that many.
I don't see anything wrong with embedded & non-preemptive it's not like the entire embedded world runs hard real time kernels, I don't on the PPC I use.
I agree, but I didn't say anything about that topic.
Actually being that lifted every single fact from IBM's blue gene website (which I linked to)
What a coincidence, I also have read a lot of the material on that site.
I feel comfortable saying there is no contradiction
The contradiction I pointed out was that first you said that each node runs embedded Linux, in the next sentence you said that each node runs a custom kernel. Clearly both of these cannot be true at the same time.
As I said, compute nodes run the custom kernel and i/o nodes run Linux.
IBM is running a custom non-preemptive kernel, just like they said they did.
Yes, but I didn't dispute that.
HTH, HAND
I expect a lot of this system's performance depends on the scalability of the system software, and the compilers / libraries.
The blue gene is an all out MPI machine. System software scalability is not that crucial, since every compute node kernel only controls 2 cpu:s. With this modest number of cpu:s per node, I'd guess it doesn't require any extreme trickery from the scalability point of view to achieve near hardware performance.
Software-wise, all the scalability problems lie in the design of the applications.
Did they use infiniband? Or a proprietary interconnect, perhaps?
Proprietary. Actually, it has 3 networks, one mesh network for point-to-point communication, one tree network for collective communication and a service network for disk i/o, control, health monitoring etc. The service network is ethernet IIRC, the other two are custom.
Each node is running an embedded linux kernel.
No.
each node has 2 cpus and 4 fpus, custom non-preemptive kernel
I see a contradiction with your previous statement here...
As I said in my comment above, the compute nodes run an IBM proprietary kernel (apparently the kernel you're describing), and every 64 compute nodes are managed by an i/o node running Linux.
I can't resist adding that GCC won't use the second FPU on each die...
So what's the problem? It's not like anybody who could afford a highly specialized and expensive machine like this one couldn't afford to shell out some $$$ for xlf.
Anyways, I'm sure that if this modified PPC core gets popular outside multi-million dollar supercomputers, the gcc team will figure out how to utilize the second FPU.
So does this mean the finished product, with almost 10x as many procs will be much faster still?
Yes. Assuming the machine scales linearly (might be possible with linpack) the real thing will have a linpack score 8x than that of the earth simulator.
Impressive yes, but keep in mind that the earth simulator was 5x faster than the next fastest machine when it was introduced in 2002.
It's the result of the linpack benchmark, i.e. the number Rmax in the top500 list, as opposed to Rpeak which is a theoretical estimate of peak performance.
I have no idea of what you mean by sustained.
It's a sort of two layer system. The compute nodes (2 cpus per compute node) run a IBM proprietary, very small and simple, kernel. 64 compute nodes are managed by an i/o node running Linux.