6 ms·

Meanwhile this renders MMX and SSE sort of redundant. It's an evolution of the same SIMD ideas. Yes, the newer variants do render the older variants redundant,

Meanwhile this renders MMX and SSE sort of redundant. It's an evolution of the same SIMD ideas. Yes, the newer variants do render the older variants redundant, but hang around because code might use it. MMX - SIMD, integer only, reused existing floating point registers making it a PITA that often didn't even payoff because of the expensive state switching between MMX and floating point. SSE - starting as floating point SIMD with its own 128-bit registers. Evolved through SSE 4.2 with more instructions (functionality in hardware), flexibility (e.g. operate on 4 singles or 2 doubles or...) and the addition of integer functionality. AVX - Double the size of the vector registers, adding more of them and lots of new instructions and functionality. The successor of SSE, at least on the floating point side. AVX2 brought the integer functionality. AVX-512 - Double the size of the vector registers again. 16 single float operations in one go. Maybe this is another area where ARM can beat x86. Have a better planned out vector instruction set that can be expanded without adding hundreds of new instructions all the time, and more compact machine code. This kind of sounds like baseless griping. Unless you write a compiler, why do you care? Do you really sweat the instruction prefixes?

ChuckMcM 13y ago
I wish that Intel would have spent some transistors on an arbitrary precision decimal arithmetic floating point unit. That would have helped scientific processing but in the past has been 'too expensive' in terms of transistors to implement. Now that we have more transistors than we know what to do with, seems like that should be revisited. Then generalize the vector coproccessing abilities of the GPU and that would be a pretty flexible base to work from.
- wmf 13y ago
  Try Power7/8; IBM loves decimal math.
- jey 13y ago
  Why does scientific computing care about decimal arithmetic?
  - ChuckMcM 13y ago
    Same reason accountants do, numbers like .1 aren't approximate repeating fractions in decimal representation.
    - acqq 13y ago
      Citation needed, please. I don't know where nature is decimal.
      - ChuckMcM 13y ago
        Actually its more fun if you just "do the math" and its a fun computer science problem: 0.1 is 1 / 10, fractional binary bits are 1/2, 1/4, 1/8, 1/16 ... find a combination of bits that represents 0.1. If you want a very long treatise about how binary sucks for doing arithmetic wander over to http://speleotrove.com/decimal/ http://speleotrove.com/decimal/
        jey 13y ago
        Right, and I can see why that's a problem in accounting, but why does it matter for scientific computing? I do a fair amount of stuff that could be called scientific computing, and I just use doubles. If I need to keep track of uncertainty or propagate errors, I normally use Gaussians as the representation (not "significant figures" as would be implied by using decimal).
        drewcrawford 13y ago
        I'm sorry, are you asking for what purpose a scientist would need to multiply by a power of ten? Converting between units in scientific notation? Doing base 10 logarithms? Calculating things in decibels? Maybe I have misunderstood the question.
        jey 13y ago
        The original post that started this thread was saying that chips should support decimal floating point natively in silicon instead of only base-2 floating point. Yes, those are different things: https://en.wikipedia.org/wiki/IEEE754#Basic_formats https://en.wikipedia.org/wiki/IEEE754#Basic_formats
Symmetry 13y ago
Well, all those instruction prefixes mean that decoding x86 instructions is really hard. That leads to more cycles to decode, for a larger branch mis-predict penalty. And your decode unit takes as much power as your integer cluster (which is still small potatoes compared to all the OoO resources). And you're limited to 1 decoded instruction per cycle when executing instructions brought into cache for the first time, before the processor can tag the boundaries (but again, most instructions are executed many times).
- CamperBob2 13y ago
  If the instruction cache still contains raw, undecoded x86 instructions, I'd be amazed. That seems like the lowest of low-hanging fruit.
  - Symmetry 13y ago
    Well, sort of. For the actual 32 KB instruction cache they just tag the instructions in the cache at the instruction boundaries. The Pentium IV tried holding decoded instructions (or traces, rather) in the instruction cache, but it didn't work out very well. The complications induced by lining up the different instruction sizes with the previously specified jump targets and the fact that decoded instructions are much bigger made that approach less successful. Intel Sandy Bridge and later processors do keep a sort of L0 instruction cache full of decoded instructions with all the annotations needed to sort out branching. It can hold 1.5 K uOps, which is certainly something but not so big that you won't be missing it regularly.
    - nkurz 13y ago
      > And you're limited to 1 decoded instruction per cycle > when executing instructions brought into cache for the > first time I don't think that's true for any recent processors. For Sandy Bridge, you can get a throughput of 4 instructions decoded per cycle as long as they average 4 bytes or less in length and are well aligned. The exact details are a bit messy given the different layers, but you can mark up to 6 instructions or 16B per cycle, and you can put 4 into the queue each cycle (or 5 if the is fusion): http://www.realworldtech.com/sandy-bridge/3/ http://www.realworldtech.com/sandy-bridge/3/ > It can hold 1.5 K uOps, which is certainly something but > not so big that you won't be missing it regularly. You'll be missing it frequently, but it's big enough that it should hold almost any tight loop. Intel is claiming it's equivalent to a 6KB instruction buffer, and has about an 80% hit rate.

ChuckMcM 13y ago

I wish that Intel would have spent some transistors on an arbitrary precision decimal arithmetic floating point unit. That would have helped scientific processing but in the past has been 'too expensive' in terms of transistors to implement. Now that we have more transistors than we know what to do with, seems like that should be revisited. Then generalize the vector coproccessing abilities of the GPU and that would be a pretty flexible base to work from.

wmf 13y ago
Try Power7/8; IBM loves decimal math.
jey 13y ago
Why does scientific computing care about decimal arithmetic?
- ChuckMcM 13y ago
  Same reason accountants do, numbers like .1 aren't approximate repeating fractions in decimal representation.
  - acqq 13y ago
    Citation needed, please. I don't know where nature is decimal.
    - ChuckMcM 13y ago
      Actually its more fun if you just "do the math" and its a fun computer science problem: 0.1 is 1 / 10, fractional binary bits are 1/2, 1/4, 1/8, 1/16 ... find a combination of bits that represents 0.1. If you want a very long treatise about how binary sucks for doing arithmetic wander over to http://speleotrove.com/decimal/ http://speleotrove.com/decimal/
      - jey 13y ago
        Right, and I can see why that's a problem in accounting, but why does it matter for scientific computing? I do a fair amount of stuff that could be called scientific computing, and I just use doubles. If I need to keep track of uncertainty or propagate errors, I normally use Gaussians as the representation (not "significant figures" as would be implied by using decimal).
        drewcrawford 13y ago
        I'm sorry, are you asking for what purpose a scientist would need to multiply by a power of ten? Converting between units in scientific notation? Doing base 10 logarithms? Calculating things in decibels? Maybe I have misunderstood the question.
        jey 13y ago
        The original post that started this thread was saying that chips should support decimal floating point natively in silicon instead of only base-2 floating point. Yes, those are different things: https://en.wikipedia.org/wiki/IEEE754#Basic_formats https://en.wikipedia.org/wiki/IEEE754#Basic_formats

Symmetry 13y ago

Well, all those instruction prefixes mean that decoding x86 instructions is really hard. That leads to more cycles to decode, for a larger branch mis-predict penalty. And your decode unit takes as much power as your integer cluster (which is still small potatoes compared to all the OoO resources). And you're limited to 1 decoded instruction per cycle when executing instructions brought into cache for the first time, before the processor can tag the boundaries (but again, most instructions are executed many times).

CamperBob2 13y ago
If the instruction cache still contains raw, undecoded x86 instructions, I'd be amazed. That seems like the lowest of low-hanging fruit.
- Symmetry 13y ago
  Well, sort of. For the actual 32 KB instruction cache they just tag the instructions in the cache at the instruction boundaries. The Pentium IV tried holding decoded instructions (or traces, rather) in the instruction cache, but it didn't work out very well. The complications induced by lining up the different instruction sizes with the previously specified jump targets and the fact that decoded instructions are much bigger made that approach less successful. Intel Sandy Bridge and later processors do keep a sort of L0 instruction cache full of decoded instructions with all the annotations needed to sort out branching. It can hold 1.5 K uOps, which is certainly something but not so big that you won't be missing it regularly.
  - nkurz 13y ago
    > And you're limited to 1 decoded instruction per cycle > when executing instructions brought into cache for the > first time I don't think that's true for any recent processors. For Sandy Bridge, you can get a throughput of 4 instructions decoded per cycle as long as they average 4 bytes or less in length and are well aligned. The exact details are a bit messy given the different layers, but you can mark up to 6 instructions or 16B per cycle, and you can put 4 into the queue each cycle (or 5 if the is fusion): http://www.realworldtech.com/sandy-bridge/3/ http://www.realworldtech.com/sandy-bridge/3/ > It can hold 1.5 K uOps, which is certainly something but > not so big that you won't be missing it regularly. You'll be missing it frequently, but it's big enough that it should hold almost any tight loop. Intel is claiming it's equivalent to a 6KB instruction buffer, and has about an 80% hit rate.