Any FP double precision abilities in CELL?

[Guden Oden]

Is it only single precision as in PS2, or can it actually do 64-bit calculations too this time 'round?

I started thinking about it since I saw on Ars Technica a cryptography nut had been cracked using the equivalence of 1200 years' worth of computing time of an Athlon 3200 CPU. The writer mentioned it would take much longer to solve the next larger problem using today's CPUs, and then I thought... 'Hmmm... Broadband Engine...' Alright Deadmeat, don't get your f****g panties in a wad or anything, I'm being serious so don't reply in this thread thank you.

So, unless it has double precision maths, it wouldn't be terribly useful for scientific work. Ok, so it can be emulated, but it would be awkward in comparison to if it was just implemented natively, and it would waste a lot of performance too.

So again... What's the deal here?

(Of course I'm completely ignoring the pretty much rock-solid fact PS3 will be a closed platform and no client released for it with which to compute distributed science problems, so nobody need to comment on this either.)

 

[Megadrive1988]

IBM might have a "professional" variant of Cell built for the purpose of double precision FP ops. Since Cell is ment to be a consumer electronics family of processors, I kinda doubt the main versions will feature double precision FP.

 

[ERP]

At this point it's just guess work, but I would not expect double spport on the PU's of Cell.

I'm also not really convinced that Cell would be good design for general purpose scientific problems. Unless the problem can be expressed in a stream (or data packet) friendly manner, I think you'll end up spending more time moving data around than actually doing work on it.

 

[Paul]

BE will not have a double precision FP.

 

[akira888]

Well, back to the topic...

I doubt it will matter whether or not the BE will have 64 bit FP as far as encryption processing goes. The reason for this is that in general encryption algorithms need to perserve data in a lossless fashion, something which FP of course inherently cannot do. Consider the RSA algorithm (this is the only crypto algorithm I've ever personally implemented so take this with a grain of salt), the only operations needed are the integer forms of +,-,*, /, and %.

Besides, encrypting data to send over a network isn't going to be something that is going to take up much CPU time at all.

 

[Fafalada]

I doubt it will matter whether or not the BE will have 64 bit FP as far as encryption processing goes. The reason for this is that in general encryption algorithms need to perserve data in a lossless fashion, something which FP of course inherently cannot do.

True, but who is to say APUs will not support higher bit integer arithmetics. R59k already had native 64 and partial 128bit
That would also be much more reasonable to expect then higher bit FP - as it actually has uses in the target applications for PS3.

 

[archie4oz]

I doubt it will matter whether or not the BE will have 64 bit FP as far as encryption processing goes. The reason for this is that in general encryption algorithms need to perserve data in a lossless fashion, something which FP of course inherently cannot do. Consider the RSA algorithm (this is the only crypto algorithm I've ever personally implemented so take this with a grain of salt), the only operations needed are the integer forms of +,-,*, /, and %.

And lots of shifts, and rotates...

 

[Panajev2001a]

I think that the FPU attached to each PU will be able to do Double Precision Floating Point ( doubles ) as well as Single Precision Floating Point ( floats ) math: the RISC core's FPU in the EE did both SP and DP Floating Point math after-all.

 

[Panajev2001a]

I doubt it will matter whether or not the BE will have 64 bit FP as far as encryption processing goes. The reason for this is that in general encryption algorithms need to perserve data in a lossless fashion, something which FP of course inherently cannot do. Consider the RSA algorithm (this is the only crypto algorithm I've ever personally implemented so take this with a grain of salt), the only operations needed are the integer forms of +,-,*, /, and %.

And lots of shifts, and rotates...

Like dancing...

"...and this move I called it the barrel shifter..."

or


it could be an areobica class

"rotate left, then left then right... now shift right, shift right and now left... come on burn that fat"


WHOWZAaaa .


Sorry... just configured VS.NET to work with PS2Linux over a Network.

 

[David_South#1]

It is my impression that the APU of cell are in fact 64bit based.
I believe that they are single precision only.

One question,
Is it possible for a 64bit single precision processor to perform 32bit double precision?

 

[akira888]

Archie:

Doh, forgot about rotates. But bitwise operations are indifferent in fixed point or floating point data representation.

David South:

Typically the nomenclature holds that "single precision" is 32 bit (1s-23m-8e) precision while "double precision" is 64 bit (1s-52m-11e). Yes, higher precision FPU's can perform operations on lower precision data by up-converting the data precision on memory->register load. For example the x86 FPU actually has a native precision of FP80.

Vis-a-vis the BE APU precision note that the write port from the FPU to the register bank is 128 bits wide. Given that it operates on 4-vectors each component seems to be 32 bit.

 

[Fafalada]

the RISC core's FPU in the EE did both SP and DP Floating Point math after-all.

Nope it didn't. Single precision only.

Is it possible for a 64bit single precision processor to perform 32bit double precision?

Precision is defined as number of bits used for floating point number. DP FP number is defined as 64bit. Different number of bits, different precision.

And the bitness of processor itself is normally defined completely separate from their FPU coprocessors - eg. Pentiums are 32bit cpus with 80bit FPU precision.

 

[Panajev2001a]

the RISC core's FPU in the EE did both SP and DP Floating Point math after-all.

Nope it didn't. Single precision only.

Is it possible for a 64bit single precision processor to perform 32bit double precision?

Precision is defined as number of bits used for floating point number. DP FP number is defined as 64bit. Different number of bits, different precision.

And the bitness of processor itself is normally defined completely separate from their FPU coprocessors - eg. Pentiums are 32bit cpus with 80bit FPU precision.

Sorry, I thought it did process also Double Precision Floating-Point math, but I will take your word since I do trust you.

 

[Fafalada]

You don't have to take my word for it, you have the hardware docs, look it up for yourself

 

[MrWibble]

You don't have to take my word for it, you have the hardware docs, look it up for yourself

Or alternatively, make the mistake of leaving double-precision operations in your code (rather easy to do when it's actually the default in C) and watch your performance plummet through the floor as very slow software routines replace any FPU instructions...

You can spot 'em a mile off on the PA...

 

[David_South#1]

Vis-a-vis the BE APU precision note that the write port from the FPU to the register bank is 128 bits wide. Given that it operates on 4-vectors each component seems to be 32 bit.

It's been ages since I've made a hard effort to revise my cell info...

But I made drawing back then of APU, BE, Elements etc.
And I noted something that was peculiar. I thought I had double-checked it too.

The write port from the FPU is 128bit per FPU.
This struck me as strange too. Because to because my initial impression was 384 to each group of FPU (floating point unit) and FXU (Fixed point). And 128 back from each. Totaling this I got the 1024bit thing. I felt this was somehow fitting. But when I read the granted patent I could have sworn it said to each FPU. So I changed my drawing to say Each. This was a long time ago. And I am an amateur.

Plus I’m aware that the design of the EE is 256 (128x2) to VU0 and 128 back and recognize the similarities between EE, APU design, and what you’ve shared.

I guess I’ll take the time to look up the granted Sony patent and proof read this old impression. I’ll probably have to change it. ;P As that would be 8,192 bits of write port just between the Units, Registers, and Local NORMA Memory.

To the Point.
The reason for all this jibber jabber is your conclusion. I have it on record that Cell is definitely a 64bit processor. I assumed that the APU were also. However if what you've said is correct (I assume it is, because why would a 64bit Unit have a 128bit answer? )
Does that mean the PU is 64bit and the APU are 32bit?
Is such a thing possible and has it been done before?

 

[archie4oz]

Doh, forgot about rotates. But bitwise operations are indifferent in fixed point or floating point data representation.

Well I was speaking for crypto in general...

Or alternatively, make the mistake of leaving double-precision operations in your code (rather easy to do when it's actually the default in C) and watch your performance plummet through the floor as very slow software routines replace any FPU instructions...

Hehe, been there, done that, got the T-shirt (and cursed the compiler).

Nope it didn't. Single precision only.

...and it's not IEEE compliant either...

 

[Fafalada]

You can spot 'em a mile off on the PA...

You don't even need PA to spot those a mile off

Does that mean the PU is 64bit and the APU are 32bit?

In terms of FPU, I have no doubt APUs will be 4x32bit. However, I wouldn't be surprised if they support wider integer arithmetic - with 128bit GPRs it seems a waste to limit yourself only to 32bit ints.

Is such a thing possible and has it been done before?

Not sure why you'd think it'd be difficult or impossible, but EE pretty much has that exact setup. R59k (64bit) , VU (32/16bit).

...and it's not IEEE compliant either...

Bah you're just jealous your IEEE compliant units are one exponent bit short

 

[David_South#1]

Does that mean the PU is 64bit and the APU are 32bit?

In terms of FPU, I have no doubt APUs will be 4x32bit. However, I wouldn't be surprised if they support wider integer arithmetic - with 128bit GPRs it seems a waste to limit yourself only to 32bit ints.

Is such a thing possible and has it been done before?

Not sure why you'd think it'd be difficult or impossible, but EE pretty much has that exact setup. R59k (64bit) , VU (32/16bit).

Thank you for the replies. But what are GPR's?
(Google = Ground Penetrating Radar)
Graphic Processing Registers perhaps? To me that would seem like a perfectly sized register for Quad-Word data/instructions.

I know that the EE partially supports 64bit mips extensions.
But how well it supports 64bit processing is unknown to me.

 

[nobie]

General Purpose Register.