dual processors may be helping dos software

[Paul Purvis]

Hi, everyone.

I did some short test to compare the cpu usage on a few computers running dos software and did not make any chart, just made note of some general observations.

The dos software i used for this test is not very cpu friendly when it comes to being run under windows nt. The dos software is used all day long on workstations and there are some programs that are run to help hold down the cpu usage of these programs while they area being run. This is a very common situation in dos software, where the cpu usage is keep very high, and most of the cpu usage comes while waiting for a keyboard input in a console windows and i want you to know we do not run any dos graphic's software. it is all just plain text on a console screen.

well just to make things short, i had to replace a broken computer with a newer one and i picked a dual processors made by intel. it is rated at 1.8 Ghz and i use the windows 2000 pro operating system.

so far, i have been impressed by the speed of the machine compared to other 3.2Ghz machines. I am sure the new computer has faster ram, more cpu cache, and some other internal parts that are speeder than the previous 3.2Ghz machine.

i have several other machines which i did the same test on, that was just running the dos software on its own from the command prompt and watching the cpu usage inside the task manager.
the w2k os can use up to two processors and what knowledge i have picked up over the years, is that w2k will do some of its internal processing on the second processor if it finds one there when the os is installed. I think just about all or at least mostly all our software is not written to take advantage io using the second processor.

the outcome of what i saw, was there was a dramatic reduction in cpu usage compared to the other computers, which where not dual processors.
I do not consider hyper-processors to be dual processors and where we have these type of processors in computers, i have turned that feature off in the bios, because i believe for what we are running, because it just makes the computer slower when programs are not going to use a second processor.

so without any other test at this time, it appears that if you are going to be running any dos cpu hungry programs, a dual processor maybe what you should considering when purchasing equipment.

it would be nice to hear from some of the other members if they are seeing what i am seeing and that is a big reduction in cpu usage on dual processors while running dos software.
even software written to run on a 32bit system could have these same results in poor cpu usage, but i would think most programmers writing code for the newer os(windows nt and up) have addressed this issue for any software that stays running for long periods of time.

i am sure i will be doing a little more testing in this area, but do not plan on anything scientific.

paul

[Marco Pontello]

Off course there are many situation in witch a Dual (or more) processor CPU really help making the system more responsive. Every time you have a process that tend to hog the CPU (and that is the case more often with old 16bit DOS app, that never considered to have to share the CPU cycles with other app), with a dual CPU you "still have another", so to speak.
On the other side, there are still apps that can't take very much advantage by more CPU, being essentially single threaded. But the system in its complex will still fill snappier, because like you observed the many threads always running will be spawned on different CPUs.
There's also space to still take advantage of multi-CPU's even with single threaded apps, simply running more instances of them. That's usually the case, for example, with some audio encoding programs. Instead of compressing one folder of WAV file to MP3, you can compress two at the same time, and cut the time in half (saved for some I/O overhead).

Bye!

[Paul Purvis]

Marco thanks for those notes.

Do you think a program, maybe like one compiled with PB for Dos, basically a msdos compiler, would be run on the first processor one time and maybe on the second processor at another different time. Is that how it works?

I was not sure how or which processor a program would use, if there where two processors on one motherboard and a program did not have the ability to recognize or take advantage of a second processor.

With todays windows operating systems, at least those starting with windows 2000 pro, would you then suggest using a dual processor cpu over a single processor computer when using dos programs over any time period other than a short period.

paul

[Marco Pontello]

Do you think a program, maybe like one compiled with PB for Dos, basically a msdos compiler, would be run on the first processor one time and maybe on the second processor at another different time. Is that how it works?

Yes, that's basically the idea. It's the OS scheduler that determine how different threads are allocated in the various (physical & logical) processors available. But apps & users too can influence the process (see the Processor Affinity settings).

With todays windows operating systems, at least those starting with windows 2000 pro, would you then suggest using a dual processor cpu over a single processor computer when using dos programs over any time period other than a short period.

I would say that today, typically a multi processor is usually the better choice.
For situation in witch you basically have a monolithic, single threaded app, instead, the most fastest single core CPU is probably to be preferred. But anyway is a kind of CPU that is seeing its days counted, as for the current tech-trend.

Bye!

[Mike Stefanik]

Marco is right, the choice of single-core or multi-core processors is quickly becoming a moot point. The industry has decided that the way forward is not ramping up clock speeds, but rather multi-core designs. New systems today tend to be dual-core on the low end, and quad-core on the higher end. And just over the horizon are the Dunnington 6-core systems (essentially 3 dual-core 45nm Penryn chips) and the Nehalem 8-core systems (and from what I've read, the Nehalem microarchitecture will support more than 8 cores). Intel even demonstrated an 80-core system that they said would be available within 5 years.

This creates a challenge for software developers, who for years, had the idea that you could boost performance just by throwing higher clock speeds at it. On today's systems, if you want better performance, you need to design your application to be multi-threaded and intelligently distribute workload between those processors; monolithic architectures that peg one of the processors will not perform nearly as well. It's one of the reasons that you see some older applications (video games being notable culprits) with issues because they were written with the assumption that the ultimate arbiter of performance was clock speed, and that's not how things have turned out.

[Paul Purvis]

thanks for those remarks guys

not very long ago, i stayed away from those processors, because i thought i would not see much benefit of the second processor, but i was wrong, at least for my purposes at the user level.

i predicted several years ago that we would be using a lot of virtual software in the future. these improvements should make it more easier for the legacy software to run more smoothly on these newer machines, and allowing a better multitasking environment.

paul

[Mike Doty]

This is a very common situation in dos software, where the cpu usage is keep very high,
and most of the cpu usage comes while waiting for a keyboard input in a console windows
and i want you to know we do not run any dos graphic's software. it is all just plain
text on a console screen.

I was running PDS 7.1 software and eliminated it years ago using a IDLE command which
is like SLEEP or WAITKEY$ to release time-slices. Not sure what the equivalent is with
PowerBASIC for DOS, but it only needs to be placed in your input routine. Hopefully, there
is not a tight loop running without releasing time slices.

[Donald Darden]

Windows 2000 Pro was designed to take advantage of two processors if available. At that time, some advanced motherboards had slots for two processors. I would guess that the software is able to recognize a dual processor based on the older design, and make use of it.

Dual Processor technology also brings a more efficient and faster instruction pipe. The result is more instructions carried out at a lower clock rate, so "stepping back" to a 1.8 clock rate is not what it seems.

And as noted, other benefits of a more modern PC design and feature set can be felt in the way it performs overall. In particular, the addition of L1 and L2 caches and faster frontside and RAM mean major speed improvements. You can even count improved hard drive designs, because even though the rotation speeds may be the same, the higher bit storage capacity can mean faster read and write times, and the incorporation of buffers in the drive controller design means the ability to read ahead and write back at higher rates.

[John Spikowski]

I was running PDS 7.1 software and eliminated it years ago using a IDLE command which
is like SLEEP or WAITKEY$ to release time-slices. Not sure what the equivalent is with
PowerBASIC for DOS, but it only needs to be placed in your input routine. Hopefully, there
is not a tight loop running without releasing time slices.

Mike,

If you followed the DOSEMU thread, PowerBASIC for DOS doesn't seem to have the problem with CPU hogging. This was tested in the IDE and running programms. DOSEMU has a setting for DOS programs that don't like to share.

John

[Paul Purvis]

just something i had read from
http://www.infoworld.com/articles/tc...29tcwinxp.html

here is just another statement that i found interesting

Our tests on a dual-CPU system indicate that both Windows XP and Windows 2000 run better on an SMP (symmetric multiprocessing) configuration with relatively slow CPUs than on a single-CPU system with a screamingly fast processor. As we added more and more load, the benefits of a dual-processor configuration became more apparent. Both OSes (using Office 2000 and optimized UIs) handled the heaviest workload (scenario 3) nearly 40 percent faster on the SMP client machine than on the single-CPU Pentium 4.