Minimal code CPU stress-tester…

  • Introduction



    There are lots of utilities out there capable of creating a high CPU load to stress-test your processor(s). On Microsoft Windows, you can even use the on-board calculator.exe, enter a large number like 999999999, and press n! several times to make your CPU(s) work overtime.



    But what’s in a solution if you didn’t create it yourself?



    The mission



    Your mission – if you choose to accept it – is to create the smallest CPU stress-test tool on the planet.



    Must…




    1. must produce 100% CPU load until aborted

    2. must take a numeric input, representing the number seconds the stress-test should run

    3. must allow user interaction (keypress, closing terminal window, or something like that) which should enable a user to abort the stress-test and/or quit the program

    4. must target Microsoft Windows, Mac OSx, and/or Linux.

      (Even a hamster could stress a Comodore64… therefore, you must target a current operating system.)



    Must not…




    1. must not use 3rd-party programs or tools which replace expected functionality.

      (Proposing shortcuts in the likes of system('cpuStressThing.exe') disqualifies your proposal.)



    May…




    1. may use any approach/algorithm/functionality to produce expected 100% CPU load

    2. may use any programming or scripting language

      (as long as it allows practical verification of its functionality by running it)



    Winning Condition



    Present the smallest sourcecode possible. The winner is the one presenting the most minimal (in size) sourcecode that complies to the above “must” and “must not” conditions. Now, make that baby burn…






    EDIT



    Since the question came up in the comment area… you only need to target 1 CPU core. I'm definitely not expecting you to produce a multi-core solution. After all, this should be fun – not work.


    Is "100% of one core" enough, or do you mean "100% of a multi-core CPU"?

    @Tobia Yep, 1 core is enough. I've edited my question to specifically include that information. Thanks for pointing me to the fact that that wasn't all too clear.

    do cryptocurrency miners count/

    @TheDoctor If you can make it fit the conditions I described… be my guest. It would surely be interesting to see a cryptocurrency miner that is able to beat (for example) a 36 byte bash script in filesize.

    The problem is that most miners are several thousand lines of code.

    @TheDoctor **I know** – that's why I said it would surely be interesting to see you pull it off. ;)

    Given the popularity of `yes`, it would be nice to clarify whether the program is allowed to produce output.

    @NateEldredge Just like it says: `may use any approach/algorithm/functionality to produce expected 100% CPU load` – so if you decide that producing output will do the job of producing a high CPU load, you are free to do that…

  • Bash and standard utilities, 36 31 22 29 28 26 bytes


    yes :|sh&sleep $1;kill $!

    That looks pretty gorgeous for a Bash code! That's really a nice answer!

    You don't need the `:` in `do :; done`. I've found `do;done` does the job - that'll pull you in 2 bytes. Also +1 for being nearly half the length of my bash solution (I made it overly complicated for no good reason as I forgot about `$!`).

    @ChrisJ - that doesn't work for me: `bash: syntax error near unexpected token \`;'`. I've tried these bash versions: `3.00.15(1)-release (x86_64-redhat-linux-gnu)`, `3.2.48(1)-release (x86_64-apple-darwin12)`, `4.2.25(1)-release (x86_64-pc-linux-gnu)`

    Ah - my mistake, sorry. ksh allows that syntax, bash/sh doesn't (having jsut tested).

    @ChrisJ - I guess you have yourself a 34-byte `ksh` answer then ;-)

    I'd put `$1` in place of `10` there, just to make it into a script that "takes numeric input".

    Also `/d*/n*` works just as well on my Linux box, as there's only one file with that pattern—/dev/null

    @Tobia - I have `/dev/net /dev/network_latency /dev/network_throughput /dev/null`. I guess `/d*/nu*` would do it. Not sure if its worth introducing fragility for the sake of 2 bytes. Of course it is - its code-golf!

    I like that you suppress the output of `yes`. I thought of a shorter way: `yes :|sh&`

    @NateEldredge - very good - thanks!

    @e-sushi - yes I guess there is some inefficiency of utilization when writing all those chars to the terminal window. I've removed that part of the answer.

    +1 for emoticon... `:|`

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM

Tags used