Forgot your password?
typodupeerror
AMD

AMD Unveils SSE5 Instruction Set 85

Posted by CowboyNeal
from the new-and-improved dept.
mestlick writes "Today AMD unveiled its 128-Bit SSE5 Instruction Set. The big news is that it includes 3 operand instructions such as floating point and integer fused multiply add and permute. AMD posted a press release and a PDF describing the new instructions."
This discussion has been archived. No new comments can be posted.

AMD Unveils SSE5 Instruction Set

Comments Filter:
  • Who cares... (Score:1, Insightful)

    by aquaepulse (990849) on Friday August 31, 2007 @01:20AM (#20421049)
    in 2009 I'll be holding out for SSE8 anyway.
  • by Harik (4023) <Harik@chaos.ao.net> on Friday August 31, 2007 @01:39AM (#20421153)
    So, where's the analysis by people who write optimized media encoders/decoders? How useful are these new instructions, or are they just toys? How well did they handle context switching? What's the CX overhead? Is there a penalty for all processes, or only when you are switching to/from a SSE5 process? Will this be safely usable under all operating systems, or will they need a patch?
  • by WoTG (610710) on Friday August 31, 2007 @02:44AM (#20421533) Homepage Journal
    I'm not really qualified to make an opinion on this, but my guess is that these instructions will prove increasingly useful as AMD integrates the GPU and CPU. To me, it looks like they plan to make accessing what was traditionally part of the GPU a simple process (relative to accessing a GPU directly through their own pseudo CPU api's).

    It'll take a couple years for "SSE5" to show up in AMD chips... which happens to coincide nicely with their Fusion (combined CPU+GPU) product line plans.

    Will Intel pick up on these instructions? Maybe not. Does that mean they die? No, the performance benefits for those areas where this will make the most difference will make it worthwhile. At the very least, AMD can sponsor patches to the most popular bits of OSS to earn a few PR points (and benchmark points).
  • by aquaepulse (990849) on Friday August 31, 2007 @03:24AM (#20421707)

    And assuming that a floating-point number is represented by 128 bits, that still means there are only 2^128 (that is, 17,179,869,184) discrete values it can represent.
    Sadly that's wrong. 17,179,869,184 = 2^34. I mean, is it that difficult for people writing articles to check their math.
  • by MrNaz (730548) on Friday August 31, 2007 @03:59AM (#20421861) Homepage
    Great! I'm glad those two organizations have such a long and distinguished history of self-restraint when it comes to the borders of their mandated spheres of operation.
  • by renoX (11677) on Friday August 31, 2007 @05:45AM (#20422349)
    For 'serious' scientific computing, they use 64b FP number, having vectors of 4 element seems the right size, so SIMD computations of 4*64=256 seems the 'right size' for these users.

    Sure multimedia & games use lower precision FP computations so 16b or 32b FP number is enough, but it's strange that AMD doesn't try to improve the usage for the scientific computation niche.

    Maybe it's because the change would be expensive as to be efficient, the width of the memory bus should be expanded to 256b from 128b now.

Help me, I'm a prisoner in a Fortune cookie file!

Working...