1

I am looking for a simple idea for a program that is able to saturate a CPU with calculations. For now, the only idea i have is to use a prime number generator, as the number of digits in a prime number increases, the difficulty in generating one increases exponentially. Is there any other type of algorithm that can do the same?

Subhaac
  • 111
  • 1
  • 2
  • 13
  • 2
    I don't think the calculation itself really matters, does it? You could loop over a massive string and make a modified copy of it. To really eat the CPU though, you should spawn a ton of Threads that all do this to plug all the processing units. Out of curiosity why do you need this? – Carcigenicate Oct 30 '16 at 12:01
  • 1
    Do you need to use a lot of electrical power / make heat? Or do you just need to use CPU time? If the latter, any simple loop with a repeat count from 1M to 1000M is good, depending on how long you want it to run. Does it matter how hyperthreading-friendly your loop is? (Or any other kind of SMT on CPU microarchitectures other than Intel's.) – Peter Cordes Oct 30 '16 at 12:20

1 Answers1

0

  • You shouldn't care about the Type of operation your CPU is doing, as long as it is a CPU Operation.

    std::atomic<bool> flag_exit;
    int a = 1;
    int b = 1;
    while(!flag_exit)
    b = a + b;
    }
    cout << b; // using 'b' just to make sure it isn't optimized away.

  • You might want to consider spreading your work on all your cores
    Though you can try relay on super-scalar out-of-order execution(thanks Peter Cordes) to split Unrelated instructions across, i'd recommend create a separate thread per core.

Tomer W
  • 3,395
  • 2
  • 29
  • 44
  • unless `flag_exit` is a `std::atomic` or something (or a `volatile`, which will work in this case but not in general as a substitute for an atomic type), most compilers will optimize that to `if(!flag_exit){ while(true){} }`, because they'll do the load once and keep the value in a register. Yup, that's exactly what happens with gcc6.2 ([on Godbolt](https://godbolt.org/g/c0x8PG)) – Peter Cordes Oct 30 '16 at 12:25
  • It of course works with -O0 (in which case you don't need the `cout`, or if you use `std::atomic flag_exit`: https://godbolt.org/g/IG9mKa – Peter Cordes Oct 30 '16 at 12:30
  • "relay on Hyper threading to split Unrelated instructions across". That's the opposite of what HT does. It lets multiple threads use the same core, to better keep with work to do. Gain in overall throughput at the expense of single-thread performance. Normal superscalar out-of-order execution is what takes advantage of instruction-level parallelism in the instruction stream. – Peter Cordes Oct 30 '16 at 12:32
  • @PeterCordes , for HT: My terminology is off :( 2nd thing, given `while(flag_exit)` is set from a different thread, still `flag_exit` had to be `volatile/atomic`? – Tomer W Oct 30 '16 at 12:42
  • yes, that's one of the major reasons for the existence of std::atomic. The fact that data-races on non-atomic variables are UB in C++ allows the compiler to assume that globals are not asynchronously modified, and hoist the load out of the loop. You can see it does exactly that in the first asm I linked, but not in the 2nd where I used `atomic`. The same thing applies if it's set from a signal handler within the same thread, of course. – Peter Cordes Oct 30 '16 at 12:44
  • re: your update: no, there's nothing that lets a single thread automatically take advantage of multiple cores. Superscalar OOO runs unrelated instructions in parallel inside a single core (up to its pipeline width or number of execution units). See some of the performance / microarchitecture links in the [x86 tag wiki](http://stackoverflow.com/tags/x86/info). – Peter Cordes Oct 30 '16 at 12:58
  • For more about std::atomic being required for the compiler to assume async modification: [see comments about `sig_atomic_t`](http://stackoverflow.com/questions/9606725/linux-why-is-sig-atomic-t-typedefed-to-int#comment66158213_9607790), and maybe also some of my answer on [Can num++ be atomic for 'int num'?](http://stackoverflow.com/questions/39393850/can-num-be-atomic-for-int-num) (although that's more about the atomicity of a read-modify-write than the assumption of async modification, and way different from a single load or store being atomic.) – Peter Cordes Oct 30 '16 at 13:06