Kolja, On Monday 06 September 2004 16:08, Kolja Kauder wrote:

Mark Gray wrote:

...

...

On a multiprocessor (or hyper-threading) machine it buys you a WHOLE lot because the threads can execute at the same time.

That depends VERY MUCH on the machine, especially the memory setup, caches and FSB, as well as on the specific application. I've written some multithreaded numerical stuff myself, and I get very good performance on a dual-opteron machine and very sad results on older Pentium-III Hardware because if the problem is essentially memory bound you gain nothing. That said, it buys the lot for day to day stuff when one application operates on a small set of data while another one, e.g. X or seti, runs on the other node. However, this does NOT necessarily apply to hyper-threading, for this technique requires the actual instructions to be parallelizable. This is not possible in my case, so hyper threading only buys me a confused top, time(), etc. I find it hard to write good MT code and impossible to write good HT code, though examples of the latter are said to exist. Maybe that's why I'm only Optio and not Centurio (Asterix and the soothsayer) :-)

Performance analysis, let alone optimization, just gets harder and harder as hardware gets more and more sophisticated. Oops. I mean it gets more and more interesting... I'm not familiar with the breakdown of execution units and how they relate to x86 instructions (let alone to high-level language constructs) nor how much redundancy there is in execution units and data pathways within a Hyper-Threaded Pentium 4 or Xeon processor. My intuition is that a priori there'd be considerable opportunity for overlap within the CPU itself and that patterns of primary storage access (especially overall L2 and L3 cache hit rates) are the dominant ones. After all, for lots of common execution patterns, access to RAM is the limiting factor.

...

On a single processor it is wasteful of machine cycles, but does allow the programmer to background process things in a slightly more efficient manner than forking allows for.

If I understand this right that's not true: man fork: ... Under Linux, fork is implemented using copy-on-write pages, so the only penalty incurred by fork is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child. ... I take this to mean that fork()'ing and pthread_create()'ing are essentially the same. I have no clue though about native pthreads. Again, I'm only optio, if that much.

Creating a thread does not require a full set of new page table entries, since all the threads of a given process share with their siblings all of their virtual memory environment except for their stacks.

...

KK

Randall Schulz