OSDev.org

Casm wrote:In the early eighties the processor in a PC ran at 4.77MHz. So if you assume that a two core processor is the equivalent of a single core running at 4GHz, something which would take the modern processor 1 second would have taken an 8086 about a quarter of an hour.

Your assumption is wrong. Modern processors are multi-pipelined, and the proportional method of calculating time taken doesn't apply here.
In more general sense, consider this as an example:

A code takes 2000 seconds to run on 8086 clocked at 2 MHz.
How much time does it take to run under a Pentium 4 clocked at 2000 MHz?

1 second? Err... no. This explicitly depends on the code instruction model as well as the processor designation. If the code is exceptionally pipeline hostile, then it may take 1 second but if the code isn't, then the processor will complete it in just few micro seconds.

Cheers.

My OS basically is optimized for 386/486 processors, and thus will not run proportionally faster on newer processors, especially not when they have penalties for segmentation and similar. RDOS will still run with acceptable speed with 4MB RAM on a 386, something most other OSes can only dream about. In fact, we have 6 installations out since several years back running on a diskless, keyboardless, 386-based system with two 2MB flash-chips (OS on one, application on the other) and 4MB RAM.

I currently see no reason why to optimize for modern processors. Modern processors will run fast regardless of such optimizations, while older CPUs need fast and small code to be usable.

Chandra wrote:

Casm wrote:In the early eighties the processor in a PC ran at 4.77MHz. So if you assume that a two core processor is the equivalent of a single core running at 4GHz, something which would take the modern processor 1 second would have taken an 8086 about a quarter of an hour.

Your assumption is wrong. Modern processors are multi-pipelined, and the proportional method of calculating time taken doesn't apply here.
In more general sense, consider this as an example:

A code takes 2000 seconds to run on 8086 clocked at 2 MHz.
How much time does it take to run under a Pentium 4 clocked at 2000 MHz?

1 second? Err... no. This explicitly depends on the code instruction model as well as the processor designation. If the code is exceptionally pipeline hostile, then it may take 1 second but if the code isn't, then the processor will complete it in just few micro seconds.

Cheers.

Try running the above program on a modern computer. It won't hang it in the way that it used to hang an XT, but it isn't instantaneous either.

Hi,

A code takes 2000 seconds to run on 8086 clocked at 2 MHz.
How much time does it take to run under a Pentium 4 clocked at 2000 MHz?

If the code running on an 8086 spends 1000 seconds waiting for data to be fetched from RAM and 1000 seconds actually doing something; then a Pentium 4 (with "100 times faster" RAM) might spend 10 seconds waiting for data to be fetched from RAM and 1 second actually doing something. That sounds good (11 seconds instead of 2000 seconds), but...

People's expectations have changed too. Maybe (back when people used 8086 CPUs) that program might have been processing 50 MiB of data in 2000 seconds, and maybe a modern computer with modern expectations would be processing 5 GiB of data instead. If the modern computer can do 50 MiB in 11 seconds then it might do 5 GiB in 1100 seconds, but only if you're lucky and the algorithm/s are "O(1)". Chances are that not everything will be "O(1)"; and maybe the modern computer with modern expectations will only take 20000 seconds.

Of course programmers have also changed. Once upon a time a programmer would spend ages trying to squeeze every last drop of performance out of their software. Not because they really wanted to, but because there's not much choice when you're working with "extremely limited" systems with very slow CPUs and tiny amounts of RAM. Now, the main focus is on development time. Maybe the modern version of that software could have taken 20000 seconds, but the developers wanted to develop it in PHP (to get it finished faster) and start selling the "final version" now rather than going bankrupt while they optimise it, so it actually takes 50000 seconds.

So.... something that took 2000 seconds back in 1980? Probably take 25 times longer now....


Cheers,

Brendan

Casm wrote:Try running the above program on a modern computer. It won't hang it in the way that it used to hang an XT, but it isn't instantaneous either.

I wasn't talking about whether that particular code would hang on XT or not, I was talking about this,

Casm wrote:In the early eighties the processor in a PC ran at 4.77MHz. So if you assume that a two core processor is the equivalent of a single core running at 4GHz, something which would take the modern processor 1 second would have taken an 8086 about a quarter of an hour

In this case, that particular code you are talking about, may take several hours. See discription above.

Brendan wrote:Hi,

A code takes 2000 seconds to run on 8086 clocked at 2 MHz.
How much time does it take to run under a Pentium 4 clocked at 2000 MHz?

If the code running on an 8086 spends 1000 seconds waiting for data to be fetched from RAM and 1000 seconds actually doing something; then a Pentium 4 (with "100 times faster" RAM) might spend 10 seconds waiting for data to be fetched from RAM and 1 second actually doing something. That sounds good (11 seconds instead of 2000 seconds), but...

People's expectations have changed too. Maybe (back when people used 8086 CPUs) that program might have been processing 50 MiB of data in 2000 seconds, and maybe a modern computer with modern expectations would be processing 5 GiB of data instead. If the modern computer can do 50 MiB in 11 seconds then it might do 5 GiB in 1100 seconds, but only if you're lucky and the algorithm/s are "O(1)". Chances are that not everything will be "O(1)"; and maybe the modern computer with modern expectations will only take 20000 seconds.

Of course programmers have also changed. Once upon a time a programmer would spend ages trying to squeeze every last drop of performance out of their software. Not because they really wanted to, but because there's not much choice when you're working with "extremely limited" systems with very slow CPUs and tiny amounts of RAM. Now, the main focus is on development time. Maybe the modern version of that software could have taken 20000 seconds, but the developers wanted to develop it in PHP (to get it finished faster) and start selling the "final version" now rather than going bankrupt while they optimise it, so it actually takes 50000 seconds.

So.... something that took 2000 seconds back in 1980? Probably take 25 times longer now....


Cheers,

Brendan

Marketing, PHP,..................?
Does that affect in code execution?

Yes, every single choice you make during the writing of a program has an impact on code execution. Brendan has vastly under-estimated some of the factors involved too... PHP probably incurs a 10x speed hit, not a 2.5x speed hit.

Either fortunately or unfortunately, business plays the most vital role in the computing industry, of providing the funds for software development to happen (ignoring any comments about FOSS). So without the marketing department, that software might not get written at all.

The reason a P4-based machine still appears to run at the same speed as an 8086, is that the software has more features. Why does it have more features? Because people like features, and marketing departments can use features to sell, and more features makes a business better than the opposition.

I think you are getting me wrong.

The discussion is going on this particular code example: Now, is there anything to do with marketing?

Hi,

Chandra wrote:The discussion is going on this particular code example:

Code: Select all

xor cx,cx
label:
push cx
xor cx,cx
loop $
pop cx
loop label

Now, is there anything to do with marketing?

The problem with that code is that it does nothing (other than set cx to zero and modify eflags) - you could probably replace the entire thing with a single "xor cx,cx" instruction.

In real software, the software actual does do something. It's designed to meet some requirement. The requirement/s depend on end-user expectations (or, marketing) and these end-user expectations have changed dramatically.

So here's the challenge: Can you think of some software that actually does something, where that "something" hasn't changed in 30 years?

For a simple example, let's look at word processors. They used to be "ASCII only" things that run in text mode. In 20 years they became WYSIWYG graphical things with internationalisation, scalable fonts, spelling and grammar checking in the background, support for embedding images in documents, etc. For comparison, I took a look at the Wikipedia page for WordPerfect, as WordPerfect has been around for ages.

Here's a screenshot of WordPerfect 5.1 for DOS (released in 1989):


And here's a screenshot of WordPerfect X5 (released in 2010):


WordPerfect 5.1 running on a modern computer would be extremely fast - it'd probably only take 3 seconds to go from "installation complete" to the recycle bin.


Cheers,

Brendan

JackScott wrote:The reason a P4-based machine still appears to run at the same speed as an 8086, is that the software has more features. Why does it have more features? Because people like features, and marketing departments can use features to sell, and more features makes a business better than the opposition.

What are the features in Windows 7 that make it worth the extra couple of gigabytes it needs to run effectively? Whatever they are, they must have escaped my notice (unless being slower than XP is a feature).

I use both Vista and Windows 7 and I find neither of them to be slower than XP. The catch is that your machine has to meet the requirements. If you have an older PC then it would be better to just leave XP installed.

A large portion of RAM and CPU usage probably comes from the fancy graphical effects and the desktop widgets, most of which can be disabled. I am not sure how much the internal kernel has changed from XP, other than dropping DOS support?

If you bought a new machine with XP back then, and compare it with a new machine of 7 now, of course the difference is negligible. Still, my laptop with a barely touched 7 install reaches the login screen slower than my ancient XP install, even though there should be about a factor 3 difference in processing power.

Its little different than for harddisks - usage always grows to fit the available power. You always think you're coming short when you need it.

Tosi wrote:I use both Vista and Windows 7 and I find neither of them to be slower than XP. The catch is that your machine has to meet the requirements. If you have an older PC then it would be better to just leave XP installed.

A large portion of RAM and CPU usage probably comes from the fancy graphical effects and the desktop widgets, most of which can be disabled. I am not sure how much the internal kernel has changed from XP, other than dropping DOS support?

My computer might not be absolutely top of the range, but it has got a dual core processor and 4Gb of memory. When I am using something like Microsoft Publisher, I can sit there and wait for Windows 7 to leisurely paint the screen. It is a lot faster in XP.

i think near or far pointer is relative with what instruction you use.
near or far pointer is just a operands in a intruction.
just according to the instruction you use!!

berkus wrote:

j8long wrote:i think near or far pointer is relative with what instruction you use.
near or far pointer is just a operands in a intruction.
just according to the instruction you use!!

I became enlightened.

me,too

j8long wrote:i think near or far pointer is relative with what instruction you use.
near or far pointer is just a operands in a intruction.
just according to the instruction you use!!

... is this haiku?