PureBasic Forums - English

I guess it is kind of an odd question.. But I was hoping somebody with an engineering background or who just knows a bit might be able to explain this one to me.
I never understood why programs on a computer have to run, specifically, in a looped fashion; even when presenting "static" data on the screen that doesn't change..

Especially when CPU performance is rated in instructions per second / clock cycle / whatever (can anyone explain the terminology there?)
i.e just displaying a blank window, every clock cycle the program is looping, repeatedly sending the command to create a window and display it - right? That is the impression I get, but maybe it is wrong..

But lets assume this is true for the sake of the discussion. If you do not loop your code, the program "ends" and the window disappears... But why does it disappear? Who is telling the CPU/OS/whoever to erase the window?

What trips me up is why this (if correct) method of programming does not have performance decreases on an exponential scale, especially if every "refresh" of the main loop you are starting from scratch again??

Arghh, I don't know.. it just boggled my mind how it all actually works.

The only reasonable explanation I came come up with, is that the CPU is a one-off horse race. It is designed to do as much as possible in one "run" of the clock cycle, and then the race is started over again....??

I don't know why I had to ask this, it just popped into my head.

A main processing loop was probably invented by every other "bare metal" programmer long before there was a Window to close. In embedded electronics you have to Load code and then turn it loose. If it stopped, you used to have to load it again and that was be a lot more trouble than it is now... especially on a spacecraft.

Zach wrote:I never understood why programs on a computer have to run, specifically, in a looped fashion; even when presenting "static" data on the screen that doesn't change..

One answer: That's the fundamental way that processors work. As long as they are powered on and running, they just keep performing instructions and moving onto the next one, jumping to different sections of code when told to (such as if conditions in your code). CPUs (at least general-purpose ones) don't have any concept of a loop -- loops are just sections of code that happen to repeatedly point the CPU back to the same instructions.

Another answer: There are plenty of languages in which you DON'T write program loops, but instead you write event handlers and callbacks and whatnot. However these are high-level languages, who are ultimately interpreted by the operating system which is actually running "looped" code on the hardware CPU.

If you are interested, pick up a cheap used textbook on computer architecture or maybe computer science. I've taken a few classes on the low-level hardware/software of processors, and they can be sort of brilliant and surprisingly simple in some ways.

But lets assume this is true for the sake of the discussion. If you do not loop your code, the program "ends" and the window disappears... But why does it disappear? Who is telling the CPU/OS/whoever to erase the window?

This is managed by the operating system, CPUs know nothing about windows or when different programs start and stop (unless maybe the OS assigns them to different CPU threads). For example, 32-bit Windows executables have their own format and headers, and probably end-of-program indicators too. (I wish I knew more about OS's actually.) If your executable doesn't loop somehow, eventually you hit an end and the OS kills it.

What trips me up is why this (if correct) method of programming does not have performance decreases on an exponential scale, especially if every "refresh" of the main loop you are starting from scratch again??

The only reasonable explanation I came come up with, is that the CPU is a one-off horse race. It is designed to do as much as possible in one "run" of the clock cycle, and then the race is started over again....??

Not sure what you mean by "starting from scratch" or "starting over"... your program is always in some state (like a giant Finite State Machine with millions of bits of memory), that continually checks the values of inputs, performs some actions, and updates outputs. Also one "game" cycle may be thousands (millions?) of "clock" cycles. For example, one frame of a PC game typically: checks for keyboard and mouse inputs, moves/updates all the game objects as appropriate, redraws the screen and plays sounds, etc.

The performance of a CPU should never decrease just because it's running for a long time... ignoring OS-level problems like memory leaks, or CPU features like dynamic branch prediction. If your CPU gets worse, you have one poorly designed piece of hardware

Zach wrote:I guess it is kind of an odd question.. But I was hoping somebody with an engineering background or who just knows a bit might be able to explain this one to me.
I never understood why programs on a computer have to run, specifically, in a looped fashion; even when presenting "static" data on the screen that doesn't change..

The reason for looping is simple, you don't want your program to end yet. As kenmo pointed out the loops could also be considered 'unrolled' and just considered a very long list of sequential instructions by the computer. In other words, the CPU is going to be executing something, why not then execute your loop? What would you want it to do if it wasn't executing your program. If it did nothing, how would it know when to 'stop doing nothing' and execute the next program?

The only reasonable explanation I came come up with, is that the CPU is a one-off horse race. It is designed to do as much as possible in one "run" of the clock cycle, and then the race is started over again....??

Yes, but the race is simply to execute a single instruction of multiple stages of instructions via a pipeline setup.

Especially when CPU performance is rated in instructions per second / clock cycle / whatever (can anyone explain the terminology there?)
i.e just displaying a blank window, every clock cycle the program is looping, repeatedly sending the command to create a window and display it - right? That is the impression I get, but maybe it is wrong..

But lets assume this is true for the sake of the discussion. If you do not loop your code, the program "ends" and the window disappears... But why does it disappear? Who is telling the CPU/OS/whoever to erase the window?

What trips me up is why this (if correct) method of programming does not have performance decreases on an exponential scale, especially if every "refresh" of the main loop you are starting from scratch again??

The simplest loop is the CPU retrieving the next instruction and executing it, then advancing it's instruction pointer to the next instruction. Looking at the hardware level for a moment, the values stored in DRAM have to be refreshed (by being read then rewritten) or they will lose their values in just a few milliseconds because they are capacitors. This requires the CPU or memory controller to repeat this process for all DRAM in the computer a few thousand times a seconds (even when it only contains zeroes). That is what is involved in just the upkeep of memory, and not the processing of any other instructions. A similar process of refreshing is required for CRT and active matrix LCD displays (even when they are showing a blank image).

On a higher level loops come in several varieties. One is where a variety of conditions are checked or polled. In another, interrupts are generated and then handled as they show up. In this loop example, the interrupts will be assumed to come from hardware and the 'loop' does nothing if no interrupts have occurred yet. The last type of loop is one in which a task is broken into parts and during each pass through the loop only one portion of the task is completed before saving the results before moving on to the next portion (this is similar to multi-tasking).

Most loops are some combination of all these approaches. For instance in PB you would loop waiting for interactions with the GUI that produce events (similar to software interrupts) that are the result of hardware interrupts (mouse, keyboard) while displaying a progress screen of a thread that is downloading a file (multi-tasking).

These loops can be improved or engineered so that they use time more efficiently. Switching from a large number of polling operations (i.e. is light switch A, B, C, D, E, F, ..., Z, on?) to an interrupt style (i.e. the light switch G is on) is a useful trick. I believe this would be a good description of how window event messages are handled, though there is some minimal checking involved to determine if there is an event to act on.

The other improvement is simply to break tasks into portion sizes that can be mult-tasked easier. This can occur with threads, or between your program and others running in a multi-tasking environment.

To apply these approaches to the 'static blank string' you mentioned earlier the screen should only be redrawn if it is overdrawn and needs to be refreshed or another task takes over and displays something else instead.

I kind of understand what you guys are saying..

I do understand the interrupt / event concepts and how they work.

I guess it just boggles my mind for whatever reason.

Like the whole concept of not updating the screen unless something new is drawn, I get that too. Let's say there are 10 buttons on the screen, and in order to render those 10 buttons it takes a certain amount of CPU power. If the screen is just sitting there, with no updates to draw, is the computer not still drawing and redrawing those 10 buttons, over and over and over? (Otherwise the program would end there would be nothing to show)

I think that is the heart of why I think it feels rather "inefficient".. Seems like a waste of CPU power to render something that isn't changing. I suppose a different system, that was more event-based at the lower hardware level would require radical redesigns of current CPU's though.

But I wonder if anyone has every experimented with that.

Does anyone understand what I am getting at?

You have overlapped windows (from other applications), the must redrawn. You can handle this message by your
program or irgnore and windows will do this for you, but this requires a working event-loop!

Sorry TS, but that is a puzzling and vague response, given the generality of the subject we are discussing

This is entirely my own opinion rather than anything factual:

I think this entirely stems from the CRT.

Rather than a method of switching on a light as required and switching off a light as required, CRTs required a looping method of displaying anything (paint top to bottom, and repeat) as the image didn't last that long.

This had the benefit of a cheap changeable display, the only requirement was *something* that could repeatedly do the same thing over and over again, in sync with the CRT timing, but at the same time be dynamic enough to change what was to be displayed as required.

I wonder what that could be ?

i.e just displaying a blank window, every clock cycle the program is looping, repeatedly sending the command to create a window and display it - right?

Not at all. I don't know where you got that from.

When nothing happens, the loop does not run. Instead execution is blocked inside WaitWindowEvent(). WaitWindowEvent() calls an OS function that stops the program until something happens. When something happens (the window needs to be redrawn, or there is a mouse event) the OS starts the program again.

Take a look at this:It only loops, when you move the mouse over the window and at certain other events. The OS wakes up the program (which is stuck in WaitWindowEvent()) when something potentially interesting happens.

i think you (Zach) are just mixing up many technologies and (hardware)
designs. Inside of a PC are many components ... doing the same thing
over and over again. Why? Because they are supposed to do it.

But why they are designed like that? For the answer look at your life.
Search for loops. What is repeating inside of your whole life? Eating,
drinking, breathing, walking and moving everything from your body is
just repeating an earlier learned process, your life is full of loops.
And if all this loops are stopped ... the life ends. Thats why PCs are
designed to be like they are ... it is because we doesn't know anything
else.

And sure, there is many wast of power inside of a PC ... but it is not
that easy to change the behavior of how a Computer works. At the
end, we are going to be more and more efficient and as fast as
our CPUs are now ... this single instruction to go to the loop start again
is not really impotent, or what do you think. At the end, you could
admit that it is possibly the best solution for a computer.

MFG PMV

Thanks Trond, for picking up on that.

I didn't get the idea from anywhere, it was just the way I interpreted what was happening based on what I was seeing.. (i.e well the program ends if I don't loop it, so it must be repeating the instructions over and over and over to draw a window, etc..)

A flawed, but understandable "logical" conclusion for a layman to make.

Some assumptions you make are just wrong.

For example - if you write something into the videocard memory like a few thousand pixels which look like a window, the videocard will make sure this is displayed on whichever video technology you use (CRT, TFT, Beamer, plasma, LCD, e-paper whatever). The CPU doesnt need to endlessly redraw refresh that window. But in a modern OS like windows (coughs), you share the display with a bunch of other "apps" and therefore some higher instance manages the shared area on the desktop screen. You could write a program which draws something directly into video memory and then quits and the drawing would stay there, but once you move a window or other stuff over it, it will be overwritten and disappear. Thats because the (windows) OS uses windows to manage screenspace. Other window managers do it different.

With multitasking operating systems and traditional CPU systems, you usually have one process running in the background with the lowest priority possible. This process "historically" did something like this:

10 NOP
20 Goto 10

NOP = No Operation - a command which does nothing beside using a single clock cycle of the cpu.

It is the "idle" task nowadays and since CPUs know how to go into a sleeping mode, this is what it looks like nowadays:

10 HLT
20 Goto 10

The HLT command is a command which lets the CPU go into a power saving state. That means the CPU actually does (close to) nothing and consumes less power. Otherwise your CPU fans would always run with at maximum RPM

In some operating systems, this "idle" process is actually part of the scheduler, but in windows you should be able to see the "system idle process" in your task manager. The endless repeated redrawing is actually done for some video technology like CRT, but that is the duty of the graphics card.

Really old systems actually had software routines which did the video display and some computer systems later used programmable video custom chips. But thats irrelevant nowadys.

But in general, a CPU has a program counter, it fetches the instruction and data from the given program counter, increments the programcounter and then executes the command. Rinse repeat. Naturally you need to make a loop somewhere, because otherwise the CPU would run out of instructions at the end of the physical memory

Yep Ramihyn has good points.

There are lots of layers of abstraction/communication from your program you write all the way to what shows up on the screen. Basically:

o Your program says "draw a circle on my window".
(This does not need to be repeated until the OS sends you a redraw message, or maybe it's a game at a constant framerate.)
o The OS handles many of these windows and their z-ordering and overlapping, etc.
o The OS communicates with the video card via drivers, and draws the desktop, window borders, window contents, etc. to video memory (unless you are manually writing to video memory in your program).
o The video card communicates with the actual video hardware - VGA monitor, LCD screen, etc.
(Back in the days of VGA screens I know they had to continually scan thousands of pixels per frame, repeatedly looking up each pixel even if it wasn't changing. I don't know if newer screen technology communicate differently, but eventually at the lowest hardware level, you're just switching pixels.)

That is BASICALLY how it works, though some details might be wrong. So your user code, in some languages, may not be continously looping, but at some point in the chain, little mindless hardware components are just repeating the same tasks billions of times and don't care how you coded it.

I think the problem is actually more philosophical. In principle, CPU's only handle one task at a time (and a muliticore machine is just multiple CPU's each handling their own a single task at the time).

The CPU has a list of conditions and actions, but it can only consider one condition at a time. So, how can it consider the other conditions? By checking the first one, doing something if necessary, then checking the next one and so on.

Once the list is complete, it won't do anything, unless you tell it to start over. There's your loop

In addition, 'interupts' can be fired, which is simply another way to tell the CPU to temporarily halt whatever it is doing and do something else. Once done, return to the list.

Literally, a one track mind.

Sounds like most people I've ever met, come to think of it...

blueznl wrote:I think the problem is actually more philosophical. In principle, CPU's only handle one task at a time (and a muliticore machine is just multiple CPU's each handling their own a single task at the time).

The CPU has a list of conditions and actions, but it can only consider one condition at a time. So, how can it consider the other conditions? By checking the first one, doing something if necessary, then checking the next one and so on.

A modern CPU actually processes multiple commands at once. It looks ahead, does prefetching, predictively parses and even executes commands "out-of-order" in multiple integer execution units. Internal logic makes sure the correctness of a pseudo "in-order" execution flow is kept.

blueznl wrote:Once the list is complete, it won't do anything, unless you tell it to start over.

A CPU simple fetches command and data at the current program counter (E-IP), adjusts the program counter, executes the command and then starts with the same cycle again. If you want a CPU to "stop", you need to TELL it to stop. Either by external signals or dedicated commands. CPUs dont even stop when they reach the end of the physically installed memory, at least not last time i checked.