1
$\begingroup$

I am new to computer science, so excuse me if the question is inappropriate or sounds absurd to you.

In the textbook, it says that a typical laptop can execute 1 billion instructions per second. Therefore, I thought that if I wrote a never-ending piece of algorithm, it would generate tons lines in the program counsel after running it for 10 seconds. Taking into account the time it needs to convert to machine instructions, and the fact that other programs needed to be executed as well, the number I expected was some where about one million of instructions per second and thus 10 millions per 10 second.

I tried to run something like this:

        While 1+1=2:
               Print(0)

To my surprise, I found that the print instruction had been executed for less than 4,000 times within 10 seconds. I know that my original estimation was not meant to be accurate but I was not expecting the speed to be this slow. I think maybe the read-writing speed of my ssd was the major drawback. I know that sending instruction to the screen is even slower, but that should not affect the CPU's performance.

So, here are my questions:

  1. What are the major factors that slow down the speed?

  2. Are there any other factors that I overlook?

  3. Is there a way to know exactly or make reasonably accurate estimation of the Python code execution rate?

  4. And are there any suggestions to speed up the execution rate?

  5. Even if it takes time to send instructions to the monitor, the processor can still utilize the gap in between to execute other instructions. So, does that exclude slow I/O speed as a drawback?

  6. If the hidden layer between me and the machine already figures out what to do in the beginning, is it going to repeat the same instruction without executing extra instructions?

  7. It is possible to have the processor focus on a piece program without executing any other program at all?

Thank you for your help in advance.

$\endgroup$
  • 1
    $\begingroup$ Your text is very hard to read. Please spend more effort on formatting it. $\endgroup$ – Yuval Filmus Mar 19 '17 at 21:45
  • $\begingroup$ print(0) takes a lot more instructions than you think $\endgroup$ – user253751 Mar 20 '17 at 2:58
2
$\begingroup$

There are a number of reasons for this.

  • Other processes were probably running at the same time.
  • Printing to the console takes many, many instructions per print, especially when the console starts to scroll.
  • You may have been using an interpreted language. In this case, the computer must figure out what each line of your program means before running it. Some interpreters figure this out again every time they come to a line, even if they've run it before. Again, this takes many, many instructions per line.
$\endgroup$
2
$\begingroup$

You are misinterpreting "instruction". Check out for example http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf or https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf (a bit outdated) to find what is meant by "instruction".

Print (0) is not an instruction. It is a statement in an interpreted language. The processor will probably execute thousands of instructions to interpret the statement. And the Print statement will eventually start scrolling the screen, which consists of a million pixel or more, which are moved up smoothly, pixel by pixel, which may take millions of instructions.

$\endgroup$
1
$\begingroup$

Most likely, printing was the slowest bit. In fact, whenever your program issued a print instruction to the operating system, it is likely that the operating system did something that made your program wait for the print to be completed. In addition, it is unlikely that the operating system performed the print immediately. Instead it took the opportunity to do other things. Input/output is slow.

What you should do is run your program again and observe how much CPU it is actually using. On my computer it uses about 77% of CPU in Python and 55% in OCaml compiled to native code. That is, the program is waiting for the operating system to perform the print on the console.

A much better way to test speed of CPU is to write a program which will make only the CPU busy. That would be a small loop which computes something (and don't use any arrays of memory). But you should make sure to compute something that the compiler cannot just optimize. Good compilers know about arithmetic and gemetric series, and lots of other things.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.