Toshiba Cell demo @ CEATEC JAPAN 2005

Titanio said:
I doubt this relates to the PS3 dev kit at all. Last I heard Sony wasn't including any IBM IDE, or stuff like Eclipse, with the PS3 kit.

That's a pity. I suppose depending on what happens with the Cell workstations it still could be interesting, but I was really hoping that perhaps Sony was starting to embrace more openness. :(

Nite_Hawk
 
Apparently software layers are all independently developed by 3 parties save for things produced in Cell chip development such as ICE for Cell. Toshiba's comprehensive platform includes 'Beat' hypervisor, Lv2Linux, ITRON, realtime resource scheduler, and GUI dev tools such as Eclipse, all for embedded consumer/professional products software developers.
 
What version of CELL is in the Toshiba Reference Set?

DD2 2.4GHz 6SPE?

DD2 3.2GHz 7SPE?

DD2 4.0GHz 8SPE?

If it’s the same as the one in PS3 and they bundle a HD Eyetoy in with the PS3 this could get even more interesting.
 
really cool software... Toshiba will probably only deliver this software on a HD-DVD just the sakes of it.. ;)
 
Really cool demo! :oops:

hey69 said:
is that a watercooling pump and block on the cell procesor?
Yeah, that is my guess too. That would explain the fairly open case (water cooling unit on the bottom).

One of these days, in 10 years, I am going to buy a CELL server like that just to have one :D
 
avaya said:
What version of CELL is in the Toshiba Reference Set?

DD2 2.4GHz 6SPE?

DD2 3.2GHz 7SPE?

DD2 4.0GHz 8SPE?

If it’s the same as the one in PS3 and they bundle a HD Eyetoy in with the PS3 this could get even more interesting.

Very likely the DD2 2.4GHz Cells... don't know how many working SPEs, but I would assume 6 or 7.
 
Interesting that nobody bothered to comment on the performance analyzer screenshot so far... :) Looking at the diagram there, it seems the SPUs spend a fair amount of time idling, either because of efficiency issues with the hardware design or early programming efforts leading to poor performance.

Or perhaps the processor's simply so damn fast it burns through its calculations too quickly and becomes starved for input data. ;) Take yer pick...
 
Guden Oden said:
Interesting that nobody bothered to comment on the performance analyzer screenshot so far... :) Looking at the diagram there, it seems the SPUs spend a fair amount of time idling, either because of efficiency issues with the hardware design or early programming efforts leading to poor performance.

Or perhaps the processor's simply so damn fast it burns through its calculations too quickly and becomes starved for input data. ;) Take yer pick...
Hard to feed any CPU 100% all the time.

I had looked at it, but I am not an expert. What *I* drew from it was this: Looks like the SPEs are a lot more useful than the EE VU1/VU0, specifically the underused one ;)

I think utilization on the SPEs will come down to programming model, what type of code you are trying to run on it, and of course how good your code is. In the Multi-core thread I started a little over a month ago it seemed that with so many cores and more of a "dispatch" model you may use them as you need them. So sometimes they will be idle, and sometimes you will be cranking on them.

Which is not surprising considering even a modern game with physics, like HL2, is only being "pushed" when there are things in the game pushing it. So if your *game code* gets 60fps & 100% utilization when you have 100 active physics objects, when those 100 physics objects are no longer active you may be at 40% utlization.

So by design you wont be cranking on the SPEs all the time in most games (I am sure there will be exceptions!).

I look forward to seeing the neat techniques developers come up with to make the use of the design.
 
Acert93 said:
Hard to feed any CPU 100% all the time.

I had looked at it, but I am not an expert. What *I* drew from it was this: Looks like the SPEs are a lot more useful than the EE VU1/VU0, specifically the underused one ;)

I think utilization on the SPEs will come down to programming model, what type of code you are trying to run on it, and of course how good your code is. In the Multi-core thread I started a little over a month ago it seemed that with so many cores and more of a "dispatch" model you may use them as you need them. So sometimes they will be idle, and sometimes you will be cranking on them.

Which is not surprising considering even a modern game with physics, like HL2, is only being "pushed" when there are things in the game pushing it. So if your *game code* gets 60fps & 100% utilization when you have 100 active physics objects, when those 100 physics objects are no longer active you may be at 40% utlization.

So by design you wont be cranking on the SPEs all the time in most games (I am sure there will be exceptions!).

I look forward to seeing the neat techniques developers come up with to make the use of the design.

And off this I wonder if gaming devs are noticing things like this. I wonder if the more developers like Toshiba and the like do, if gaming devs are going to try to find a way to incorporate that same thing into their game? Can you imagne a game putting you in the game and you can actually see yourself move in real-time?:oops:

Damn gotta love the future.
 
mckmas8808 said:
And off this I wonder if gaming devs are noticing things like this. I wonder if the more developers like Toshiba and the like do, if gaming devs are going to try to find a way to incorporate that same thing into their game? Can you imagne a game putting you in the game and you can actually see yourself move in real-time?:oops:

Damn gotta love the future.

It would certainly be awesome for games with create-a-player modes, like wrestling games or the Tony Hawk series. And if the image data isn't too big, it could be awesome for multiplayer games (UT2K7?).
 
Off-topic for this thread, kind of, but I never know if I should be creating threads about general Cell stuff in the Console forum or what ;)

Mercury Systems has announced their first Cell product - a dual-blade Cell system (400Gflops) as well as multi-blade solutions at 2.8Tflops and 16Tflops (the much vaunted 16Tflop server! ;)). Will be available Q1/Q2 next year:

http://www.mc.com/cell/press2.cfm

Mercury Computer Systems Announces the First Cell BE Processor-Based Product for Industrial, Medical, and Military Markets
Initial Orders Expected for Early-Access System

CHELMSFORD, Mass., Oct. 6 /PRNewswire-FirstCall/ -- Mercury Computer Systems, Inc. (NASDAQ: MRCY) announced the Dual Cell-Based Blade, Mercury's first product based on the IBM(R) Cell BE (Broadband Engine) processor. As announced in June 2005, Mercury is partnering with IBM Engineering & Technology Services to integrate Cell technology into a range of products designed to address computationally intensive applications in aerospace and defense, seismic, semiconductor test, and medical imaging, as well as other markets. Availability of the Dual Cell-Based Blade is planned for Q1 of calendar 2006, and production is planned for the following quarter.

The Dual Cell-Based Blade, based on IBM's industry-leading BladeCenter(R) design, will offer unprecedented peak performance of 400 GFLOPS and feature two IBM Cell BE processors, as well as XDR(TM) memory from Rambus Inc. An online data sheet is available at www.mc.com/cell.

Detailed specifications of this product have been shared under NDA with various customers, and initial orders for early-access systems are anticipated in the near-term.

In keeping with Mercury's strategy to leverage open standards where available, the Dual Cell-Based Blade software environment will run on the Linux(R) OS, and Mercury will provide the Eclipse-based open source software framework necessary to harness the tremendous processing power of the Cell processor architecture -- integrating the compilers, debuggers, math libraries, utilities and middleware in a seamless fashion.

Utilizing the open standards that IBM delivered through its development and offering of the BladeCenter ecosystem, the Dual Cell-Based Blade will be available in the IBM BladeCenter platform, which integrates server, storage, and networking functionality to provide upward scalability and performance density for computing needs in a variety of applications. Scalable to seven blades in a 7U configuration, the Dual Cell-Based Blade is expected to provide up to 2.8 teraFLOPS of processing performance in a 7U form factor, and up to 16 teraFLOPS in a six-foot rack.

"We are delighted to get this product to market so quickly, and the Engineering & Technology Services unit at IBM has been instrumental in making this happen," said Randy Dean, vice president, Business and Technology Development at Mercury. "A number of customers are eager to have access to this breakthrough blade solution. Some of these customers plan to place the Dual Cell-Based Blade into production immediately, while others will leverage the system as an application development platform."

"Through exceptional teamwork, Mercury and IBM are bringing innovative, advanced new products to customers. These solutions have the ability to transform not only business processes, but entire industries," said Raj Desai, vice president, Engineering & Technology Services, IBM. "The strength of the combined portfolio and skills allows this partnership to tackle and solve customers' most pressing computing problems with breakthrough solutions. Mercury's passion for enabling customer success mirrors that of the IBM team."

A render:

Cell-blade.jpg


And here's the datasheet:

http://www.mc.com/products/view/index.cfm?id=64&type=boards

Specifications

Dual Cell BE Processors
PPE core: IBM® 64-bit PowerArchitecture™
L1 cache size: 32 KB instruction; 32 KB data
L2 cache size: 512 KB
SPUs: 8
Local memory size: 256 KB
Registers: 128 x 128 bits wide
EIB: 192 GB/s aggregate bandwidth
Processor internal clock speed: 3 GHz
Processor-to-memory bandwidth: 24.0 GB/s
Processor-to-processor coherent interface: 20 GB/s in each direction

Memory
Memory (each processor): 512 MB XDR DRAM, 2 channels each
ECC support: Single-bit correct; double-bit detect
Flash: 8 MB
NVRAM: 1 MB

Hard Disk
Hard disk controller: Integrated IDE busmaster
Number of hard disks (max): 1

IO Subsystems
Serial ports: 2

Expansion Options
Daughtercard: 2 optional InfiniBand cards

System Management
System management processor: H8 environmental monitor

Software
Linux® with BE-SPU extensions
SAL Scientific Algorithm Library: Available
PASâ„¢ Parallel Execution System: Available
TATLâ„¢ Trace Analysis Tool and Library: Available

Size
Length: 429.9 mm (16.925 in)
Width: 245.3 mm (9.657 in)
Height: 58 mm (2.283 in)
The board is a double-width Dual Cell-Based Blade in a 7U chassis

Environmental
Ambient temperature: 0°C to 35°C
Humidity: 5% to 95% non-condensing
Altitude: -400 m below MSL to +3000 m above MSL
Noise level: 45 dB from 1 m at 35°C

Power
Dual Cell-Based Blade total power: Conforms to open BladeCenter requirements

Compliance
Keyboard/displayless operation : FCC Class A
European Directive 2002/95/EC: (RoHS Directive)
Safety: UL 60950-1 and IEC 60950-1
EMC: EN 55022, EN 61000, EN 55024:1998

edit - there's a PDF here: http://www.mc.com/literature/literature_files/Cell_blade-ds.pdf. For what it's worth, they claim "95% utilisation" for XDR.
 
Last edited by a moderator:
Titanio said:
Mercury Systems has announced their first Cell product - a dual-blade Cell system (400Gflops) as well as multi-blade solutions at 2.8Tflops and 16Tflops (the much vaunted 16Tflop server! ;))
Must be with many zeroes in the price tag :cool:

Another small Cell news, the security lab at Stanford will have a public seminar on Cell security.

http://crypto.stanford.edu/seclab/sem.html
http://crypto.stanford.edu/seclab/sem-05-06/shimizu.html

Tuesday 10/25/2005 at 4:30pm.
Kanna Shimizu, SonyToshibaIBM Design Center
Cell Broadband Engine Security Architecture


With the rapidly growing demand for stronger security, it is becoming increasingly clear that software alone cannot meet this need. Therefore, hardware, which is intrinsically less vulnerable to holes, manipulation, and attacks, must be re-thought and re-architected to support the security of the system. Cell Broadband Engine (Cell BE) is a general-purpose microprocessor designed from scratch with this goal in mind. Its key strength is that it does not solely rely on the integrity of the operating system or the hypervisor for security. It is designed such that even if the operating system or the hypervisor is compromised, applications and data remain secure. This is in marked contrast with many other security architectures where once the operating system is compromised, all bets and guarantees are off.

The multi-core design of the Cell BE is leveraged to accomplish this strong protection. One class of processor cores on the Cell chip can be put into isolation mode whereby it is physically isolated from the rest of the system. When in this mode, the core's 256K of private local memory, where it holds its code and data, cannot even be accessed by root or the operating system. Therefore, a hacker who has root access, gains nothing in its attempt to observe, control, or copy the protected program and data.

The Cell BE will be the central processor for Sony Computer Entertainment's next-generation game console, the Playstation III. This game console is expected to be in about 100 million households in a few years, and thus, it can be safely assumed that the security architecture described in this talk will be pervasive and exploited by many commerce-driven consumer applications.
 
One's posted Quote said:
The multi-core design of the Cell BE is leveraged to accomplish this strong protection. One class of processor cores on the Cell chip can be put into isolation mode whereby it is physically isolated from the rest of the system. When in this mode, the core's 256K of private local memory, where it holds its code and data, cannot even be accessed by root or the operating system. Therefore, a hacker who has root access, gains nothing in its attempt to observe, control, or copy the protected program and data.

Wow. Thats a pretty cool way to implement Security on a hardware level. I wonder how it works though? If the system detects its being compromised it isolates that core? (seems to be the most obvious thing to do). Seems like Linux is really being emphasized for Cell (or vice versa). A could way to impliment that type of security is to isolate one of the Cells cores when being compromised and having it only be unlocked with Finger Print or Optical scanning (wouldn't work for remote users though).

One step closer to self aware CPUs! or not :LOL: would be freaky though if the system locked up on its own....the CELL=SKYNET comparison looms in the background :oops:
 
Last edited by a moderator:
Where can I see those Cell make up videos? The links go to page that has tons of different links in japanese, none of them seem to be about "Cell" at least from the pics.
 
BlueTsunami said:
One step closer to self aware CPUs! or not :LOL: would be freaky though if the system locked up on its own....the CELL=SKYNET comparison looms in the background :oops:

you *know* Dave has to do a cell review now.

"I'm sorry Dave, I'm afraid I can't do that."

Nite_Hawk
 
Thanks.

That demonstration was more impressive than I thought, I really hope the PS3 will have something like that on day one.
That would draw a lot of non gamers interest too.
 
Though this is a Cell demo, do we have anything to compare it to on non-Cell systems? In other words, what is it about Cell that makes it able to do this and how much is it having to do?

Not that either other console will probably be able to match this if possible on PS3 as they don't appear to be getting the needed optical devices. But to rate performance it'd be nice to have a comparison. For all I know a Athlon 1800 can do this, just no-one had invented the algorithms until now!
 
Good to see that the CELL is getting good use already. CELL is already better for Non Playstation stuff than EE was during it's whole lifespan. Good to have IBM on board.:D
 
Back
Top