Hardware Analysis - Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Bond Keevil — 2006-03-31T18:52:55-05:00

Having used a dual processor motherboard before, I noticed that there wasn't a significant performance boost if you were running a single program. While most programs have more than one thread, many of these are idle 99% of the time.

Where I did notice performance was when you had more than one process executing at a time. For example, writing a letter in Word while your anti-virus software is performing a full system scan in the background. In such cases, I didn't even notice a slowdown.

In short, it's not the number of threads, but the number of threads actually executing.

I am not sure what will happen with this dual-core technology, because my understanding is that they share the same L2 cache. Could the two processors actually run concurrently if they are constantly locking each other out of a shared cache?

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Alexander Kowalski — 2005-04-27T11:10:03-05:00

I would examine the testing tools other sites have used to examine the effects of Multithreaded code in the Operating Systems as well as applications running on it that are multiply-threaded designed.

There are a few benchmarks programs out there online that test this & iirc, are freebies too!

(It's better than writing up some code yourself & attempting to do tests that check this imo, takes less time!)

APK

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Sander Sassen — 2005-04-25T10:29:01-05:00

Alright, after some delay Intel shipped us a 3.2GHz (840) dual core processor and 955 chipset motherboard, before I let her go on a standard set of benchmarks that'll not do much for dual core, I'd like for you to tell me what you'd like to see. Keep in mind that we don't have time for elaborate testing schemes, as we're out to see if dual core can prove its worth on the desktop.

If you have any suggestions feel free to post them in the below thread, or email me directly at ssassen@hardwareanalysis.com.

Dual core benchmarking, we'd like your input
http://www.hardwareanalysis.com/content/topic/42925/

Best regards,

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Alexander Kowalski — 2005-04-12T16:06:22-05:00

I don't know if it's a matter of "NEED", rather than want... everyone wants to go faster & operate smoother I would assume... I know I do!

See, on SMP setups (mostly Dual Core or true physical smp rigs more than H/T ones), those multiple threads in apps DO get you a performance boost & one above & beyond single cpu systems vs. multiple cpu types (which do better in multitasking). Many tests that I cite above bear this out for me, as well as programming multiple threaded apps for a decade or more now... The poster Joe Gonko noted an excellent example of WHY he went multithreaded in his apps as well... NOT strictly SMP, but multithreading, and how/why etc. according to parallelism guidelines I cited, but with datastreams from soundcard channels in his work... and HOW IT IMPROVED THE PERFORMANCE OF HIS APP!

(This holds true really, for ANY applications, not just "high-end" ones, if designed well! Simple, mundane E.G.-> Do you get more work done with 1 arm, or 2 arms?)

I guess this applies best:

Read the above statements with quotes from other sites that analyzed that like Tom's Hardware & those along with the examples I put up above on how parallelism works in apps, where it is advantageous in apps to program with multiple threads!

(My Excel spreadsheet example, or Joe Gonko's designs in his app where multiple thread design helps on SMP/H-T/Dual Core cpu setups, & where multiple thread designwork would NOT help in apps (primitive math example, where putting processing for D (which has to wait for result of C) which uses C result, would not be smart to put on another thread... easy to understand really)).

HOWEVER - Single CPU setups, though, that are NOT "HyperThreaded" actually DO get slowed up from multithreaded applications designwork. I stated that above.

The point is, however (& I've been saying it for years) is that Intel is going to "force the issue" from now on in their CPU designs (really from 2003 onwards when H/T intro'd)...

Even single cpu setups via H/T have their spare "nops" assembly idling instructions being used to emulate a 2nd CPU (how I understand HyperThreading and how it works & is made reality).

Multiple threaded apps can have their parent thread run on one CPU, and the Operating System process scheduler takes care of running their subordinate child threads on the 2nd (or more) CPU's present in SMP (True physical dual or more CPU's present, H/T, or Dual Core setups).

That said? API work like GetProcessAffinity/SetProcessAffinity actual SMP programming work & cpu #'s detections?? Not even needed... Modern OS' like Linux, Windows NT/2000/XP/Server 2003 take care of thread mgt. (lightweight processes, better than UNIX forking) for you, AND do utilize it for better overall performance AND multitasking operations.

And, from what I see here and have for years? 88% of my applications in my process lists ARE multithreaded... if you want the MOST out of them?? You go Dual Core, H/T, or TRUE SMP (more than one actual CPU present)... the best of these imo?? Dual Core... less memory sharing & SMP mgt. overheads.

You don't really have a choice... it's the future of personal computing. I've been stating it for around 5 years now on Forums all over the web, & "the future IS now"... Intel's seeing to that: An SMP future where multiple threaded apps reign supreme for BETTER overall multitasking & performance.

APK

P.S.=> Another interesting review seconding & showing that Dual Core (SMP) type setups do better multitasking and that threads, help:

http://www.legitreviews.com/article.php?aid=188

(Good read, along with the Tom's hardware ones I put up above, enjoy!)... apk.

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Michael Miller — 2005-04-12T15:24:03-05:00

The author has a point. The average user does not need Hyperthreading or even Dual Core for that matter. Only those who use high end applications do. LIKE ME!!!

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Alexander Kowalski — 2005-04-08T13:39:16-05:00

To "Hammer the point home" more than the last quote from Tom's Hardware Page, this finishes it off moreso with reference to the Dual Core CPU design:

http://www.tomshardware.com/cpu/20050405/pentium_d-19.html

"The Pentium D:
Intel's Dual Core Silver Bullet Previewed

Article Info
The Pentium D:
Intel's Dual Core Silver Bullet Previewed Created:
April 5, 2005 By:
Patrick Schmid

In the past, noticeable performance gains have been achieved through the introduction of incrementally faster processors, but never before has the potential performance gain been as large as it is with dual core CPUs. Yet the potential can only be exploited with thread-optimized software - older, non-optimized programs will be executed only as fast as we are used to with current processors. "

Showing again, multiple-threaded applications (if designed with good parallelism guidelines from the examples I posted above, one where it does (Excel) & one where it does not (simple math results)) benefit applications running on SMP scenarios (such as H/T, true physical SMP, &/or Dual Core cpu's).

(Joe Gonko's design in his software he states above separating threads for diff. channels for his sound processing application is another GOOD solid example of how multithreading works also and how to design an app around it... & he later agreed on multithreaded code running (theoretically) slower on std. single cpu designs, but faster on SMP types).

And, best part? Explicit SMP code, such as GetProcessAffinity/SetProcessAffinity type API call code is NOT needed... the Operating System Process Scheduler handles this for you if your application has multiple threads, as my last post noted from Tom's Hardware Page as well as this one does...

APK

P.S.=> This also goes along with better multitasking period, & especially my example from above where setting REALTIME_CPU_PRIORITY on an application running on a system with a single CPU only on it will make the system appear to be "frozen/locked up", whereas on a true dual or more physical CPU system, an H/T system, or Dual Core one? The REALTIME cpu priority app will run on 1 cpu ALL TO ITSELF, while the Operating System & other programs run on the second (or more) cpu's, just fine... apk

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Alexander Kowalski — 2005-04-08T13:21:21-05:00

http://www.tomshardware.com/cpu/20050405/index.html

"To take advantage of multiple CPUs, modern software should be designed to use multiple execution threads, which encapsulate program fragments into snippets that can run independently. Windows XP's scheduler then allocates threads to the different CPUs, optimizing load balance and leading to better responsiveness of the whole system."

Another perspective on multithreading being used on SMP, HyperThreaded, or Dual Core CPU systems... EFFECTIVELY!

(Mirrors what I wrote above for the most part w/out all the detail & examples I posted (most of which should have been easy to understand, but this should drive the point home in a simple manner imo))

APK

P.S.=> Having a second source, one that's respected, helps drive the point home & all that... apk

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Joe Gonko — 2005-04-08T05:48:05-05:00

Well, to keep my post short, I didn't mention that I have a second array that acts as a backup to the RAID0 array (yes, I believe in data redundancy). Two large disks on that one (ie slower throughput). The Highpoint RocketRAID404 will do RAID5 but it does it in software (not an acceptable disk throughput sacrifice for me). That's why I'm drooling over the 3ware 9500 card and maybe getting PATA to SATA converters for the many 80gb drives. I know that others have had very bad experiences with Maxtor drives but mine hum along just fine (they are cooled very well so maybe that helps). I did have a couple of "older" Maxtor D740X drives start to whine loud (bearings) but the exchange process went fine also. Got new ones for free. Perhaps the drives shipped to Minnesota by Maxtor are great, heh.

Have a good one! Joe And, server rebuilding is quite fun (if not under-the-gun so-to-speak).

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Tim Magraw — 2005-04-07T06:55:30-05:00

Tim - My heart bleeds for you Joe, stuck with 640GB of storage. I just hope one of your drives doesn't go down! :o( I tend to go for RAID 5 myself rather than the more standard 0 or 1 or combination thereof. but I suppose coming from a system admin background rather than programming, (sad for a trained software engineer I know!) redundant MB/$ is more important to me than throughput. I really don't have a lot of time for IDE RAID either. A properley set up U320 SCSI Raid controller with 128MB Cache can get close to the max 320MB per channel in RAID 0 config - I would gues about 200MB in RAID 5, although I haven't calculated the overheads with the redundant write ops. Prices are a bit nasty though, the last box I bought with this kind of spec, Quad Xeon 700, 5 x 73GB U320 SCSI, 128MB Mylex RAID controller, in an Intel Hudson Chassis with 2 GB ECC RAM cost me �18500 + VAT (17.5%)..... Ahhhh those were the days! and GOD was it fast!

Joe - Shall we now open the discussion to include AMD's separated memory banks (HyperTransport) and how that would affect process switching and other stuff?? Hee hee

Tim - From a totally no knowledge point of view this looks like a total OOPS!

Got to go to work again, another server to rebuild. :o(

Bye Guys

Tim

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Joe Gonko — 2005-04-07T06:08:17-05:00

Alex, unfortunately, after spending the cash on the necessary components, I'm still using the Highpoint RocketRAID 404 card from the previous system, heh. Eight 80gb drives in RAID0. The card is in a PCI-X slot (64-bit/133mhz) but it'll only run at 32/33. Still, it'll do >100MB/sec which comes close to the 133MB theoretical max. Quite a few CPU-intensive tasks are offloaded to other hardware (ie MPEG2 encoding via Haup500 card, decoding and TV window via GT9800 card, etc.) and that helps. BTW, if you go the 800fsb Xeon route, buy Supermicro heatsinks which have speed-controlled fans and connect via 4-pin motherboard headers (otherwise the 3-pin Intel heatsink fans will drive you nuts continually spinning at max rpm of 5000).

Tim, you're right about singlethreaded apps running slower on SMP machines. The overhead involved in switching the process to a different processor, as the OS algorithm sees fit, will make it run slower. But, forcing the processor affinity should help solve that problem (I think...). And, yep, running the separate threads of my software was why I went SMP. <grin>

Shall we now open the discussion to include AMD's separated memory banks (HyperTransport) and how that would affect process switching and other stuff?? Hee hee.

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Alexander Kowalski — 2005-04-06T11:49:39-05:00

Tim - "OK, a touch picky but point agreed :o) "

It's ok man, I do the same myself @ times, especially under pressure (from others, work, etc. life in general)... it's a complex field, and a fairly complex topic. It's one of the more difficult things an Operating System has to manage, up there with (imo) memory mgt. as being the most complex, again imo.

Tim - "I also agree that I was guilty of knocking up a quick, and not totally precise post while the wife was not present to call me a boring nerd !o("

LOL! Man... I do know that feeling and experience, especially from women in my life. They just do not understand how interesting this field is or can be. BUT, to go off-topic a bit? We have to understand they need us around, emotionally especially, more than I think most guys into this field understand... it's more important, imo, than computers... oops! Did I say that? lol...

Tim - "Whilst I follow what you are saying, I don't have the background to generate such detail."

Now you do by all means. That's the point of my writing that up. Mainly for the article author Sander & on the point he amended on most apps not being multithreaded today (and my tasklists via taskmgr.exe show otherwise with 88% of my apps running between 2-43 threads each, and that multithreaded apps (because of the Operating System Process Scheduler) take advantage of SMP multiple CPU setup systems (true physical cpus, HyperThreaded, &/or Dual Core) for performance benefit. Without the need for EXPLICIT GetProcessAffinity/SetProcessAffinity API calls in the code of an application itself. Perhaps not quite as well, but they do by all means... this is especially illustrated in the REALTIME cpu priority being set on a particular Ring3/RPL3 application, and the OS and other apps surviving on the 2nd or more CPU's present... if REALTIME_CPU_PRIORITY is set on a single processor PC? The system appears to be locked up, and why you are told NOT to use REALTIME_CPU_PRIORITY on single CPU systems...)

Tim - "My comments were based on "real life" observations hopefully you will agree that yes multiple CPU cores whether physically seperate or not will have some variable benefit in normal operation, however the real speed up comes in multiple concurrent operations, whether implemented by specially written code or by multiple applications."

I know two things of interest here: Believe it or not? Multiple threaded apps can theoretically SLOW DOWN on single cpu systems (non-hyperthreaded ones), believe it or not. BUT, on SMP (actual 2 or more physical cpu's, HyperThreaded &/or Dual Core cpus) setup systems? Multithreaded applications speed things up as myself and the poster above noted who also writes multithreaded softwares. I proved it myself developing apps using hi-resolution timers ticking off how long it takes for my entire app to finish a job, and also how long each procedure/subroutine & functions take (multithreaded design vs. single thread main thread only design). Multithreaded designs on the Dual CPU systems I had and current H/T Intel P4 system here nearly always won (provided I used proper application of threads in multithreaded apps that gained in operations lending themselves to true parallelism performance gaining operations/scenarios).

Tim - "I miss my dual CPU P3 550 system, it was faster for my purposes (multiple programs running concurrently)at the time than the later model P3 1100 I also had. Joe I am seriously jealous! Do you use U320 SCSI too?"

You're right here, and I noted it above as well. I could do ALOT more @ once on SMP (or H/T systems) systems and of much more intensive nature without hesitation or interruptions of flow here because of Dual CPU smp setup systems in the past, & currently on Intel P4 3.2ghz cpu H/T system here now.

I do not use UltraScSi - I used to, UltraScSi-III based stuff (Adaptec adapters & Seagate Cheetahs on my Dual Pentium I 233mmx system) but found that since I was not running a system with 1000's of users hitting it? I was not gaining... interesting point you bring up, because of WHY UltraScSi is so good in multiuser (i.e. server based systems) scenarios - UltraScSi is a MULTITHREADED I/O Interface is why. I use SATA EIDE here (Western Digital "Raptor" 36gb 10,000rpm 8mb buffered disks), because it is optimized for single-user workstation/desktop applications in its I/O interface and cache aggression designs.

Here are my current system general specs again:

Intel Pentium 4 3.2ghz HyperThreaded (on/active)
512mb DDRAM-400 Corsair Matched Pair Memory
Dual Western Digital "Raptor" 36gb SATA 10,000rpm 8mb buffered disks (1= OS + programs, 2= GHOST)
CENATEK 2gb RocketDrive Solid-State Disk (1st 1gb partition= Paging File, 2nd 1gb= temp ops, webpage caching, application & OS logging)
ATI 9800XT Video 256mb RAM
Running Windows Server 2003 SP #1

Tim - "OOPS! - got to go to work!"

Yea, thanks for reminding me man! A.M. Coffee and posting here, gotta get back myself...

APK

P.S.=> Joe Gonko - "While most are right that multi-threading isn't great for the normal user," I agree on one note - on single CPU systems, as I noted above? Multithreaded apps can actually run slower than single threaded apps (in theory)... but on SMP arrangements (True Dual or more CPU's, or HyperThreaded/Dual Core designs)? The examples I note above show where it gains... much as you yourself noted on your interesting sounding application placing separate data (channels) onto diff. threads & seeing gains in overall processing time (less) using multiple thread application design to do so... and, following parallelism guidelines very well imo, separate channels = separate datastreams, but allowing you to process them in parallel simultaneously... good job, good application of multithreaded design principals imo as well... apk

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Tim Magraw — 2005-04-06T07:07:40-05:00

Hi Alex

"Hmmm, are you SURE you do not mean SMP specific applications (that use SetProcessorAffinity API calls in them as well as multiple CPU detection routines) vs. Multi-Threaded applications?"

OK, a touch picky but point agreed :o) I also agree that I was guilty of knocking up a quick, and not totally precise post while the wife was not present to call me a boring nerd !o(

Seriously.

Whilst I follow what you are saying, I don't have the background to generate such detail. My comments were based on "real life" observations hopefully you will agree that yes multiple CPU cores whether physically seperate or not will have some variable benefit in normal operation, however the real speed up comes in multiple concurrent operations, whether implemented by specially written code or by multiple applications.

I miss my dual CPU P3 550 system, it was faster for my purposes (multiple programs running concurrently)at the time than the later model P3 1100 I also had. Joe I am seriously jealous! Do you use U320 SCSI too?

OOPS! - got to go to work!

Bye guys

Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ

Joe Gonko — 2005-04-06T03:12:12-05:00

Wow. Lots of discussion on this (which is good).

I built a dual xeon 3.2ghz (800fsb) system based on the Supermicro X6DAE-G2 (no, I'm not trying to advertise). While most are right that multi-threading isn't great for the normal user, the software I write takes full advantage of the four logical CPU's. Instead of waiting for multiple FFT threads to complete on one processor, the work is split (by the program code) and the time required is reduced drastically. Multiple audio channels can be processed simultaneously. It is very fun to watch via task manager. Spotting a single-threaded app is very easy as it will only max-out at 25% on my system. But, my "FFT app" will send the CPU use to a full 100% when I give it the workload.

Unless you're working with high-powered software, whose programmers are quite good, HT or SMP isn't going to greatly benefit you.

Re: Most applications that we use on the desktop today are NOT multithreaded? SORRY FOR DOUBLE POST!

Alexander Kowalski — 2005-04-05T20:50:54-05:00

Re: Most applications that we use on the desktop today are NOT multithreaded? (Tim & others, read al
Tim - "In essence I totally agree that most applications are not multithreaded."

Hmmm, are you SURE you do not mean SMP specific applications (that use SetProcessorAffinity API calls in them as well as multiple CPU detection routines) vs. Multi-Threaded applications?

Background -> Here on system of this makeup:

Intel Pentium 4 3.2ghz HyperThreaded (on/active)
512mb DDRAM-400 Corsair Matched Pair Memory
Dual Western Digital "Raptor" 36gb SATA 10,000rpm 8mb buffered disks (1= OS + programs, 2= GHOST)
CENATEK 2gb RocketDrive Solid-State Disk (1st 1gb partition= Paging File, 2nd 1gb= temp ops, webpage caching, application & OS logging)
ATI 9800XT Video 256mb RAM
Running Windows Server 2003 SP #1

I run 47 total processes here concurrently listed in taskmgr.exe.

* Of that total sum of processes ALWAYS running here? 41 of the 47 resident run 2-43 threads on an H/T Intel CPU box.. that's 88% of my applications, TODAY 04/05/2005, running with multiple thread design!

(See, I ran 3 dual cpu systems years before this H/T rig: Pentium I, & III types over time (233mmx & 1ghz respectively) & because of multithreaded app designs and dual smp cpu setups? I multitasked FAR more smoothly & effectively... i.e.-> Zipping a HUGE file, surfing the web, watching WinTV2000, and more @ once with NO lags was easy on setups like those vs. single cpu systems. The 30-40% gain you get from running dual/smp cpu's was apparent in benchmarks, but multitasking also gained ALOT, as my examples note, and others online do from other people because of multithreaded applications... the Operating System Process Scheduler can send 'child threads' to 2nd or more CPU's, & especially if the main thread of ANY RUNNING APP saturates the first CPU! This can & does happen...).

Another example? When you set an application to REALTIME cpu priority?? That means it has 1 cpu ALL TO ITSELF, & the Operating System and other applications survive on second or more cpu's... afaik, this is EXACTLY why you are told on single CPU systems "DO NOT SET APPLICATIONS TO REALTIME PRIORITY"... especially Ring3/RPL (request privelege level 3) applications... i.e.-> Ones you use under the Explorer.exe shell!

This in turn, in the course of developing programs I made, turned up the fact that using multiply threaded application design (following parallelism guidelines I noted above on where it helps, & how, as well as what to design multithreaded applications around using parallelism gains on them), did indeed show while profiling my apps (primitive method, using hi-res timers and generating clock ticks counters with multithreaded design vs. non-multithreaded ones... and multithreaded design won by GOOD margins everytime. This is my "cheating way" of deciding when to use multiple threads in apps and what to use the threads on, or not... As well as obvious things I noted above in previous replies (with examples) which I will put down again in this reply too... it's important the author of this article understand that SMP & MultiThreaded apps go together like bread & butter...)

IIRC, this 'shunting' of secondary or more 'child threads' occurs with certainty when the primary process application thread (main thread) begins to near the first CPU #1 saturation of cycles point.

It can & does happen.

This is the point where secondary (or more) child threads WILL be sent to CPU #2 (or more, depending on how many CPU's are present physically, or otherwise (such as H/T emulation)) to run there to gain speed via operations that lend themselves to parallelism (Excel printing 1 spreadsheet worksheet while formatting another, no common data or result usually is present here because diff. data present (unless calling result from previous worksheet that is)), and where they do not (math example above, primitive but point IS there).

C= A+B
D= C+A

Where D absolutely MUST wait for the results of C prior to being calculated. This does not lend itself to parallelism in applications in this example. Placing it on multiple threads design to take advantage of multiple CPU arrangements (SMP specifically)? Not a good example of where it would.

Adding another CPU (or two, four, etc.) does not guarantee 100% power increase. Usually, it translates out to 30-40% better overall power, but for multitasking smoothness of operations running multiple apps? Absolutely... I've seen it myself, where I could Zip a HUGE file, surf the web, watch WinTV2000, and print documents and the system never even hiccups... SMP & multiple threaded apps (if well designed following the examples I posted above regarding what responds to parallelism well)? Only help make that even better...

APK

P.S.=> Hope the last two posts, in addition to my original one, help you make a better article is all Sander, so you have easily understood examples on multiple thread design, who/what/when/where/how vs. SMP SetProcessorAffinity related SMP coding API calls... I think you may have SetProcessorAffinity API calls work in apps confused with Multiple Thread designed ones, and are not aware of the fact that SMP setups (physically dual or more cpus, HyperThreaded CPU's, &/or Dual Core ones) can take advantage of multiple threaded applications designs... Hey, we are all learning man, all the time in this field...

The last few posts of mine? Sander, YOU might want to check out to better your article WITH concrete/discrete examples of what & where SMP helps with multiple threaded applications that are centered around putting threads onto operations that benefit from parallelism (Excel sheet example) & where it would not help (math example, primitive, but easily understood) above... apk

Re: Most applications that we use on the desktop today are NOT multithreaded? (Tim & others, read al

Alexander Kowalski — 2005-04-05T20:48:42-05:00

Tim - "In essence I totally agree that most applications are not multithreaded."

Hmmm, are you SURE you do not mean SMP specific applications (that use SetProcessorAffinity API calls in them as well as multiple CPU detection routines) vs. Multi-Threaded applications?

Background -> Here on system of this makeup:

Intel Pentium 4 3.2ghz HyperThreaded (on/active)
512mb DDRAM-400 Corsair Matched Pair Memory
Dual Western Digital "Raptor" 36gb SATA 10,000rpm 8mb buffered disks (1= OS + programs, 2= GHOST)
ATI 9800XT Video 256mb RAM
Running Windows Server 2003 SP #1

I run 47 total processes here concurrently listed in taskmgr.exe.

* Of that total sum of processes ALWAYS running here? 41 of the 47 resident run 2-43 threads on an H/T Intel CPU box.. that's 88% of my applications, TODAY 04/05/2005, running with multiple thread design!

(See, I ran 3 dual cpu systems years before this H/T rig: Pentium I, & III types over time (233mmx & 1ghz respectively) & because of multithreaded app designs and dual smp cpu setups? I multitasked FAR more smoothly & effectively... i.e.-> Zipping a HUGE file, surfing the web, watching WinTV2000, and more @ once with NO lags was easy on setups like those vs. single cpu systems. The 30-40% gain you get from running dual/smp cpu's was apparent in benchmarks, but multitasking also gained ALOT, as my examples note, and others online do from other people because of multithreaded applications... the Operating System Process Scheduler can send 'child threads' to 2nd or more CPU's, & especially if the main thread of ANY RUNNING APP saturates the first CPU! This can & does happen...).

Another example? When you set an application to REALTIME cpu priority?? That means it has 1 cpu ALL TO ITSELF, & the Operating System and other applications survive on second or more cpu's... afaik, this is EXACTLY why you are told on single CPU systems "DO NOT SET APPLICATIONS TO REALTIME PRIORITY"... especially Ring3/RPL (request privelege level 3) applications... i.e.-> Ones you use under the Explorer.exe shell!

This in turn, in the course of developing programs I made, turned up the fact that using multiply threaded application design (following parallelism guidelines I noted above on where it helps, & how, as well as what to design multithreaded applications around using parallelism gains on them), did indeed show while profiling my apps (primitive method, using hi-res timers and generating clock ticks counters with multithreaded design vs. non-multithreaded ones... and multithreaded design won by GOOD margins everytime. This is my "cheating way" of deciding when to use multiple threads in apps and what to use the threads on, or not... As well as obvious things I noted above in previous replies (with examples) which I will put down again in this reply too... it's important the author of this article understand that SMP & MultiThreaded apps go together like bread & butter...)

IIRC, this 'shunting' of secondary or more 'child threads' occurs with certainty when the primary process application thread (main thread) begins to near the first CPU #1 saturation of cycles point.

It can & does happen.

This is the point where secondary (or more) child threads WILL be sent to CPU #2 (or more, depending on how many CPU's are present physically, or otherwise (such as H/T emulation)) to run there to gain speed via operations that lend themselves to parallelism (Excel printing 1 spreadsheet worksheet while formatting another, no common data or result usually is present here because diff. data present (unless calling result from previous worksheet that is)), and where they do not (math example above, primitive but point IS there).

C= A+B
D= C+A

Where D absolutely MUST wait for the results of C prior to being calculated. This does not lend itself to parallelism in applications in this example. Placing it on multiple threads design to take advantage of multiple CPU arrangements (SMP specifically)? Not a good example of where it would.

Adding another CPU (or two, four, etc.) does not guarantee 100% power increase. Usually, it translates out to 30-40% better overall power, but for multitasking smoothness of operations running multiple apps? Absolutely... I've seen it myself, where I could Zip a HUGE file, surf the web, watch WinTV2000, and print documents and the system never even hiccups... SMP & multiple threaded apps (if well designed following the examples I posted above regarding what responds to parallelism well)? Only help make that even better...

APK

P.S.=> Hope the last two posts, in addition to my original one, help you make a better article is all Sander, so you have easily understood examples on multiple thread design, who/what/when/where/how vs. SMP SetProcessorAffinity related SMP coding API calls... I think you may have SetProcessorAffinity API calls work in apps confused with Multiple Thread designed ones, and are not aware of the fact that SMP setups (physically dual or more cpus, HyperThreaded CPU's, &/or Dual Core ones) can take advantage of multiple threaded applications designs... Hey, we are all learning man, all the time in this field...

The last few posts of mine? You might want to check out to better your article WITH concrete/discrete examples of what & where SMP helps with multiple threaded applications that are centered around putting threads onto operations that benefit from parallelism (Excel sheet example) & where it would not help (math example, primitive, but easily understood) above... apk