Normally, I would agree, but I must disagree in this case. The vast majority of people in the U.S. are science-illiterate and easily swayed by sensational headlines (For example, last week slashdot posted a story on how the background radiation in Fukushima is less than that of Denver, yet people panic over radiation exposure in Japan, but not Colorado.). I worry that a similar backlash against GM crops could negatively affect the world's food supply.
While we can disparage crops that have been crafted to withstand copious amounts of insecticide, please keep in mind that there are 7 billion people on the planet, and all of them need to be fed. Much of the world depends upon the United States' agricultural output. GM helps boost this output. While the American consumer can withstand a few cents increase in cost due to decreased food supply, the same increase can trigger food riots in less fortunate countries. If the United States' agricultural output is enhanced by GM, then I'm all for it. I worry that shunning GM food in the US could hurt further investment/development.
CUDA was released, supported by NVIDIA GPUs, in early 2007. The first OpenCL specification was not released until late 2008 (OpenCL has not been around for 4 years, as you claim). As for which is more popular, I'm afraid that you have this backwards too. The dominant market force for GPU computing is supercomputing. How many of the top 5 supercomputers used AMD GPUs? Zero. How many use NVIDIA GPUs? Three. And they're all using CUDA because it's more feature rich---it can do fancy things like direct memory copies between infiniband interconnects and GPU memory.
FYI: OpenCL on NVIDIA is implemented on top of CUDA, so you're still using CUDA if you're using OpenCL on NVIDIA.
Surprise, surprise, I have the feeling that most of you haven't actually read the article. The article is not arguing that GPUs are inherently flawed. Also, the article is not an NVIDIA-vs-AMD competition. Rather, the author tests software on each platform. It's the software that is bad, not the GPUs themselves. For instance, the NVIDIA GPU does quite well with Arcsoft and Xilisoft; this wouldn't be possible if GPUs were somehow broken for transcoding. After all, as others have pointed out here, floating point support is actually quite good on modern GPUs.
Still, poor software shouldn't come too much as a surprise. While CUDA and OpenCL certainly make GPU-based computing easier, it is still a relatively new technology that only a few programmers know how to use efficiently. I'm also not sure that the market pressure is there yet from consumers for efficient GPU-based applications (how many of them actually know what a GPU is?).
I think the time of the PS3 clusters has past. The Cell processor was released back in 2006! IBM released a few upgraded processors, mostly improving double-precision performance, but those systems are really cost prohibitive.
Assuming you can deal with PCIe latency, GPUs are the way to go.
What does SLI give you in CUDA? The newer GeForce cards support direct GPU-to-GPU memory copies, assuming they are on the same PCIe bus (NUMA systems might have multiple PCIe buses).
The system has a theoretical peak ~9.1 TFLOPS, single precision (simultaneously maxing out all CPUs and GPUs). I wish the GPUs had more individual memory (~1.25GB each), but we would have quickly broken our budget had we gone for Tesla-grade cards.
If you are already going to be in New Mexico to see the Very Large Array, try to swing by the Carlsbad Caverns: http://www.nps.gov/cave/index.htm
Sure, it's not tech-oriented, but I'm sure you can get your geology geeking on. It's not often one is in the area (BFE New Mexico), so take the opportunity. The caverns are not to be missed!
It took a custom CPU to knock out the Tianhe (GPU-based) supercomputer. Did IBM plan to use an existing POWER chip, or were they trying to develop a new Cell-like (or other boutique) processor? IBM keeps saying that the future of Cell isn't dead. I wonder if NCSA thought they'd get more bang for their buck with a GPU-based solution?
The reports currently are that the train cars detailed because of a collision, not because they were simply going too fast and took a sharp turn on faulty rails. Can you really expect cars to remain on the tracks after a collision?
You might be forgetting that the Cell was released in 2006. The multi-core CPUs from Intel today are only just now starting to reach the peak theoretical performance than the Cell. Also, your Radeon was released when? 2009? Given Moore's law (which is still in effect for parallel architectures like Cell and GPUs), the factor by which your Radeon beats the Cell isn't too bad. Also note that the compute performance of an I/O device like a GPU can be limited by the I/O bus; both in terms of bandwidth and latency. GPUs used for computing typically perform best on large chunk, long running, computations. I believe that the Cell could possibly still trounce a modern GPU for smaller, less-memory intensive, jobs since it has access to main memory and is scheduled directly by the operating system (there's no GPU driver middle-man). This will change soon of course with on-chip integrated CPU/GPU solutions. However, it took nearly 5 years after Cell's release to get to that point.
So don't rag too much on Cell. It's very old, if not ancient, by microprocessor standards.
It's great to see that EDSAC will be rebuilt! I wonder if Maurice Wilkes, the project leader, was told before he passed away just this last November? He was probably the last of the "first generation" computer pioneers to pass away. Several slashdot stories of his passing were submitted, but I don't think it ever made the main page. At least he can get his props here now.
I remember having trouble using the old Sun workstation keyboards. The Control and Caps Lock keys are in switched positions. I suppose that makes some sense on a UNIX system, but it was hard getting used to. Maybe Google should just move Caps Lock somewhere else?
Didn't this hack merely put the console into development/debug mode? I haven't heard of anyone using the USB hack to so something more "low-level" like restoring the OtherOS feature or allow RSX access in Linux (after all, this USB hack should probably work for those who opted not to update to keep OtherOS). A Sony-created development environment sandbox is far different than a complete hypervisor hack.
Granted, I suppose it may be too early to assess what is really exposed by the USB hack.
It's crazy that an architecture developed in the '60s lives on in the System Z today. IBM bet the company on the S/360 product line. I think the investment has paid off-- and still does!
Ugh. I just updated on my Mac running 10.6.4. It looks like Adobe is still distributing Reader 9.3.0 as the default distribution package. I had to download/install this version and then apply individual patches for 9.3.1, 9.3.2, and finally 9.3.3. Annoying.
Perhaps it would have been easier had I updated from within Reader?
Perhaps I misinterpreted the original COTS post. I took the intent to mean that the USAF would develop "games" to run on a cluster of stock PS3s (like folding@home), not a cluster of dev kits. My point was that the stock PS3 OS might not have all the features necessary to operate in an MPI-based cluster. I suppose your "game" might be able to provide this environment, but that could get quite expensive.
As for building a cluster of dev kits, it is not price competitive against IBM's QS22. I believe a QS22 blade is (was?) somewhere around $8-10k a piece (excluding chassis costs). However, the blade has TWO higher-end Cell processors with all 8 SPUs functional in each and the blade can be configured with up to 32GB of memory (compare that to the PS3s 256MB). I'm not sure how many SPUs are functional on the dev kit. Still, it has only a single lower-end Cell, right?
Thus, the only price competitive solution for a dev kit is to use it to develop software for a cluster of stock PS3s. Which again, might not be able to do all the things it must in an MPI-based cluster.
Slashdot Mirror
Kind of makes me wonder why slashdot almost never links the REAL articles and instead just links some fancy news sites with second hand information.
Maybe because of the paywall?
The thief will have to sell the goods on the black walnut market.
Normally, I would agree, but I must disagree in this case. The vast majority of people in the U.S. are science-illiterate and easily swayed by sensational headlines (For example, last week slashdot posted a story on how the background radiation in Fukushima is less than that of Denver, yet people panic over radiation exposure in Japan, but not Colorado.). I worry that a similar backlash against GM crops could negatively affect the world's food supply.
While we can disparage crops that have been crafted to withstand copious amounts of insecticide, please keep in mind that there are 7 billion people on the planet, and all of them need to be fed. Much of the world depends upon the United States' agricultural output. GM helps boost this output. While the American consumer can withstand a few cents increase in cost due to decreased food supply, the same increase can trigger food riots in less fortunate countries. If the United States' agricultural output is enhanced by GM, then I'm all for it. I worry that shunning GM food in the US could hurt further investment/development.
Yes, and the rover could have sent "I'm on a boat!" for its first message home.
Jim.
CUDA was released, supported by NVIDIA GPUs, in early 2007. The first OpenCL specification was not released until late 2008 (OpenCL has not been around for 4 years, as you claim). As for which is more popular, I'm afraid that you have this backwards too. The dominant market force for GPU computing is supercomputing. How many of the top 5 supercomputers used AMD GPUs? Zero. How many use NVIDIA GPUs? Three. And they're all using CUDA because it's more feature rich---it can do fancy things like direct memory copies between infiniband interconnects and GPU memory.
FYI: OpenCL on NVIDIA is implemented on top of CUDA, so you're still using CUDA if you're using OpenCL on NVIDIA.
Surprise, surprise, I have the feeling that most of you haven't actually read the article. The article is not arguing that GPUs are inherently flawed. Also, the article is not an NVIDIA-vs-AMD competition. Rather, the author tests software on each platform. It's the software that is bad, not the GPUs themselves. For instance, the NVIDIA GPU does quite well with Arcsoft and Xilisoft; this wouldn't be possible if GPUs were somehow broken for transcoding. After all, as others have pointed out here, floating point support is actually quite good on modern GPUs.
Still, poor software shouldn't come too much as a surprise. While CUDA and OpenCL certainly make GPU-based computing easier, it is still a relatively new technology that only a few programmers know how to use efficiently. I'm also not sure that the market pressure is there yet from consumers for efficient GPU-based applications (how many of them actually know what a GPU is?).
I suppose this is an improvement over a design from another Dutch firm for residential towers in South Korea: http://www.dailymail.co.uk/news/article-2072308/MVRDV-architects-reveal-plans-South-Korean-buildings-look-eerily-like-Twin-Towers-exploding.html
SLI is absolutely useless for CUDA-based (Cray's uses NVIDIA GPUS) GPGPU.
Well, Apple, it looks like you'll be the last major OS still running a terribly out of date file system. Ditch HFS+!
I think the time of the PS3 clusters has past. The Cell processor was released back in 2006! IBM released a few upgraded processors, mostly improving double-precision performance, but those systems are really cost prohibitive.
Assuming you can deal with PCIe latency, GPUs are the way to go.
What does SLI give you in CUDA? The newer GeForce cards support direct GPU-to-GPU memory copies, assuming they are on the same PCIe bus (NUMA systems might have multiple PCIe buses).
My research group built this 12-core/8-GPU system last year for about $10k: http://tinyurl.com/7ecqjfj
The system has a theoretical peak ~9.1 TFLOPS, single precision (simultaneously maxing out all CPUs and GPUs). I wish the GPUs had more individual memory (~1.25GB each), but we would have quickly broken our budget had we gone for Tesla-grade cards.
If you are already going to be in New Mexico to see the Very Large Array, try to swing by the Carlsbad Caverns: http://www.nps.gov/cave/index.htm
Sure, it's not tech-oriented, but I'm sure you can get your geology geeking on. It's not often one is in the area (BFE New Mexico), so take the opportunity. The caverns are not to be missed!
Interesting projects, but how do they get funding?
Thought: Would you rather own the spider or a spyder?
Let's make this a record level of comments for a Slashdot story.
Goodbye, Steve. It was with a Mac that I came to love computers.
It took a custom CPU to knock out the Tianhe (GPU-based) supercomputer. Did IBM plan to use an existing POWER chip, or were they trying to develop a new Cell-like (or other boutique) processor? IBM keeps saying that the future of Cell isn't dead. I wonder if NCSA thought they'd get more bang for their buck with a GPU-based solution?
The reports currently are that the train cars detailed because of a collision, not because they were simply going too fast and took a sharp turn on faulty rails. Can you really expect cars to remain on the tracks after a collision?
You might be forgetting that the Cell was released in 2006. The multi-core CPUs from Intel today are only just now starting to reach the peak theoretical performance than the Cell. Also, your Radeon was released when? 2009? Given Moore's law (which is still in effect for parallel architectures like Cell and GPUs), the factor by which your Radeon beats the Cell isn't too bad. Also note that the compute performance of an I/O device like a GPU can be limited by the I/O bus; both in terms of bandwidth and latency. GPUs used for computing typically perform best on large chunk, long running, computations. I believe that the Cell could possibly still trounce a modern GPU for smaller, less-memory intensive, jobs since it has access to main memory and is scheduled directly by the operating system (there's no GPU driver middle-man). This will change soon of course with on-chip integrated CPU/GPU solutions. However, it took nearly 5 years after Cell's release to get to that point.
So don't rag too much on Cell. It's very old, if not ancient, by microprocessor standards.
It's great to see that EDSAC will be rebuilt! I wonder if Maurice Wilkes, the project leader, was told before he passed away just this last November? He was probably the last of the "first generation" computer pioneers to pass away. Several slashdot stories of his passing were submitted, but I don't think it ever made the main page. At least he can get his props here now.
I remember having trouble using the old Sun workstation keyboards. The Control and Caps Lock keys are in switched positions. I suppose that makes some sense on a UNIX system, but it was hard getting used to. Maybe Google should just move Caps Lock somewhere else?
Didn't this hack merely put the console into development/debug mode? I haven't heard of anyone using the USB hack to so something more "low-level" like restoring the OtherOS feature or allow RSX access in Linux (after all, this USB hack should probably work for those who opted not to update to keep OtherOS). A Sony-created development environment sandbox is far different than a complete hypervisor hack.
Granted, I suppose it may be too early to assess what is really exposed by the USB hack.
It's crazy that an architecture developed in the '60s lives on in the System Z today. IBM bet the company on the S/360 product line. I think the investment has paid off-- and still does!
Ugh. I just updated on my Mac running 10.6.4. It looks like Adobe is still distributing Reader 9.3.0 as the default distribution package. I had to download/install this version and then apply individual patches for 9.3.1, 9.3.2, and finally 9.3.3. Annoying.
Perhaps it would have been easier had I updated from within Reader?
If the aim is to simply multiply brain cells, there are plenty of other ways to do that too: just do anything that can give you brain cancer.
Perhaps I misinterpreted the original COTS post. I took the intent to mean that the USAF would develop "games" to run on a cluster of stock PS3s (like folding@home), not a cluster of dev kits. My point was that the stock PS3 OS might not have all the features necessary to operate in an MPI-based cluster. I suppose your "game" might be able to provide this environment, but that could get quite expensive.
As for building a cluster of dev kits, it is not price competitive against IBM's QS22. I believe a QS22 blade is (was?) somewhere around $8-10k a piece (excluding chassis costs). However, the blade has TWO higher-end Cell processors with all 8 SPUs functional in each and the blade can be configured with up to 32GB of memory (compare that to the PS3s 256MB). I'm not sure how many SPUs are functional on the dev kit. Still, it has only a single lower-end Cell, right?
Thus, the only price competitive solution for a dev kit is to use it to develop software for a cluster of stock PS3s. Which again, might not be able to do all the things it must in an MPI-based cluster.