4 ms·

Here is more information from official site [1,4,5]: - native "Elbrus" ISA or x86 ISA, - Ebrus ISA is VLIW, can dispatch 23 operations per cycle (33 with SIMD

• agumonkey 11y ago
  How many processors have hardware support for loops ? I expect it to be a different, more efficient infrastructure than Comparison/Jump, maybe something similar to DisplayLists in old OpenGL ?
  • spatular 11y ago
    Well, full translation would be "hardware support for loops, including pipelining". How exactly is pipelining implemented is not clear.
  • Zardoz84 11y ago
    x86 LOOP
    • revelation 11y ago
      Or just REP.
      • ddingus 11y ago
        Which CPU is this for?
        • Sanddancer 11y ago
          x86/x64 -- http://web.itu.edu.tr/kesgin/mul06/intel/instr/rep.html http://web.itu.edu.tr/kesgin/mul06/intel/instr/rep.html
          • ddingus 11y ago
            Thanks!
    • kazinator 11y ago
      DBcc instructions in Motorola 68000.
  • rzzzt 11y ago
    Intel's Itanium line had the following hardware support for loops: * Register rotation [1]: referenced registers inside the loop are cycled on each iteration * Branch prediction [2]: with a dedicated loop count register, the CPU can tell with complete certainty when not to take the jump to the beginning (no mispredictions at the exit) [1] http://www.cs.nmsu.edu/~rvinyard/itanium/register_rotation.htm http://www.cs.nmsu.edu/~rvinyard/itanium/register_rotation.h... [2] http://www.cs.nmsu.edu/~rvinyard/itanium/branching.htm http://www.cs.nmsu.edu/~rvinyard/itanium/branching.htm
    • petjuh 11y ago
      Branch prediction is already extremely efficient for loops, it simply assumes the last comparison will be the same. For loops this is true for all but the first and last iteration.
      • SamReidHughes 11y ago
        Even if it's perfect it still takes up branch prediction overhead in the processor, and hurts the performance of other branches. Also, getting the first or last iteration wrong is pretty bad for a ton of for loops out there.
  • jevinskie 11y ago
    Qualcomm Hexagon DSPs have "instruction packets" that have hardware loop support. http://en.wikipedia.org/wiki/Qualcomm_Hexagon#Code_sample http://en.wikipedia.org/wiki/Qualcomm_Hexagon#Code_sample
• userbinator 11y ago
  The most interesting thing about the benchmarks is that they show some pretty amazing IPC. The P6-based Pentium M was known for its high IPC, but this 500MHz Elbrus core is more than 50% of the speed of a 1GHz Pentium M. The floating-point results are even better, although perhaps not surprising due to having 4 FP ALUs. Another set of benchmarks containing an Elbrus is at http://www.7-cpu.com/ http://www.7-cpu.com/ and also shows extremely good IPC efficency - it achieves 1.2 MIPS/MHz/core for compression, which is better than all the other non-x86 in that list, and somewhere between Haswell's 1.18 and Ivy Bridge's 1.24. If they could scale this up to a newer process, they'd probably be equal to if not surpassing Intel's current x86 performance.
  • microarchitect 11y ago
    How good is the compiler? To paraphrase David Patterson, its easy to get really great IPC for code from a shitty compiler, but that doesn't mean your program will run faster.
  • Everlag 11y ago
    Being limited to in-order execution, won't the overall IPC be limited by Amdahl's law as a result of issues such as pipeline stalls? Out-of-order will take as much space and power as you can throw at it but there's a reason we aren't using 'speed demon' processors for general computation.
  • spatular 11y ago
    It's quite possible that in SPEC benchmarks they used 2 Elbrus cores and 1 Pentium M core, so IPCs are about the same. And it's confirmed by 7zip benchmark. In theory Elbrus can dispatch 23 non-SIMD ops per cycle, it has only 6 integer units and 4 among them can do FP, so it's not clear what remaining 17 operations can do. Modern x86 CPUs have about the same number of integer/FP ALUs. Current IPC is quite good, but it's hard to tell if core clock can be increased without lowering IPC. If ALU pipelines are short, it may be difficult to increase frequency without adding more stages. If more stages are added then pipeline flushes due to unpredicted jumps will result in heavier penalty. And it looks like Elbrus doesn't have a branch predictor at all. Pipeline stalls caused by memory access will also increase with CPU frequency. In x86 CPUs they are somewhat masked by out-of-order execution and SMT, which Elbrus doesn't have, so it should depend on memory preload instructions inserted by compiler.