>>VFP in and of otself is single threaded and single-tasked.
>
>I'm sure you know this, but just to clarify your answer:
>
>User code in VFP always runs in a single thread, and so your processes can be said to be single threaded, but VFP itself is multithreaded, and often runs internal tasks using 2 or 3 threads.

By that, almost any Winapp can be said to be multithreaded if it implements asynchronous I/O, the bulk of which is the improvement seen in most VFP apps; the release of the COPU from background I/O is not completely clean. There are, as you mention, other threads internal to VFP that we have no control over used for pruning and cleaning data cache in parallel with operations that would otherwise block waiting on OS services.

It seems that no one realizes that if you call for a read of 100MB, VFP is not circumventing the OS to do this - it submits a request and blocks it's primaruy thread of execution, and if it has no cleanup it can do in parallel, it idles.

In reality, VFP can call for asynchronous read and deferred write operations that can allow VFP to procede processing part of an OS submitted action even with only partical completion. It is, however, single tasked in that you cannot submit user-defined operations that can operate in a parallel state so that if one line of parallel action is blocked the other continues - this is one reason that the 'divide and conquer' strategy works - there are many instances where breaking a query into several segments run on separate systems, even though they all compete for the common OS disk objects in the query. A good discussion of how distributed computing can pay off in environments with single-threaded applications is covered in "Distributed Computing - Implementation and Management Strategies", edited by Raman Khanna, which includes a large number of articles originating in the academic communities at Stanford and Carnegie Mellon, which have been involved in massive parallelism implementations for years, and interestingly, from Harvinder Singh of Oracle, discussing the toplogies of parallel query resolution strategies. It's a bit dated, the copy I have is dated 1996.

There probably is a 30-50% overhead in single processor environments where disk and memory bandwidth or capacity don't force blocks of large data transfer operations. We can see this in the design of a number of mid-range computing solutions, even in the original proposed design strategy for the P4 processor, implementing a large L3 cache at a fraction of an order of magnitude performance compared to the masiive L23 cache strategy of the larger PIII Xeon processors, which could have L2 caches as large as 2MB (the L2 cache for the PII/PIII ran 256K or 512K typically, and the Celeron-A used a 128K L2 cache. Much of the competitive performance from the AMD Athlon and Duroin invplved their enlarged L1 and L2 caches, with L2 on chip rather than off-chip as in the original PII processor. There are good discussions of the cache tradeoffs on sysdoc.pair.com and www.x86.org ad their effects on different benchmark tests run against the Pentium III/Athlon as internal clock speeds approached and crossed the 1GHz range.