Slashdot Mirror
Gitbrew Releases OtherOS++ PS3 Linux Dual Boot
An anonymous reader writes "Gitbrew has proudly released otherOS++ Linux Dual Boot v1.0b1, enabling PS3 users to install an alternative OS to their console with full access to all system hardware, including all 8 CELL cores (making the PS3 the world's most affordable supercomputer). For more information check out the installation instructions and source code."
George Hotz widely distributed information on how to install another operating system onto the PS3 to run illegal versions of PS3 games and software.
Libel much?
Look at the comments on the same piece of news, but from a site that's predominantly made up of PS3 fans...
http://n4g.com/news/756574/hackers-bring-back-otheros-for-ps3/com
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
The PS3 suddenly became an interesting product again :-) Now lets give us some benchmarks of some scientific number crunching apps!
Not to me. Sony is at war with its customers; that's been evident since XCP. Hell, I felt dirty buying a broken Sony stereo for ten bucks, even though Sony didn't profit from my purchase.
How do you know the PS3s don't have hardware rootkits? I know of no other company that's deliberately installed malware on its products. I avoid Sony like the plague and can't understand why anyone would buy anything from them, or how it's has stayed in business, let alone how it can actually have fanbois.
Free Martian Whores!
Look at it this way... at least you can use your PS3 while waiting for your PSN account to be reactivated ^_^
"We know what happens to people who stay in the middle of the road. They get run over." - Aneurin Bevan
Sounds right. Until you think again. There was a second rootkit with the microvault thumb drive and they were another division as well. (Why do people keep forgetting this one?) Then the subpoenas of people who visited a web site, or watched a video, which was still yet another division. Sony sees the customer as the enemy. I do not want to do business with my enemy.
Apparently, Geoff Levand was one of the people behind this release [1]. Geoff Levand is the programmer who worked for Sony supporting OtherOS and made the ill-fated and oft-quoted promise that Sony would never ever remove OtherOS from fat PS3s. [2] Looks like Geoff just kicked his former employer in the nuts. Go Geoff!
[1] http://psgroove.com/content.php?1029-PS3-Dual-Boot-GameOS-Linux-CFW-Released
[2] http://lists.ozlabs.org/pipermail/cbe-oss-dev/2010-February/007202.html
The best they claim is 25.6 GFLOPS per cell in theoretical performance, so 205 GFLOPS is the best you theoretically get, if there are no bandwidth constraints (which there are on a PS3) for single precision math. Ok well testing my actual Radeon 5870, I get 800 GFLOPS for single precision, 227 for double precision. That is an actual benchmark of the card running on my desktop.
As somebody who programmed Cell CPUs for signal processing (including to, but not limited to PS3s), let me tell you that the PS3's memory bandwidth is so close to unlimited, that you usually don't have to think about it. At least as long as you move data only on the Element Interconnect Bus, between the 256KB local SRAMs of each CELL core, which is sufficient for most of what I did. It moves up to 200 giga bytes per second, maximum 16 bytes per 2 cycles in and out per core. The DMA engines that do those transfer have their own 1024bit (!) read/write port into the SRAM, so they burst 128 bytes per cycle into the SRAM, and don't have to steel many RAM cycles. The wikidedia article has more details.
In my experience, you can usually come pretty close to the 200 GFLOP/s of the Cell-CPU. When relying on C-Compiler with SIMD intrinsics, you usually manage 100 GPFOP/s for algorithms that have as many read/write opcodes as arithmetic opcodes. Smaller problems can mostly be handled on registers only (per CPU we have 128 16-byte registers!) and will run even faster.
Also note that many algorithms nowadays are not bandwidth but memory latency limited. Having the Cell's per-core DMA engines do background transfers to large local S-RAMs, mostly eliminates these latency problems and is much cleaner than relying on CPU caches guessing what parts of RAM to prefetch next. BTW these are user-space DMA engines that undergo page translation and are fully compatible to unix vm concepts. Still programming directly accesses DMA registers and doesn't need any kernel calls.
Try to do that with your GPU!