><snip>
>>At least now it is clearer that you base this ONLY on OPINION and some silliness about lots of stuff running in the background when nothing is obviously running.
><snip>
>Jim,
>When I look in Task Manager with just VFP7 running in XP pro there are lots of processes running.
>Someone is ignoring all of the System processes. If you are going to give Craig a hard time - then please be factual. Many of us lurkers follow these threads.

Things are not quite as simple as either you or Jim imply. On my (W2K) system, for example, 29 processes are "normally" running. However, CPU utilization hovers between 0 and 1% unless OE is checking the mail, or my box is logging a port probe on my firewall. So, it could be argued that, on average, these processes don't use much CPU.

However, there are many other CPU consumers that don't show up in Task Manager and which only come into play once you "do something" with your system. Good examples are the memory/cache/bus controller(s), and IDE disk and video drivers.

Imagine for a moment we're in the bad old days of low RAM and no disk caches (e.g. early DOS !) Every time the CPU wants something not in RAM, it has to go out to disk. Even modern hard drives are 5-6 orders of magnitude slower than silicon (say, 10 millisecond access time vs. 10 nanosecond access time for SDRAM). Even though the computer is working "as fast as it can", most of the time the CPU is waiting for data from disk, so while a job is processing, CPU utilization is low. The disk subsystem is the bottleneck.

Fast forward to today, and modern machines have significant L1 and L2 processor caches, and in most cases a meaningful disk cache. Until an application overwhelms one or more of these caches it runs at full silicon speed. However, it takes a lot of CPU to manage the L1/L2 cache controllers, RAM disk cache, and memory and PCI bus - by no means is all available CPU going to useful work on your app, there's a lot of housekeeping involved. Until a cache miss occurs, CPU utilization is high - maybe pinned. The CPU doesn't get a "breather" until a slow device needs to be accessed.

If you do have to hit the disk, a lot of systems these days use low-cost IDE controllers. It's been some time since I last looked at drive benchmarks but I seem to recall that under stress, some IDE drives can use 10 - 30% of CPU to support their read/write operations.

In many cases the video card won't come into play in intense VFP processing, but it could become a significant factor without the developer realizing it. For example, suppose you put the following "feedback" command into a tight SCAN loop on a large cursor:

WAIT WINDOW "Now processing record nnnnnn of xxxxxx" NOWAIT

Furthermore, suppose you have a video card that can't keep up with your CPU. Suddenly, your app's overall speed is limited to the speed the video subsystem can put the WAIT WINDOWs on your screen. It's just like waiting for a slow hard drive. I've seen tight loops speed up by a factor of 2, 3 or more by eliminating such commands - just like SET TALK/STATUS OFF helps, for similar reasons. Conversely, if your video card is fast but has a CPU-intensive driver, this command could cause your system to consume a lot of CPU without you realizing it.

Low cost PCs these days typically mate a quite fast CPU with skimpy RAM, marginal graphics and a relatively slow IDE hard drive. While munging large data sets the system will be paging out to disk often, giving the CPU lots of breathing room. Screen updates may offer a break as well. VFP apps are rarely CPU-bound on these machines.

The thread Jim mentioned was the uncommon case where a VFP app is truly CPU-bound. The system in question had tons of RAM and a fast, intelligent SCSI RAID disk subsystem. While the SCSI disk system probably requires very low CPU, its high performance is probably capable of saturating a PCI bus and maximally stressing the bus and memory controllers and OS-level disk cache. Once another CPU was made available to help with these housekeeping chores, it's not surprising the performace of the VFP app increased substantially.

For lurkers interested in hardware, sites like www.tomshardware.com and www.anandtech.com are good places to start.

All of the above is significantly off-topic from the origin of this thread. At the beginning it was not clear that this was a Terminal Server environment. In that case, the answer depends on two things:

- how many intensively processing VFP apps are expected to run simultaneously on the box.
- whether a single VFP app can make use of multiple processors.

If the box is expected to run 4 or more VFP processes simultaneously, the VFP threading question is moot - the larger number of processors will probably be better.

According to Erik Moore's investigations, VFP does run on more than one thread at least part of the time. I know nothing about the threading model used, which would determine whether the threads could possibly be run on multiple CPUs or if from a performance standpoint it would be worthwhile doing so. Another, related question is whether the extra threads increase VFP performance significantly or are simply low-priority threads assigned to VFP housekeeping tasks.

Craig seems to believe that multiple VFP threads will still run on a single processor. I'm sure someone like Mike Stewart at MS could answer this question directly. If this is true, running a single instance of a VFP app on a 4-processor box may not be cost-effective; one or two might be idle much of the time. But, in a TS environment with lots of remote users you're likely to keep all 4 CPUs busy much of the time. In that case, Craig is certainly right - you'd want to compare the performance of the various options under Terminal Server.

Houston's point was basically that it's important to optimize the performance of VFP apps when run under TS, which can require some specialized techniques. However, this can be said of any VFP app under any environment. Four users running an optimized app on a 4 CPU box will probably be better than 4 users running the same optimized app on a 2 CPU box.