Using network drives with any of the network interfaces available on minis will be significantly slower than a local drive. If the point is to have a faster drive, this will defeat the purpose.
If the point is simply to have a bigger drive, then network drives are an option. However, on wireless it will be pretty slow even if you don't care how slow it is. Better to go with ethernet.
"APUs aren't cores that you can schedule threads on."
Right, but the controlling processor can be scheduled and it can context switch. How does it handle the SPEs when it does? There must be some mechanism to keep the SPEs from letting one thread/process's APUlets from bleeding into another's.
Just because they use the POWER ISA doesn't mean they're as powerful as a POWER5 for general purpose code. An MPC7441 (G4) doesn't compare very well to a PowerPC 970FX (G5), but they're both PowerPC.
My point is that there's a decent chance it won't be particularly good at general purpose code, at least in its initial itteration. I think this because it's unlikely Sony will put several POWER5s in their PS3, and Cell is more or less a big vector processor added to a PowerPC processor.
If I'm right, then it certainly won't replace POWER, PowerPC, or x86 in desktop/server use. It might give Itanium a run for its money because that gets used a lot for big numerical jobs.
"With the cell architecture, a lot of complex stuff can be scaled nearly linearly, and at low cost."
Yes, but only things that are easily parallelizable. There's a lot of that on todays computers, but there's a lot that still requires old fashioned brute force.
"I'm curious to see if that pans out, especially of this shows up in a powermac."
I think there's a good chance they'll show up on other architechtures (including PowerPC) as coprocessors on the PCIe bus. But the flexible design means they can just as easily end up on PCs as coprocessors.
As I understand it, the APUs can act semi-independantly but the controlling processor has overall control. If that's true, if the processor wanted to (say) switch to some other process would it have to save all that state to somewhere else before continuing, just as standard processors do now?
As all the APUs have lots of big registers and significant amounts of private memory, wouldn't that be painful?
I believe it does use the POWER ISA, but that doesn't mean it'll be fast. For example, I doubt Sony is going to be using a full POWER5 with SMT in their playstations.
More likely, the chip will be binary compatible with POWER but lacking in performance for general purpose code.
More likely, servers and desktops will continue to use AMD, Intel, or IBM processors with the option to use Cell coprocessors in PCIe cards for applications that need them.
It's unlikely that Cell processors will have comparable performance on non-vector code to current Intel or AMD (or IBM) desktop and server chips. It's a vector processor.
Also, its flexibility means it could be used as a coprocessor on existing systems -- Mac or PC.
The very fact that it scales to such rediculous clock speeds implies that it won't be doing the same general purpose tasks as other processors. I have no doubt that it will have very strong performance in the areas for which it was designed, but it is doubtful that it will be replacing current desktop chips or server chips (including the desktop chips from IBM).
In fact, the very flexible architechture of the chip combined with the fact that PCIe is becoming available means that it's likely that everyone will be able to use these as coprocessors without any other changes to their systems -- Mac or PC.
You can emulate multi-core functionality on a single CPU, and I suspect that would be faster. Communication in SMP machines happens at the speed of main memory (many gigabytes per second) with a latency of substantially less than a microsecond. On dual-core chips, I suspect a lot of that can happen in the latency of L2 cache, which is in the tens of nanoseconds.
Between different boxes, the best you can do with consumer hardware is gigabit ethernet, which will give you a latency of under a millisecond if you're lucky, and under a hundred megabytes per second of bandwidth.
It's not worth it unless they don't have to work closely together.
If you really want to optimize your app for SMP before dual cores are available, just get an SMP machine from AMD or Intel. That's the closest you'll get, though I suspect that would be significantly faster than dual-cores.
The 130 nm AMD parts are pretty bad (not Intel bad, but not great), but the 90 nm parts are actually very good. They're rare at the moment, and they're not the highest speed grades, but they're very reasonable for high performance desktop processors.
HT is very difficult to use meaningfully. Performance gains are trivial unless the two processes behave very well together. Dual cores should actually be able to be used meaningfully together.
"I hope AMD isn't too far behind Intel on this one..."
Looks like a few months.
"Looks like the "Who is Winning the CPU War" line just shifted again."
It would be more impressive if these weren't P4 cores. Heat dissipation and throttling will be a problem. Prescotts already throttle under high load in normal thermal conditions, and now there's two of them. AMD has comitted to keep their dual-core processors under 100 watts total.
The University of Calgary has great research but the undergrad program for comp sci sucks, and continues to deteriorate.
Basically, they're increasing group work so it's easy for people that don't know what they're doing to coast, and they're making core requirements easier to meet.
As a comp sci student at the University of Calgary, I can unequivicably say "yes".
Though I doubt the administration has anything to do with it. It's a very high level course with small size, the kind that's typically snapped up by undergrads in their last year, and it requires permission to enrol. The faculty doesn't like courses like that.
Instead, they like to make it easy for large numbers of undergrads in earlier years to get into easy courses with lots of group work (so they don't all have to know what they're doing). Keeps the numbers up which means funding.
Klein is running public services into the ground despite the fact that our provincial debt is completely gone (so this giant surplus can actually go towards services again). I suspect he's doing this so he can save the day by privatising them.
Also, while young people are often liberal, I see religious nuts that are as bad as when I lived in Houston.
"you don't use linux very much, or not for long periods of time"
I use it as my main desktop OS, but I don't subject it to much punishment. Most of the important stuff happens on my server, which is OpenBSD. I've also never seen it crash, but I'm not very nice to it at all.
"you're extremely lucky"
Reread my post. I'm not lucky. Just because I haven't had a crash on a running system with working hardware doesn't mean I haven't had problems. It's just that my problems relate to the kernel developers breaking things that were already supported on a frighteningly regular basis.
"oh yes some hardware is better supported than others. Ask your hardware vendor to give you open source drivers, I happen to run hardware that is well supported."
The hardware is all fully supported by fully open source drivers in Linux 2.6. The problem is that the kernel developers break things all by themselves.
"And I don't see lot of unstability issues, and I bet lot of people unsing 2.6 here will agree with me that 2.6 has been by far the stablest linux release ever."
If by "stable" you mean "lack of crashes", maybe. I've never seen Linux crash without bad hardware on any kernel so I don't know.
If by "stable" you mean "it's safe to update to the new release of the kernel", then not a chance. Support for my hardware has been broken thrice since the release of 2.6.0 (once with that burner memory leak, once when DMA stopped working on my drives, and once when libata stopped my burner from working) (these have manifested themselves variously on Gentoo, Suse, Fedora and Debian). Right now I have my burner on a Promise IDE card because the kernel doesn't support using it on the same chipset as an SATA drive.
In terms of breaking without my help, that makes Linux worse than Windows in my experience since 2.6.0 was released.
Assuming that distros have the resources to do propper regression testing as the kernel maintainers have done is crazy. The simple fact is that they do not, and distros that have switched to 2.6 are subtly broken all the time now.
I'm happy for you that Linux works so well on 32-way and 512-way computers. Unfortunately, the experience on my single processor computer has been less stellar. If I didn't need Linux for work I would have switched to something else long time ago.
Slashdot Mirror
Using network drives with any of the network interfaces available on minis will be significantly slower than a local drive. If the point is to have a faster drive, this will defeat the purpose.
If the point is simply to have a bigger drive, then network drives are an option. However, on wireless it will be pretty slow even if you don't care how slow it is. Better to go with ethernet.
Mac minis will fit inside some of the larger PC cases, and if you set your fans up right you could even have it inside a running PC.
Why bother with fancy
Orcas eat penguins...
You boot your BSD box monthly?
"APUs aren't cores that you can schedule threads on."
Right, but the controlling processor can be scheduled and it can context switch. How does it handle the SPEs when it does? There must be some mechanism to keep the SPEs from letting one thread/process's APUlets from bleeding into another's.
Isn't that a security risk?
Just because they use the POWER ISA doesn't mean they're as powerful as a POWER5 for general purpose code. An MPC7441 (G4) doesn't compare very well to a PowerPC 970FX (G5), but they're both PowerPC.
My point is that there's a decent chance it won't be particularly good at general purpose code, at least in its initial itteration. I think this because it's unlikely Sony will put several POWER5s in their PS3, and Cell is more or less a big vector processor added to a PowerPC processor.
If I'm right, then it certainly won't replace POWER, PowerPC, or x86 in desktop/server use. It might give Itanium a run for its money because that gets used a lot for big numerical jobs.
"With the cell architecture, a lot of complex stuff can be scaled nearly linearly, and at low cost."
Yes, but only things that are easily parallelizable. There's a lot of that on todays computers, but there's a lot that still requires old fashioned brute force.
"I'm curious to see if that pans out, especially of this shows up in a powermac."
I think there's a good chance they'll show up on other architechtures (including PowerPC) as coprocessors on the PCIe bus. But the flexible design means they can just as easily end up on PCs as coprocessors.
As I understand it, the APUs can act semi-independantly but the controlling processor has overall control. If that's true, if the processor wanted to (say) switch to some other process would it have to save all that state to somewhere else before continuing, just as standard processors do now?
As all the APUs have lots of big registers and significant amounts of private memory, wouldn't that be painful?
I believe it does use the POWER ISA, but that doesn't mean it'll be fast. For example, I doubt Sony is going to be using a full POWER5 with SMT in their playstations.
More likely, the chip will be binary compatible with POWER but lacking in performance for general purpose code.
More likely, servers and desktops will continue to use AMD, Intel, or IBM processors with the option to use Cell coprocessors in PCIe cards for applications that need them.
It's unlikely that Cell processors will have comparable performance on non-vector code to current Intel or AMD (or IBM) desktop and server chips. It's a vector processor.
Also, its flexibility means it could be used as a coprocessor on existing systems -- Mac or PC.
The very fact that it scales to such rediculous clock speeds implies that it won't be doing the same general purpose tasks as other processors. I have no doubt that it will have very strong performance in the areas for which it was designed, but it is doubtful that it will be replacing current desktop chips or server chips (including the desktop chips from IBM).
In fact, the very flexible architechture of the chip combined with the fact that PCIe is becoming available means that it's likely that everyone will be able to use these as coprocessors without any other changes to their systems -- Mac or PC.
You can emulate multi-core functionality on a single CPU, and I suspect that would be faster. Communication in SMP machines happens at the speed of main memory (many gigabytes per second) with a latency of substantially less than a microsecond. On dual-core chips, I suspect a lot of that can happen in the latency of L2 cache, which is in the tens of nanoseconds.
Between different boxes, the best you can do with consumer hardware is gigabit ethernet, which will give you a latency of under a millisecond if you're lucky, and under a hundred megabytes per second of bandwidth.
It's not worth it unless they don't have to work closely together.
If you really want to optimize your app for SMP before dual cores are available, just get an SMP machine from AMD or Intel. That's the closest you'll get, though I suspect that would be significantly faster than dual-cores.
The 130 nm AMD parts are pretty bad (not Intel bad, but not great), but the 90 nm parts are actually very good. They're rare at the moment, and they're not the highest speed grades, but they're very reasonable for high performance desktop processors.
If you have two branchy threads that are very easy on memory I can imagine big performance gains on the order of 50%. That's not very common though.
It's really nothing like HT...
HT is very difficult to use meaningfully. Performance gains are trivial unless the two processes behave very well together. Dual cores should actually be able to be used meaningfully together.
"I hope AMD isn't too far behind Intel on this one..."
Looks like a few months.
"Looks like the "Who is Winning the CPU War" line just shifted again."
It would be more impressive if these weren't P4 cores. Heat dissipation and throttling will be a problem. Prescotts already throttle under high load in normal thermal conditions, and now there's two of them. AMD has comitted to keep their dual-core processors under 100 watts total.
Or do what IBM does and have the processor pass hints to the OS about how well the processes are coexisting together.
The University of Calgary has great research but the undergrad program for comp sci sucks, and continues to deteriorate.
Basically, they're increasing group work so it's easy for people that don't know what they're doing to coast, and they're making core requirements easier to meet.
As a comp sci student at the University of Calgary, I can unequivicably say "yes".
Though I doubt the administration has anything to do with it. It's a very high level course with small size, the kind that's typically snapped up by undergrads in their last year, and it requires permission to enrol. The faculty doesn't like courses like that.
Instead, they like to make it easy for large numbers of undergrads in earlier years to get into easy courses with lots of group work (so they don't all have to know what they're doing). Keeps the numbers up which means funding.
I'm also Calgarian and I gotta disagree.
Klein is running public services into the ground despite the fact that our provincial debt is completely gone (so this giant surplus can actually go towards services again). I suspect he's doing this so he can save the day by privatising them.
Also, while young people are often liberal, I see religious nuts that are as bad as when I lived in Houston.
"you haven't been using linux very long"
Since 2002. Not that long.
"you don't use linux very much, or not for long periods of time"
I use it as my main desktop OS, but I don't subject it to much punishment. Most of the important stuff happens on my server, which is OpenBSD. I've also never seen it crash, but I'm not very nice to it at all.
"you're extremely lucky"
Reread my post. I'm not lucky. Just because I haven't had a crash on a running system with working hardware doesn't mean I haven't had problems. It's just that my problems relate to the kernel developers breaking things that were already supported on a frighteningly regular basis.
"oh yes some hardware is better supported than others. Ask your hardware vendor to give you open source drivers, I happen to run hardware that is well supported."
The hardware is all fully supported by fully open source drivers in Linux 2.6. The problem is that the kernel developers break things all by themselves.
"And I don't see lot of unstability issues, and I bet lot of people unsing 2.6 here will agree with me that 2.6 has been by far the stablest linux release ever."
If by "stable" you mean "lack of crashes", maybe. I've never seen Linux crash without bad hardware on any kernel so I don't know.
If by "stable" you mean "it's safe to update to the new release of the kernel", then not a chance. Support for my hardware has been broken thrice since the release of 2.6.0 (once with that burner memory leak, once when DMA stopped working on my drives, and once when libata stopped my burner from working) (these have manifested themselves variously on Gentoo, Suse, Fedora and Debian). Right now I have my burner on a Promise IDE card because the kernel doesn't support using it on the same chipset as an SATA drive.
In terms of breaking without my help, that makes Linux worse than Windows in my experience since 2.6.0 was released.
Assuming that distros have the resources to do propper regression testing as the kernel maintainers have done is crazy. The simple fact is that they do not, and distros that have switched to 2.6 are subtly broken all the time now.
I'm happy for you that Linux works so well on 32-way and 512-way computers. Unfortunately, the experience on my single processor computer has been less stellar. If I didn't need Linux for work I would have switched to something else long time ago.