Please register or login. There are 0 registered and 1289 anonymous users currently online. Current bandwidth usage: 326.30 kbit/s December 12 - 06:17pm EST 
Hardware Analysis
      
Forums Product Prices
  Contents 
 
 

  Latest Topics 
 

More >>
 

    
 
 

  You Are Here: 
 
/ Forums / Intel's dual core processors, sizzling hot snake o...
 

  Most applications that we use on the desktop today are NO...ded? Beg to Differ 
 
 Author 
 Date Written 
 Tools 
Continue Reading on Page: 1, 2, Next >>
Alexander Kowalski Apr 05, 2005, 08:11am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List Replies: 23 - Views: 4337
Article Author - "Hardly, as we’ve outlined before; in essence it comes down to the simple fact that most applications that we use on the desktop today are not multithreaded"

That's funny... of the 47 processes I have resident now? Taskmgr.exe shows 41 of 47 having more than 1 thread! In fact, between 2 and 43 threads on 41 of them... would you like a listing?

(I can provide it easily as can most people to dispute this point by you by using taskmgr.exe, process tab and selecting columns to view (in this case, threads) there from the VIEW menu, Select Columns submenu item, and threads must be checked).

I'd wager that MOST of what you run nowadays are not single-threaded applications, and that being the case? Your operating systems process scheduler will make GOOD use of the applications' threads on multiple processors... for years now, I have stated on forums that SMP (H/T, true physical, dual core or otherwise would be the future of personal computing... Intel's making it happen because modern OS & their process schedulers make it a reality for BETTER PERFORMANCE)!

APK


Want to enjoy fewer advertisements and more features? Click here to become a Hardware Analysis registered user.
Thermalfreak Apr 05, 2005, 08:48am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List

Edited: Apr 05, 2005, 08:49am EDT

 
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
Thats not what is meant by "not optimized for multithreaded operations....he means making a program make use of the threads on both cpus (physical and virtual).....its the same question behind dual core cpus....whether or not a single program will use the threads available on both prcoessors.....cuz otherwise its useless unless you multitask consistently

p.s. intel's hyperthreading makes their cpus have better performance? wow their cpus must really suck for them to still lose in everything but encoding and heavy multitasking.... :p

Ive snapped:
An xbox360 and a 12" iBook....
And a kawasaki er-6n to mod instead
Alexander Kowalski Apr 05, 2005, 09:28am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
Anonymous User reply #1 - "Thats not what is meant by "not optimized for multithreaded operations...."

Oh, really? What did he mean saying this:

Article Author - "Hardly, as we’ve outlined before; in essence it comes down to the simple fact that most applications that we use on the desktop today are not multithreaded"

Anonymous User reply #2 - "he means making a program make use of the threads on both cpus (physical and virtual)...."

Uhm, what do you think the OS does with multithreaded programs if CPU #1 is saturated and CPU #2 (physical actual cpu, H/T, or Dual Core emulated)? It will send second or more threads (child ones) to the least saturated CPU... and SetProcessorAffinity calls (specific multicpu detection and use code in an app API calls in Win32 iirc) are NOT needed, nullifying your next point.

Anonymous User reply #3 - "its the same question behind dual core cpus....whether or not a single program will use the threads available on both prcoessors...."

Oh, there's NO question it will. Modern Operating Systems such as Linux, Windows NT-based family ones like NT 3.5x/4.0-2000-XP-Server 2003, will make it so via their process scheduler iirc.

Anonymous User reply #4 - "cuz otherwise its useless unless you multitask consistently"

Most people do... like I said above? I run 47 total processes here concurrently. Of them, 41 of the 47 resident run 2-43 threads on an H/T Intel CPU box... I ran 3 dual cpu systems years before it (Pentium I, & III types over time 233mmx & 1ghz respectively) and 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.

Anonymous User reply #5 - "p.s. intel's hyperthreading makes their cpus have better performance? wow their cpus must really suck for them to still lose in everything but encoding and heavy multitasking.... :p"

AMD has a great product in the FX64 series, no doubt about it, mainly because it can access more memory at once vs. 32-bit Intel CPUs, and any process that is swapfile/diskbound WILL lose to memory bound processing.

However, I am not replying here about Intel vs. AMD to you though...

I am though, on about how multithreading IS the norm in most folks' taskmgr.exe process lists and is easil verifiable via having the THREADS column present, and the fact that SetProcessorAffinity calls are not really needed in code vs. effectively & efficiently designed multithreading in code (where the OS scheduler controls the running of threads on the least saturated cpu's for faster concurrency & operations... especially with out-of-order speculative executions and processes that lend itself to this, example next of one that does not):

C= A+B
D= C+A

C has to finish FIRST, in order for D to happen. That scenario does not lend itself well to concurrency & multithreading. Parallelism in applications' operations is the possibility you have to look for when using multiple threads. That is what has to be accounted for, & processes that do NOT grab the same data as the primitive example above notes. How well the author of any program uses threads is what is in question... design!

Other opeations in apps (vs. my small one above), however, do make good use of multiple threads!

(Many benchmarks online prove it... see them for yourself. Those same synthetic benchmarks have real world analogs.)

APK

Sander Sassen Apr 05, 2005, 10:58am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
Ah, classic mixup of terminology, I meant to say 'not making use of SMP' not threading, I'm sorry if that has caused for confusion, I updated the column to reflect this.

Sander Sassen
Editor in Chief - Hardware Analysis
ssassen@hardwareanalysis.com
Thermalfreak Apr 05, 2005, 12:03pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List

Edited: Apr 05, 2005, 12:12pm EDT

 
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
Doesnt that basically mean that although itll run spearate threads fine itll have problems processing simultaneously on both processors anyway?

Jeez Alex i make a short post you send over an entire essay like its a court case...relax dude

multitheaded programs still dont make optimal use of processors that give a second virutal or second physical cpu....unless its a professional program thats had it in mind its quite inefficient....turning hyperthreading on and off doesnt make any difference on 50% of the stuff that those processors are used for theres no point having better multithreaded support if your processor has such a friggin deep staged pipeline which has to correct itself halfway through and replies on the basic queing process the OS does

edit: anon. user? comin from a guy with 2 posts whos squabbling over a typo....

Ive snapped:
An xbox360 and a 12" iBook....
And a kawasaki er-6n to mod instead
Brian Stewart Apr 05, 2005, 12:55pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
LOL

I knew when I read this topic it was going to be someone who opened task manage and saw thousands of threads.

Those threads can be thought of as concurrently running processes. Only 1 may ever run at a time, but they can run in any order. So if you're encoding a video, you can use other things while it encodes.
You don't have to wait for one program to be done before you can use another.

Multithreading refers to using multiple CPUs. And your application has to be coded for this.
(Unless Windows gets a nice update so that it handles the load balancing, or Intel and AMD decide to implement automatic load balancing in hardware)

MSI K8N Neo 2 Platinum
1 GB DDR 400
Athlon 64 4600+
6800 GT
Alexander Kowalski Apr 05, 2005, 02:15pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
Sander (author) - "Ah, classic mixup of terminology, I meant to say 'not making use of SMP' not threading"

Sander, it's cool... but SMP is used by multiple threaded programs... DO READ MY LARGE, 2nd post above for the specifics, especially how the process scheduler can & DOES send child threads to the least saturated CPU if a program contains multiple threads. No SetProcessAffinity API calls (specific SMP related Win32 API calls) needed either... the OS handles it.

And, do pay attention to the primitive example (mathematics) of operations that do not lend themselves to parallelism (due to one process having to wait for another to complete).

It's about helping YOU, make a better article. That's all man, so you appear to have examples that are discrete and apply, showing what benefits from SMP (well designed multiple threaded apps & in what conditions parallelism applies for operations the system has to perform as well as applications). Requoted from above, next (below SMILEY!):

:)

Multithreaded applications today? ARE the norm in most folks' taskmgr.exe process lists and is easil verifiable via having the THREADS column present!

The fact that SetProcessorAffinity calls are not really needed in code vs. effectively & efficiently designed multithreading in code (where the OS scheduler controls the running of threads on the least saturated cpu's for faster concurrency & operations... especially with out-of-order speculative executions and processes that lend itself to this, example next of one that does not):

C= A+B
D= C+A

C has to finish FIRST, in order for D to happen. That scenario does not lend itself well to concurrency & multithreading. Parallelism in applications' operations is the possibility you have to look for when using multiple threads. That is what has to be accounted for, & processes that do NOT grab the same data as the primitive example above notes. How well the author of any program uses threads is what is in question... design!

Other opeations in apps (vs. my small one above), however, do make good use of multiple threads! Examples? Having say, Excel print one spreadsheet, while formatting another on a separate thread.

(Many benchmarks online also prove it... see them for yourself. Those same synthetic benchmarks have real world analogs, such as the Excel one I provided.)

APK

Alexander Kowalski Apr 05, 2005, 02:35pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
Also, sander & others:

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... we are all learning man, all the time in this field... this is one 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

Tim Magraw Apr 05, 2005, 03:34pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
I find myself in agreement with parts of all of these postings.

In essence I totally agree that most applications are not multithreaded. But I also agree that Multiple applications run concurrently can be and are!

For example (an old example here) Running a dedicated internet Unreal Tournament server (4 players on line 4 Bots) , installing Quake 2, and playing UT concurrently on a dual PIII 550 box, with no apparent lag in any of the running apps, has got to show that multiprocessors have their uses. If however youy want to do this kind of thing, you also need hard drives with queing cabability which neither IDE nor SATA drives have.

Another example - Scanning a high res image whilst doing anything else at all, we all know what a process hog scanners are! This is a genuine real world application for any kind of multi-thread technology whether implemented with multiple CPUs, by playing about with wait states on a single one, or by bunging a 2nd core onto a single die.

Have fun guys and keep up the discussion. Wouldn't the world be c##p if we all agreed on everything?

Tim

Alexander Kowalski Apr 05, 2005, 04:48pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> 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)
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

Alexander Kowalski Apr 05, 2005, 04:50pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? SORRY FOR DOUBLE POST!
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

Joe Gonko Apr 05, 2005, 11:12pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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.

Tim Magraw Apr 06, 2005, 03:07am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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

Alexander Kowalski Apr 06, 2005, 07:49am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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

Joe Gonko Apr 07, 2005, 02:08am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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.

Tim Magraw Apr 07, 2005, 02:55am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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

Joe Gonko Apr 08, 2005, 01:48am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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).

Alexander Kowalski Apr 08, 2005, 09:21am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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

Alexander Kowalski Apr 08, 2005, 09:39am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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

Michael Miller Apr 12, 2005, 11:24am EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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!!!

Alexander Kowalski Apr 12, 2005, 12:06pm EDT Reply - Quote - Report Abuse
Private Message - Add to Buddy List  
>> Re: Most applications that we use on the desktop today are NOT multithreaded? Beg to Differ
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.


Write a Reply >>

Continue Reading on Page: 1, 2, Next >>

 

    
 
 

  Topic Tools 
 
RSS UpdatesRSS Updates
 

  Related Articles 
 
 

  Newsletter 
 
A weekly newsletter featuring an editorial and a roundup of the latest articles, news and other interesting topics.

Please enter your email address below and click Subscribe.