Today this is different.
A properly pipelined CPU can do an Integer ADD per cycle.
A properly pipelined CPU can also do a FLoating point FADD per cycle.
A properly pipelined CPU can do a Integer MUL per cycle.
A properly pipelined CPU can also do a Floating point FMUL per cycle.
 
That Integer is faster than Float is not a fact anymore. ;-)

This sounds very reasonable to me (i.e. double only in FPU and float for SIMD).
 

Amiga Believer wrote:

> 16bit float is very very imprecise.   > Therefore I would not implement it.   I disagree. Half precision floating point (IEEE754 binary16) is obviously not precise enough for scientific calculations. It is however quite enough for many everyday tasks, such as MPEG

I agree with Amiga Believer. 16 bit float is very common nowadays for vector processors. I would also add complex multiplication support (at least for 16 bit), this will speed up a lot of signal processing tasks (FFT, complex filters, ...); for 16 bit is it not very expensive; if it is too much for one cycle, you can pipeline the execution phase so the latency gets up but at least the initiation time is still 1.

For float16 it would be nice, to support 2 precissions, the IEEE half (if I remember right one sign bit, 5 for the exponent and one hidden plus 10 stored bits for the mantissa) and maybe another format with more exponent and less mantissa bits, possibly switchable during runtime by setting a config bit in some register?

Things like sqrt or log can be implemented very fast for float16.

Amiga Believer wrote:

> 1) Convert InT to Float,   > 2) Do SQRT   > 3) Convert Float to Int   It may be useful to have, like I said, a square root instruction for integers.     > Do you talk about FLOAT or Integer?   Well... both...   I was thinking of adding it for signed integers and floating point.     > In 3D games you always need to rotate Vectors with a Matrix.   I was thinking of creating a SIMD unit with the goal of accelerating compression and decompression of video, audio and images, not to accelerate games. For games, I have another solution which I will bring in another forum topic.     @Loïc Dupuy     > Ok, SIMD can do 4 operation in //   > But what are the real case that benefit from this ?   > Outside this, all other instruction will be a waste, and it will be very difficult to justify the gates/power ration gives by the SIMD.   See the example which I gave about MPEG in this message. When working with macroblocks, a SIMD unit can give a boost for the DCT or the IDCT calculation.

Exactly. And for MPEG and speech recognition etc. there should be some support for sum of absolute differences (L1 norm), of course the latency can be a bit longer as long as initiation is 1.

Also useful: more intra vector instructions like find min/max
(best implementation would search for both with the same instruction), also loopable over several vectors for integer normalization (and of course min/max for SIMD float); abs for simd float is very simple by setting the sign bit to 0; abs for simd integer would be helpful;

and of course a nice intra vector permutation unit etc. :-)

...

Of course I meant complex mul for 16 bit floating point.

Any chance we get 256 bit registers?

> That Integer is faster than Float is not a fact anymore. ;-)
This just means that in theory it is possible to make a FPU which is as fast as an integer unit. It does not mean that all processors now have such a unit (Pentium 4 class CPUs do floating point much slower than integer) or even that we shall have such a powerful floating point on our SIMD unit, the design of said unit hasn't started yet. This would however hold true to our case if the floating point of our SIMD is performant, so the final answer is: it depends.

> Any chance we get 256 bit registers?
This seems unlikely to me, moreover, unless the unit is massively extended, instructions would take twice the clock cycles. I do think that 128 bit is fine.

@ Denis Markovic
> the IEEE half (if I remember right one sign bit, 5 for the exponent and one hidden plus 10 stored bits for the mantissa)
You remember right, the IEEE754 half precision floating point format (binary16) is as you described.

> For float16 it would be nice, to support 2 precissions, the IEEE half [precision floating point format] [...] and maybe another format with more exponent and less mantissa bits, possibly switchable during runtime by setting a config bit in some register?
I am not against another 16 bit floating point format, however I cannot think of a example of a case where the IEEE754 binary16 would be unsuitable (it is certainly suitable for compression or decompression of MPEG, JPEG, audio) and a format with more bits for the exponent would be suitable. Can you please provide such an example? Having IEEE754 binary16 has the advantage that it is a standard (this does not mean that non-standard options are bad).

> I would also add complex multiplication support (at least for 16 bit), this will speed up a lot of signal processing tasks (FFT, complex filters, ...); for 16 bit is it not very expensive
> Things like sqrt or log can be implemented very fast for float16.
>  And for MPEG and speech recognition etc. there should be some support for sum of absolute differences (L1 norm)
> Also useful: more intra vector instructions like find min/max
(best implementation would search for both with the same instruction), also loopable over several vectors for integer normalization (and of course min/max for SIMD float); abs for simd float is very simple by setting the sign bit to 0; abs for simd integer would be helpful;
> and of course a nice intra vector permutation unit etc.
You seem to be very knowledgeable for the following task: implementing signal processing on a SIMD unit.
Why don't you make a proposal as to the instruction set for the SIMD unit? You seem to be the right person to design the SIMD instruction set.

Gunnar pipelining hides the problem. ;)
But your right on the big picture.
Besides i am no fan of counting picoseconds.
I might be a nit picker but even i have my limits. ;)

Right on the big picture but not in general, integer is still faster than float, at least in the rare cases when your calculation has a lot of dependencies and you just want 1 value as output of a long chain of calculations; I really like counting cycles :)

Yes, you are probably right. If you have 128 bit register, you
should be able to fetch at least 128 data bits from memory/chache in one cycle in parallel to another operation (add/mac/cmac on another register) or you might starve your core.

The only advantage I see with 256 bit registers is, that you could implement instructions slower in a first run but for some future implementation with 256 bit speedup you would already have all the programs for it in place, i.e. programs would run faster automatically without a change (I guess, the pipeline will not be exposed, otherwise you might get problems with this?).

Amiga Believer wrote:

@ Denis Markovic     > For float16 it would be nice, to support 2 precissions, the IEEE half [precision floating point format] [...] and maybe another format with more exponent and less mantissa bits, possibly switchable during runtime by setting a config bit in some register?   I am not against another 16 bit floating point format, however I cannot think of a example of a case where the IEEE754 binary16 would be unsuitable (it is certainly suitable for compression or decompression of MPEG, JPEG, audio) and a format with more bits for the exponent would be suitable. Can you please provide such an example? Having IEEE754 binary16 has the advantage that it is a standard (this does not mean that non-standard options are bad).

Hm, maybe matrix inversions? But of course you could say that if you need more exponent bits, you could just use 32 bit float; I guess most use cases would be for high performance low power architectures in mobile phones, so maybe not so important for natami ... one advantage with having less mantissa bits is that
you could implement functions like 1 cycle sqrt, ... very very cheap and simple in hardware.

Anyhow, at least I would try to get rid of not a number stuff
etc. in 16 bit mode and use saturation instead, much more useful
for signal processing if you have that small amount of bits
(maybe at least settable via config bit or encoded in the opcode); nan can get really ugly for recursive algorithms.

  Why don't you make a proposal as to the instruction set for the SIMD unit? You seem to be the right person to design the SIMD instruction set.